Five People and a Task

Here's the entire method, in three lines.

Give someone a task. Watch them do it. Say nothing.

Everything else in this article is detail around those three lines — and nearly every failed usability test failed on line three.

Why five

The number comes from Jakob Nielsen and Thomas Landauer's 1993 paper. If each participant finds some fraction L of the problems, then n participants find 1 − (1 − L)ⁿ of them. With a typical L of around 31%, five people surface roughly 85% of the problems in a design, and each additional person after that finds mostly what you've already seen.

Three caveats keep this honest:

It's five per audience segment. If beginners and experts use the product completely differently, that's five each.

It applies to finding problems, not measuring anything. Any number you want to state with confidence — success rate, time on task, whether B beats A — needs a far larger sample. Five people tell you what is broken, never how much.

Three rounds of five beat one round of fifteen. Fifteen people all hitting the same broken screen gives you fifteen reports of one problem. Test five, fix, test five again, and the second round finds the problems that the first problem was hiding.

Tasks, not questions

The most common way to waste a session is to ask people what they think instead of asking them to do something.

A good task has three properties:

A goal, not an instruction. "Find out how much it would cost to send two boxes to Kazan next week" — not "use the shipping calculator."

No interface words. If your task says "click the settings icon and choose notifications," you have just performed the test yourself and handed them the answer. Name the outcome; let them find the path.

A realistic starting context. "You've just got an email saying your subscription is about to renew, and you want to stop that." Context determines where people look, and a task with no context tests a person who doesn't exist.

Give three to five tasks per session, ordered from simple to complex, and use realistic data — an account with content in it, not an empty demo.

Thinking aloud

Ask people to say what they're thinking as they work. The technique goes back to Anders Ericsson and Herbert Simon's work on protocol analysis, and it's the closest thing we have to reading someone's mind while they use software.

It's not free. Talking slows people down and can make them more deliberate than they'd normally be — worth knowing, and still worth doing, because the alternative is watching a silent cursor and inventing explanations for it.

When they go quiet at the interesting moment, prompt neutrally: "What are you thinking now?" "What are you looking for?" "What do you expect will happen?" Never "why did you do that?" — that invites a justification, and justifications are the confabulations from the interviews article.

If thinking aloud disturbs a task too much, use the retrospective version: let them work in silence with a screen recording, then watch it back together and ask what was going on at the moments where they stalled.

The moderator's discipline

This is the hard part, and it's entirely about restraint.

Don't help. The urge is overwhelming — the person is struggling with something you could resolve in four words, and staying silent feels cruel. But their struggle is the data. Wait. Count to ten. Let them fail properly; failure has a shape, and the shape is what you came for.

Don't explain your design. Not before, not during, and not after the first stumble. The moment you explain, you've trained them and lost the rest of the session.

Don't lead. Not "did you notice the button at the top?" — that's the answer wearing a question mark. When they ask you something, bounce it back: "what would you do if I weren't here?"

Say you didn't design it. "I'm not the designer, so be as harsh as you like — you can't hurt my feelings, and criticism is what helps." This measurably increases candour, and if it's a small lie, it's an ethical one.

Sit slightly behind them. Eye contact makes people perform for you; a seat off to the side lets them focus on the screen.

Watch the hands, not the mouth. What people do outweighs what they say. If someone completes a task with visible difficulty and then says "that was easy," write down the difficulty.

Listen for the tells. "I'd probably ask a colleague at this point." "Normally I'd just phone them." "I'd give up here, honestly." Each of those is a critical failure being politely disguised as a preference.

What to record

Not "the user was confused." That's a summary, and summaries can't be acted on or checked.

Record instead:

Task success — completed, completed with difficulty, failed, gave up.
Where exactly it stalled — the screen, the element, the moment.
Their words, verbatim — the quote is what will persuade the room later.
What they expected — the gap between expectation and behaviour is the finding.
Severity — frequency, impact, and whether they'd hit it every time or learn around it.

The mistakes that void a test

Testing on colleagues. They know too much and want you to succeed. For an early rough check a hallway test is fine; for anything real, recruit strangers.
Demoing instead of testing. If you're talking more than a fifth of the time, this became a presentation.
Rescuing at the first sign of trouble. The most common and most expensive error.
Asking "was that easy?" at the end. People say yes. You watched them struggle for four minutes; you already know.
Changing the task mid-session to steer someone away from a problem.
Recruiting only enthusiasts. People who already love the product test a product that already worked for them.

Other cheap checks worth knowing

Hallway test. Grab whoever's nearby, five minutes, one task. Low quality, near-zero cost, catches embarrassments before they reach real participants.

Five-second test. Show a screen for five seconds, then ask what it's for. Tests first impression and hierarchy, nothing else.

First-click test. Give a task, record only the first click. The research here is striking: when the first click is correct, people complete the task at dramatically higher rates than when it isn't. It's a cheap way to test navigation and labelling without a full session.

Heuristic evaluation. One or two people walk the interface against Nielsen's ten heuristics and list violations. Fast, useful, and no substitute for watching a real person — it finds what a designer would notice, which is a different set from what a user hits.

A/B test. Answers "which one performs better" at scale, and never "why." Pair it with the qualitative work or you'll optimise your way into a local maximum without understanding it.

Then actually change something

A test that produces a document nobody acts on is theatre.

Take the findings, score them by frequency, impact and persistence, and pick two things to fix before the next round. Two. A list of twenty gets prioritised into oblivion; two get done. Then test again, because your fix is itself an untested hypothesis.

One round of testing is an opinion. Three rounds is a process.

In practice

Run one session this week. One person, three tasks, twenty minutes. Don't wait for a proper study.

Write your tasks and check them for interface words. Delete every button name, icon name and menu name from the wording.

Practise the ten-count. When someone struggles, count to ten before you say anything. It's the single hardest and most valuable habit here.

Record two things per stall: what they expected, and what they did instead.

Show a clip, not a summary. Thirty seconds of a real person failing ends product arguments that thirty slides can't.

Fix two things and test again. Book the second session before the first one happens.

Check yourself

Close the article and answer in your own words:

Where does "five users" come from, and what three caveats keep it honest?
Why are three rounds of five better than one round of fifteen?
What makes a task good, and what one thing must never appear in its wording?
What does thinking aloud cost you, and why is it worth it anyway?
Why must you not help, and what should you say when someone asks you a question?
Someone finishes with obvious difficulty and says "that was easy." What do you record?
Why fix two things rather than twenty?

In short

The method is one person, one real task, and your silence. Most failed tests failed because the moderator talked.
Five users find ~85% of problems — per segment, for finding problems rather than measuring, and better as three rounds of five.
Tasks state a goal with realistic context and contain no interface vocabulary.
Thinking aloud slows people slightly and is still the best window into their reasoning; prompt with "what are you thinking," never "why did you do that."
Don't help, don't explain, don't lead, say you didn't design it, and watch hands over words.
Record success, the exact stall, verbatim quotes, expectations and severity — not "the user was confused."
Cheap complements: hallway tests, five-second tests, first-click tests, heuristic evaluation, A/B for "which" but never "why."
Fix two things, then test again. One round is an opinion; three is a process.