How to Run a Five-Person Usability Test, Step by Step

Why five participants, and when that is not enough

Five participants per round is a practical default, not a magic number. The idea comes from a problem-discovery model published by Jakob Nielsen and Thomas Landauer in 1993, and the arithmetic is easy to follow. If a problem affects about a third of users, the chance that at least one of five participants runs into it is 1 − (2/3)⁵, or about 87 percent. If it affects one user in ten, the chance falls to about 41 percent.

So five people reliably surface the common problems and can easily miss rarer ones. That is why the method works best as a series of small rounds: test, fix the worst issues, then test again with five new people. If you need to compare designs statistically, measure rare errors or cover several very different user groups, you will need more participants.

Plan the test and recruit the right people

Write a one-page plan before recruiting. It should state the decision the test will inform, two to four research questions, who you need, the tasks, what counts as success for each task and what you will measure. Typical measures are task success, time on task and the number of errors or requests for help. Keep each session to 45 to 60 minutes.

Recruit on recent behaviour rather than demographics: “has booked a service online in the last six months” is more useful than an age range. Use a short screener that does not reveal which answers qualify, avoid friends and colleagues, offer a fair incentive and book a reserve participant, because no-shows happen. Explain recording and data storage before anyone agrees to take part.

Write realistic tasks

Tasks are the heart of the test. Write them as short scenarios with a goal, and avoid the words used in the interface, or you will be testing whether people can match labels rather than whether they understand the design. Avoid tasks such as “Use the Reschedule button to change your booking”, which gives the answer away, and questions such as “What do you think of this page?”, which ask for opinions rather than behaviour. Order tasks from easiest to hardest and define success before the first session.

Three to five tasks fit comfortably into a 45 to 60 minute session, leaving time for the introduction and closing questions. Base them on the jobs people most need to complete, not on the screens you are proudest of, and include at least one task you suspect will cause trouble, because that is where the test earns its cost.

Prepare the prototype and the script

Make sure every task has a complete path through the prototype, including the most likely wrong turns, and give every plausible tap a response so nobody hits a dead end. Run a pilot session with one person outside the team; it often reveals a broken link or a confusing task. Use the same script for every participant so that sessions are comparable.

Decide on the setup in advance. In person, a quiet room, the kind of device participants normally use and a seat for the note-taker are enough. Remotely, a video call with screen sharing works for most screen-based products; send the link and any instructions the day before, and allow five spare minutes for technical problems.

Run the sessions without helping

The moderator’s job is to stay neutral. When participants ask whether they should tap something, reply with a question such as “What would you do if I weren’t here?” Do not hint, explain or rescue unless someone is completely stuck, and if you do step in, record the task as failed. Remind people gently to keep thinking aloud when they fall silent.

A second person should take notes on a shared sheet, recording what the participant did, what they said and where they hesitated, with timestamps. Straight after each session, spend ten minutes together listing the issues you saw while memories are fresh. Avoid asking whether people liked the design; politeness makes those answers unreliable, and behaviour tells you far more.

• Tasks that contain the answer in their wording
• Rescuing participants at the first sign of hesitation
• Explaining or defending the design during the session
• Testing with colleagues who already know the product

Turn notes into prioritised findings

After the five sessions, merge the debrief lists into one table with a row per problem: where it happened, what participants did, how many of the five encountered it and a representative quote or behaviour. Rate each issue for severity on a scale from 0, not a problem, to 4, blocks the task, considering how many people it affected and whether they could recover.

For each serious issue, write a fix that addresses the cause, not just the symptom: if people missed a button because they did not expect that action on that screen, making the button bigger will not help. Fix high-severity, low-effort issues first, share a one-page summary with short clips, and record what worked well so nobody changes it by accident.

Test again

Run a second round with five new participants on the same tasks, plus any new ones, to check that the fixes worked and did not create new problems. Compare task success between rounds, but treat small-sample numbers as indicators rather than statistics. Many flows need two or three rounds before they work smoothly. Stop iterating on a flow once people complete the priority tasks without help. The UX Basics: From Research to Prototype course covers the full cycle, from recruiting and interviews to prototypes and repeated rounds of testing.