How to Run a Usability Test With Five Users

Usability testing means watching real people try to complete real tasks with your product while you stay quiet. You do not ask what they like. You watch where they hesitate, misread or give up. Five participants is a common starting size because many of the biggest problems show up repeatedly in the first few sessions. Nielsen Norman Group has written about this approach for years, and the logic is practical: after a handful of sessions you are mostly watching the same problems again, so it is better to fix and test again than to keep recruiting.

That does not mean five users prove anything statistically. A five-person test finds problems. It does not measure how often they occur across your whole audience. Keep that distinction clear when you present results.

This guide covers the week-long plan we would follow: set the goal, write tasks, recruit, run the sessions, take notes, and synthesise.

Day 1: Decide what you are testing and why

Write one sentence: "We want to find out whether [type of user] can [do key thing] using [this design]." For example: "Can a first-time customer find a time slot and book a table on the mobile prototype?"

Then list two or three things you will do differently depending on what you learn. If no result would change a decision, the test is not needed yet.

Pick the thing to test:

• A clickable prototype (Figma or similar) is fine for early flows.
• A live build is better when interactions, speed or real data matter.
• A competitor's product is a useful way to learn what users expect before you design.

Day 1: Write the tasks

Good tasks describe a goal and a situation, not the interface. Compare:

• Weak: "Click the Book Now button and select a date."
• Better: "You are meeting two friends for dinner next Friday around 7 p.m. Book a table for three."

The weak version tells the participant where to click, so you learn nothing about whether they could find it. The better version leaves the path open.

Rules for tasks:

1. Use the participant's language, not your menu labels. If your nav says "Reservations" and you write "go to Reservations", you have given the answer.
2. Include any data they need on a card (a name, a date, a card number from a test set), so they are not inventing details.
3. Define what "done" looks like for each task before the session, so everyone scoring agrees.
4. Order tasks from common to rare, and put the most important one first while the participant is fresh.

Day 2: Recruit the right five

Recruit people who resemble your real users, not colleagues and not friends who will be polite. Write a short screener of three to five questions that qualifies or rules out a person. For a food-ordering app, you might ask how often they order delivery and which apps they use. Avoid revealing the "right" answer in the question.

If your product serves distinct groups, such as shop owners and customers, five of each group is not realistic for a small test. Pick the group whose failure hurts most and test them first.

Practical points:

• Ask for consent to record screen and audio, and explain how the recording will be used and who will see it. If you do not have consent, take notes only.
• Schedule sessions with a gap of 30 minutes between them so notes can be tidied.

Day 3: Prepare the script

A script keeps sessions comparable. Ours has five parts.

1. Welcome (2 minutes)

"Thanks for joining. We are testing the design, not you. You cannot do anything wrong, and if something is confusing, that is useful for us to know. Please think aloud as you go: say what you are looking at, what you expect, and what you are unsure about. I may not answer questions during the tasks, because I want to see what you would do on your own. Is it all right if we record this?"

2. Warm-up questions (3 to 5 minutes)

Ask about their habits related to the product area: "Tell me about the last time you booked a table online." Listen for vocabulary, tools and frustrations. Do not ask about the design yet.

3. Tasks (20 to 30 minutes)

Hand over each task one at a time. While they work:

• Stay quiet. Count to five before saying anything if there is a silence.
• If they ask "Should I click here?", reply "What would you do if I were not here?"
• If they are stuck for a long time, note the time and offer a small nudge, and mark that task as "needed help".
• Use neutral prompts: "What are you thinking?" "What did you expect to happen?"

Never defend the design or explain how it works during the task. That is the hardest habit to learn.

4. Wrap-up questions (5 minutes)

Ask: "What was the easiest part? What was the hardest? If you could change one thing, what would it be?" Then, if useful, a short rating question. A standard such as the System Usability Scale exists for this purpose and has a published scoring method. Use it only if you are going to compare scores over time, since five answers will not give a stable number.

5. Close

Thank them, confirm the incentive, and stop the recording.

Run one pilot session with a colleague first to catch unclear task wording.

Days 3 to 4: Run the sessions

Use a moderator and at least one note-taker. The moderator speaks to the participant. The note-taker writes down what happened. One person doing both misses details.

A note-taking sheet

Keep one row per task per participant:

Participant	Task	Completed? (yes / needed help / no)	Time	What they did	Quotes	Severity guess
P1	Book a table	Needed help	3:40	Looked in profile menu before finding date picker	"Where do I say how many people?"	Medium

Write observations, not interpretations. "Tapped the logo twice expecting to return home" is an observation. "User is confused by the logo" is a guess. Add a separate column for your interpretation if you want it, but do not mix them.

Day 5: Synthesise

After the fifth session, set aside two hours with the whole team that will act on the findings.

1. List every issue on its own sticky note or row, one observation each, with the participants who hit it.
2. Cluster notes that point to the same cause. "Could not find date picker" and "missed the guest count" may both come from the same layout problem.
3. Count how many of the five people hit each issue. Report it as "4 of 5", not as a percentage.
4. Rate severity with a simple scale:
   • Blocker: the participant could not complete the task.
   • Major: completed with significant difficulty or help.
   • Minor: noticed, slowed down, recovered alone.
5. Rank by severity first, frequency second. One blocker seen by two people usually matters more than a minor annoyance seen by all five.
6. Write a fix or a next step beside each cluster, and name an owner.

FAQ

Is five really enough?

For finding the main usability problems in one flow with one user group, it is a reasonable start. For comparing two designs with confidence, or measuring task times, you need a larger sample.

Can we test remotely?

Yes. Remote sessions over video call work well for most web and mobile prototypes. Ask the participant to share their screen, and for mobile, make sure the prototype link opens correctly on their device.

Talk to us

If you would like help planning or running a usability test, or turning the findings into design changes, we are glad to talk. Email hello@risingstation.com or visit risingstation.com/contact-us.