the ux pocketbook.

Judging a Design

• What problem does this solve, and for whom?
• Do they need it at all, or do they already have something that works?
• Can someone new tell what matters most and what to do next?
• Does it behave the way people expect, and can everyone use it?
• Are the words theirs?
• Does it work with how people think, and is it honest with them?
• How do we know? What have we tested, and what are we assuming?

Before You Test

• Write the chain: observation, problem statement, hypothesis
• Write the hypothesis as “If we …, then … because …”
• Decide what result would change your mind
• Have the team write down their predictions

Choosing Your Evidence

• Know which rung you’re on: opinion, what people say, what they do with a prototype, what they do with the real thing
• Get as close to the real thing as you can afford
• Pick the cheapest test that could prove you wrong
• Run A/B tests on a live product with enough traffic
• Treat a survey score as a signal, then watch people to find the cause

Running a Usability Test

• Recruit about five people per round, three or four per group if you have several
• Run a pilot with one person first
• Open with “I’m testing the screen, not you”
• Watch without guiding, and stay quiet when they get stuck
• Keep leading words out of your questions
• Watch the recordings as well as the pass rate

Reading and Sharing Results

• Report small samples as counts (“5 of 10”), never percentages
• Say it plainly when a decision was wrong, and say “we”
• Reframe the question the evidence answers
• Say “we don’t know yet,” then say how you’ll find out

Keeping Pace

• Small changes go on judgment; features and major overhauls get validated
• Test in small, frequent rounds
• When the team is arguing, test it

Before You Start

• Work through the 5W Framework (Who, When, What, Why, How)
• Identify the real problem, not just the stated ask
• Understand your timeline and constraints
• Determine which activities will give you the most valuable insights

Create Your PDP

• Document the problem and objective
• Define KPIs and success metrics
• List activities and deliverables with t-shirt sizing
• Create a timeline working backwards from the deadline
• Identify who needs to be involved
• Share with stakeholders and get alignment
• Define what good output looks like before you delegate work

During Execution

• Use your PDP as your weekly guide
• Communicate progress regularly (before meetings, after meetings, between meetings)
• Stay flexible and adjust when things change
• Document decisions and next steps in writing
• Run check-ins at the end of major activities

When Things Don’t Go as Planned

• Identify your constraints (time, resources, knowledge, organizational)
• Determine what’s most critical to keep vs. what can be cut or merged
• Do lean versions of important activities rather than skipping them entirely
• Communicate trade-offs clearly to stakeholders
• Take ownership and find creative solutions

Fundamentals

• Every story needs conflict (problem), journey (process), and resolution (solution)
• Tailor your story to your audience’s priorities

Project Storytelling (Internal Presentations)

• Use Problem → Solution for quick, clear updates
• Use Current State → Future State to show transformation
• Use Diverge, Then Converge to show your thinking and options
• Always explain the “why” behind your decisions
• Label estimates as estimates

Case Study Storytelling (Portfolio)

• Open with a short outcome summary, then follow the structure: Overview → Problem → Process → Solution → Impact
• Show the decisions and trade-offs you made
• Use numbers you can source and explain
• Show your role clearly (“I” not “we” for your contributions)
• Say who made what, and what you changed
• Be honest about challenges and what you learned
• Make it visually compelling and scannable

Communication Throughout Projects

• Set clear expectations before meetings
• Document decisions after meetings
• Maintain visibility with regular updates
• Build your brand through consistent, clear communication

Core Beliefs

• You already have everything you need to be successful
• Your existence has purpose: use your unique gifts
• Success comes from belief + adaptability + work ethic

Overcoming Self-Doubt

• Self-doubt often comes from uncertainty: focus on serving others
• Your value doesn’t change based on someone else’s inability to see it
• Knowledge comes with reps; understanding comes with time

Mastering Your Craft

• Progression: Learning → Practice → Mastery → Teaching → Influencing
• Do the hard things until they become easy for you
• Hard work and setbacks lead to growth and strength
• Consistency over time creates extraordinary results

The Tool Was Never the Job

• Think of yourself as a handyman with a toolbox: choose tools based on the job
• Become tool-agnostic so you can adapt to any environment
• The tools will change, but the outcomes stay the same
• Learn new tools by building real projects, not just following tutorials

Ownership Mindset

• Take responsibility for outcomes, not just outputs
• Understand clouds (big picture) and dirt (execution details)
• Be proactive: solve problems before you’re asked
• Give visibility to your work
• Own as much of the cycle as you choose, from research to shipped
• Own your mistakes and learn from them

The Long Game

• Everyone can win. It’s not a zero-sum game
• Entry-level roles are competitive: show real work and the judgment behind it
• Explore briefly, then commit to a direction and build depth
• Build on fundamentals over time
• Give back and mentor others
• Keep showing up

• WHO: Who is experiencing the problem?
• WHEN: When does this need to be done?
• WHAT: What problem are we solving?
• WHY: Why is this problem happening?
• HOW: How will we solve this?

Project Name:

Problem & Objective:

KPIs & Goals:

Timeline:

Activities & Timeline:

Cross-Functional Partners:

Success Criteria:

A brief hands off one piece of the work: a task for a teammate, an engineer or an AI assistant.

• Goal: The outcome you want and why. Lead with it, before any steps.
• Done looks like: What you’ll see when it’s finished, in terms you can check.
• Context: Who it’s for, what’s been tried, where the background lives.
• Constraints: The deadline, what can’t change, what needs your sign-off.
• How to check the result: The test or review that tells you both it’s right.

“If we …, then … because …”

Project Overview → Problem → Process → Solution → Impact & Next Steps

Start with the outcome: two or three lines above the first section that say what changed, what your role was, and how you know it worked.