Usability testing
Every other level in this section answers does the interface do what we said it would. Usability testing answers a different question, and it is the one the product actually lives or dies by:
Can a real person, who did not build this, accomplish what they came to do?
A journey test proves a path is passable. It cannot tell you whether anyone finds it, understands it, or gives up two steps in. Those are observations about a person, and the only instrument for them is a person.
What it is
Section titled “What it is”Someone from outside the team is given a real task, not a tour, and attempts it while you watch and stay quiet.
That is the whole method. Everything below is about not ruining it.
| Usability test | Demo | Interview | |
|---|---|---|---|
| Who talks | The participant | You | Both |
| What you learn | What they do | What you already knew | What they say they do |
| Success looks like | They struggle and you find out why | Applause | A pleasant conversation |
| The failure mode | You help them | — | They tell you what you want to hear |
The last row is the one to guard against hardest. The instinct to rescue a struggling participant is overwhelming, and every rescue deletes the finding you were there to collect.
Five participants, not fifty
Section titled “Five participants, not fifty”The number surprises people, and it is the reason this is affordable enough to do per feature rather than per year.
A handful of participants surfaces the large majority of the serious problems in a given journey, because serious problems are not rare — they are hit by almost everyone who tries. Rare problems need volume; blocking problems do not.
The practical consequence: five participants, five times a year beats twenty-five participants once. You are not measuring a population, you are finding the things that stop people — and after the third participant hits the same wall, more participants only confirm it.
If you need a number rather than a list of problems — a completion rate, a comparison between two designs — that is a different instrument with a different sample size. Do not run one and report the other.
How to run one
Section titled “How to run one”Recruit for the task, not for the demographic. The person must plausibly want the outcome. A colleague from another team is a far better participant than nobody, and a far worse one than an actual user.
Give a task, not instructions. “You have a voucher code from an email and you want to use it on this order” — never “click Apply Voucher.” The moment you name the control, you have tested nothing.
Ask them to think aloud, then stay quiet. Silence is the technique. When they pause, count to five before saying anything.
Answer a question with a question. “What would you expect to happen?” You are not being coy — what they expected is the finding.
Record the struggle, not the opinion. “I don’t like the blue” is worth nothing. “They scrolled past the primary action three times” is worth a redesign.
Stop at the point of failure and note it, then help them past it so the rest of the journey still gets tested. One block should not cost you the other four findings.
Forty-five minutes per participant. A round of five fits in a day, including the debrief.
Where the tasks come from
Section titled “Where the tasks come from”Not from imagination — the same places everything else in this hub comes from:
| From | Provides |
|---|---|
| Journey mapping | The journeys worth testing, and what the person’s goal actually is |
| The UX row of the story map | The steps marked assumption in the evidence card — test those first |
| Example mapping state cards | The unhappy paths: what people do when they are denied, when it is slow, when it is empty |
| Support tickets | The journeys that are already failing, with the evidence attached |
Testing the happy path only tells you what your demo already told you. The findings live in the recovery.
What comes out
Section titled “What comes out”Three kinds of output, and they go to three different places:
- A blocking problem — someone could not finish. This is a defect and it goes into the work, immediately.
- A friction problem — they finished, slowly, or by a route you did not intend. This goes to design critique, and often becomes a story.
- A contract finding — the pattern that confused them is a design-system pattern, used everywhere. This is the most valuable and the most expensive: it is a change request against an established contract, and it affects every screen that uses it.
That third category is the reason to run this against real established patterns rather than against a throwaway prototype. A finding about a pattern the whole product uses is worth twenty findings about one screen.
When to run it
Section titled “When to run it”Before it is built, on a prototype, for anything whose journey is new. This is where it is cheapest and where it changes the most.
After it is built, before it is widely released, for anything whose journey changed. This is where it catches what the prototype smoothed over.
Never only at the end. A usability test run the week before launch produces findings nobody can afford to act on, which teaches the team that usability testing is expensive noise — the same way a late accessibility audit teaches the team that accessibility is expensive noise. It is the timing that is expensive, not the practice.
What it cannot tell you
Section titled “What it cannot tell you”Whether people will want it. They agreed to attempt a task you gave them. That is not demand, and treating it as demand is how a usable product with no users gets built.
How it behaves at scale, over months, with their own data, under their own deadlines. Forty-five minutes in a quiet room is a specific and unrepresentative context.
Anything statistical. Five people cannot support a percentage. Report what happened and to how many, and resist every request to turn it into a metric.
Where it connects
Section titled “Where it connects”- Journey tests are the automated floor this sits on top of: they keep the path passable so the session is spent on comprehension rather than on bugs.
- Journey-first is the argument for why the journey gets the attention; this is the level where the journey is judged by someone who did not design it.
- Accessibility tests makes the same point about testing with people who use assistive technology — which is usability testing, with participants the team is most likely to skip.
- Journey mapping is where the findings go back to.