Watch real users attempt real tasks and find exactly where the design helps and where it fights them. Prototyping builds the artefact; usability testing extracts the learning.
▸ Try the interactive toolUsability testing is the practice of observing real users attempting to complete real tasks with a product or prototype, to discover where the design helps them and where it gets in their way. Where prototyping builds the artefact, usability testing is the method that extracts the learning from it.
The defining discipline is to give users tasks, not tours — and then stay quiet. You ask the user to accomplish something real and watch where they hesitate, misread, or get stuck, without explaining, leading, or rescuing them. The moment you help, you've contaminated the result. A handful of users reveals most usability problems, because the same friction points recur; the value is in watching behaviour, not collecting opinions.
Give the user a realistic task (“buy a ticket for next Friday”) — not a tour or a leading question. Watch, don't help. Note where they hesitate, err, or abandon. A few users surface most issues; behaviour, not opinion, is the data.
The designer's curse is knowing how the product is meant to work; usability testing is the only reliable way to see it through eyes that don't.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Designing in a bubble | The team knows how it works, so can't see what confuses newcomers. | Watching real users reveals the friction the team is blind to. |
| Asking opinions, not tasks | “Do you like it?” gets politeness, not usability data. | Real tasks reveal what actually trips users up. |
| Leading and rescuing | Helping the user mid-task hides the very problem you're testing for. | Staying quiet lets the genuine friction surface. |
| Over-testing for confidence | Waiting for huge samples when a few users reveal most issues. | A handful of users is enough to find the major problems. |
Frame what you want to learn as a concrete task the user attempts (“complete X”), not a question about preference. Tasks produce behaviour; questions produce opinions.
Five-ish users from the target audience surface most major issues. The right users matter more than many users; testing the wrong people validates nothing.
Observe where they hesitate, misread, click wrong, or give up. Resist every urge to explain, hint, or rescue — the struggle is the data.
Have users narrate their thoughts as they go (“I'm looking for…”, “I expected…”). This reveals the mental model behind the behaviour, not just the behaviour.
Capture each problem and rate its severity — how many users hit it, how badly it blocked them. Fix the severe, common issues first; not every snag is worth addressing.
A team was sure their checkout was intuitive — they'd designed it, after all. In usability testing, the first user was given a simple task and immediately stalled at a step the team considered obvious, hunting for a control that wasn't where they expected.
The instinct in the room was to jump in and point — which would have erased the finding. Instead the facilitator stayed silent and watched the user struggle, then eventually work around it. Four of five users hit the same wall. The problem was invisible to the team precisely because they knew where everything was; only watching uninstructed users revealed it, and only by not helping.
The deliverable is a list of observed usability problems, each with a severity rating, ordered for fixing.
| Do | Don't |
|---|---|
| Give a realistic task | Give a guided tour |
| Watch silently | Explain or hint |
| Let them struggle | Rescue them mid-task |
| Ask them to think aloud | Ask “do you like it?” |
Usability testing works by removing the one thing the team can't switch off — its own knowledge of how the product is supposed to work. Real users, real tasks, and a quiet observer reveal the friction expertise hides.
The hardest part is behavioural, not methodological: staying silent while a user struggles with something you could fix with one sentence. But that sentence would destroy the data — the struggle is the finding. Every rescue, hint, or explanation substitutes the team's mental model for the user's, which is precisely the substitution the test exists to prevent. Five users from the right segment, given real tasks and left to struggle, will surface the major problems reliably — and the discipline of watching rather than helping is what turns a polite demo into genuine evidence about whether the design works.
Walking users through hides whether they could do it alone. Set a real task.
The single most common error. Rescuing the user erases the finding. Stay silent.
“Do you like it?” yields politeness. Watch behaviour instead.
Friendly insiders won't reveal real friction. Recruit the actual segment.
Prototyping (Tool 16) builds the artefact; usability testing gets the learning out of it.
When analytics shows a drop-off, usability testing reveals the usability cause (Tool 09).
Observed usability problems become structured insights (Tool 21) that drive design decisions.
It's the primary method for retiring the usability risk in the Four Big Risks (Tool 01).
Take any product and pick one realistic task. Ask someone unfamiliar with it to complete the task while thinking aloud — and commit to saying nothing, however much they struggle.
Note every hesitation and wrong turn. Resist the urge to help even once.
The hardest part won't be finding problems — it'll be staying silent. That difficulty is exactly why teams miss usability issues: their instinct is to explain rather than watch.