How to Run Usability Testing with 5 Users: A Practical Guide

In this guide, we at Talha Aslan and team walk you through the process we use on web projects. First, we explain the math behind the 5-user rule. Then we cover task scenarios, the think-aloud method, remote sessions, and how to prioritize findings. Finally, you get a checklist you can print and keep on your desk.

In short, the goal is not an academic study. Instead, we want to help you set up a test routine that fits a small budget, runs in one week, and feeds design decisions directly. If you want the bigger picture first, read our guide to what UX covers.

What math sits behind the 5-user rule?

The rule comes from a simple formula based on research by Jakob Nielsen and Tom Landauer. In Nielsen Norman Group's article on testing with 5 users, the number of problems found equals N × (1 − (1 − L)^n). Here N stands for the total number of problems, and n for the number of users.

L is the share of problems a single user uncovers. The article gives a typical value of 31 percent. So one user alone shows roughly a third of the problems. A second user adds some new issues. However, that person also repeats much of what the first one showed.

Example calculation: with L at 0.31, five users give 1 − 0.69^5, which is about 0.84. In other words, five participants surface roughly 85 percent of the problems in that design. Nielsen Norman Group cites the same 85 percent figure. That said, it is an average, and your own project may land higher or lower.

One point matters most. The rule does not say "test 5 people and stop." Instead, it tells you to spend the same budget on several small rounds. The next section explains why.

Why run three small rounds instead of one big test?

Nielsen Norman Group suggests splitting a budget for 15 participants into three studies with 5 users each. The first round finds most of the problems. Next, you fix the design and run a second round to check whether the fixes actually work. Finally, a third round catches the issues the first round missed.

The logic is simple. A test exists to improve the design, not to document problems. Moreover, a fix sometimes creates a new problem. For example, renaming a menu label can break consistency on another page. A second round shows side effects like this early.

Example scenario: a service company has a three-step quote form. In round one, four of five people get stuck on the required fields in step two. The team simplifies the fields, and the issue disappears in round two. However, the message on the confirmation screen now confuses people. Round three confirms the flow works once the team rewrites that message.

Put simply, small rounds are a natural part of iterative design. Testing 15 people at once, on the other hand, can mean watching the same problem ten times.

When is the 5-user rule not enough?

The rule works when your audience is fairly similar. If your site serves very different groups, you need to test each group on its own. Nielsen Norman Group uses children and parents as an example of such distinct groups.

According to the same article, two distinct groups need 3 to 4 users each. With three or more groups, plan at least 3 users per group. That way, you still see the range of behavior inside each group. For instance, on a B2B site a purchasing manager and a technical evaluator arrive with very different questions.

In addition, some methods need a larger sample:

• Quantitative studies: If you want to compare task time or success rate statistically, Nielsen Norman Group recommends about 20 users.
• Card sorting: For studies where users group your menu and category labels, the recommendation is about 15 users.
• A/B tests: Comparisons with live traffic follow a different logic from qualitative testing and need far more sessions.

So use the 5-user rule for qualitative, discovery-focused tests. Then answer "which version converts better?" with a different method.

What goal should you set before usability testing starts?

Every round of usability testing should start with one clear question. "Is the site good?" is too broad. A test that tries to measure everything shows nothing in depth. Instead, pick a concrete question tied to a business goal.

For example, questions like these work well:

• Can visitors get from the service page to the quote form easily?
• Do the product filters help users find the item they want?
• Is the mobile checkout simple enough to finish with one hand?
• Is the new menu structure clearer than the old one?

After you write the goal, define a success criterion. For instance, "did the participant finish the task without help?" is simple but powerful. Also note which pages fall outside the scope. As a result, you stay focused during sessions.

Next, connect the goal with your conversion targets. If you track the share of visitors who submit a form, our conversion rate calculator helps you compare numbers before and after the changes. Still, keep in mind that a test finding is qualitative, while conversion data offers quantitative confirmation.

How should you recruit participants?

The right participants deliver half of the result. Nielsen Norman Group's article on thinking aloud states the basic rule plainly: recruit representative users, give them representative tasks, and then mostly keep quiet.

In practice, we suggest these criteria:

• Audience fit: Participants should resemble your real visitors. If you sell accounting software, recruit people who deal with accounting.
• Distance from the team: Colleagues, family members, and anyone who has seen the design will skew the results.
• Mixed digital skills: If everyone is a power user, you will miss basic problems.
• Device match: If most traffic comes from mobile, run most sessions on mobile too.

You can invite participants from your customer list, newsletter subscribers, or social media followers. In that case, prepare a privacy notice and get consent before the session. Also, a small thank-you gift for their time tends to raise turnout.

Example scenario: a school plans a test for two groups, parents and students. Following the rule, it recruits 3 to 4 people from each group and tests them on separate days.

How do you write a good task scenario?

A task scenario is a short story that tells participants what to do. Nielsen Norman Group's guide to task scenarios lists three core principles. A scenario should be realistic and actionable, and it should not give away the answer.

Realistic: Do not ask participants to do something they would never do. For example, instead of asking them to buy a product they have no interest in, give them a price limit they would really use. Then they make their own choices.

Actionable: Do not ask "how would you do this?" Instead, ask them to actually do it. People's words often differ from their actions, and talking through steps hides real friction.

No clues: Leave menu names, button labels, and step lists out of the scenario. If you repeat interface wording, you never learn whether the labels make sense. That said, avoiding clues does not mean being vague. Give people the information they need, but do not tell them where to click.

Three to six tasks usually fill one session. Start with an easy task so the participant can warm up. Then place your most critical task in the middle, because people feel relaxed by then and are not tired yet.

What separates a weak task scenario from a strong one?

To make the difference concrete, we placed weak and strong scenarios for the same goal side by side. The examples come from sample scenarios we wrote for a corporate service site.

As you can see, strong scenarios give people a reason and an end point. They also avoid interface wording. This way, you see how participants interpret your site in their own words.

Once you write the scenarios, try them with a colleague. If the reader asks "what exactly do you want?", simplify the text. For more help with wording, our guide to UX writing and microcopy offers practical examples.

How does the think-aloud method work?

In a think-aloud session, participants say out loud what goes through their minds while they use the interface. Jakob Nielsen calls it possibly the single most valuable usability engineering method. The reason is clear: it shows directly what users misunderstand and why.

The method has real strengths. It needs no special equipment, it is easy to learn, and even an imperfect study usually yields useful findings. Moreover, it persuades skeptics on your team. When a manager watches a customer struggle with a form, that moment does more than a long report.

However, the method has limits too. Talking nonstop feels unnatural to most people. Some participants filter their thoughts to look smart. In addition, prompts from an untrained facilitator can change behavior. Because the method is qualitative, it also does not support detailed statistics.

To reduce these limits, show a short demo at the start. For example, a 30-second clip where you think aloud while browsing a weather site works fine. Then the participant knows what you expect and speaks more freely.

How should a facilitator run the session?

The facilitator's main job is to keep people talking without steering them. That sounds easy. In practice, though, it is the hardest skill of all, because people naturally want to help.

During the session, we recommend these rules:

1. When the participant gets stuck, do not jump in. First, ask a neutral question such as "What are you thinking right now?"
2. If the participant goes quiet, remind them gently: "Please keep telling me what you think."
3. Avoid leading questions such as "Is this button confusing?"
4. Answer questions with a question: "What do you think should happen?"
5. Do not defend the design. Criticism is the most valuable data a test produces.
6. Note any moment where your prompts may have shaped behavior, and treat those parts separately in the analysis.

Also, tell the participant clearly at the start that you are testing the site, not them. This sentence keeps people from feeling embarrassed when they make mistakes. As a result, you get more honest reactions.

How long should a session take and what should the flow look like?

Our starting range, based on field experience, is 30 to 60 minutes per session. It is not a rule, just a planning baseline. In longer sessions, attention drops and data from the last tasks gets weaker.

Here is a sample flow we use:

1. Welcome (5 minutes): Thanks, recording consent, and the "we are testing the site, not you" note.
2. Warm-up questions (5 minutes): A few questions about how the participant uses similar sites.
3. Think-aloud demo (2 minutes): A short example from the facilitator.
4. Tasks (25 to 35 minutes): Three to six tasks, each on its own card or in its own message.
5. Wrap-up questions (5 minutes): Overall impression, plus the hardest and easiest moments.
6. Close (3 minutes): Thanks and a small gift, if you offer one.

Leave at least 15 to 30 minutes between sessions. You need that time to sort your notes and reset the setup for the next person. For instance, clearing browser history and deleting test form entries fits into this gap.

You can finish five sessions in one day. Still, spreading them over two days often keeps the facilitator fresher.

What should observers watch for and how should you take notes?

Analysis gets much easier when one or two observers take notes while the facilitator runs the session. Nielsen Norman Group also suggests inviting team members to watch, because watching speeds up buy-in.

Observers should record events, not opinions. For example, instead of "the user hated the menu," write "the user opened and closed the menu three times and said 'I guess it isn't here.'" This difference cuts down on debate later.

A simple note template can use these columns: task number, time, what happened, participant quote, and task outcome. Mark the outcome with one of three options: finished without help, finished with difficulty, or did not finish.

After each session, hold a short 10-minute debrief. Everyone shares their three most striking observations. That way, you capture fresh memories. Also, if you record sessions, note timestamps for key moments, because short clips are very persuasive in a presentation.

How do you run remote usability testing?

In remote usability testing, the participant and the facilitator sit in different physical locations. Nielsen Norman Group's article on remote usability tests prefers in-person testing when possible. However, it also stresses that remote testing beats skipping testing altogether.

Any video call tool with screen sharing will do the job. What matters is technical preparation. Test the connection, the screen sharing, and the recording with a colleague first. Then send participants a short prep note.

Practical tips for remote sessions:

• Rehearse the technology and try sending links and tasks from both ends.
• Pilot your tasks first, because in an unmoderated session there is no safety net.
• Log in early and stay reachable by email or phone for participant questions.
• Recruit a few extra people, since no-show rates can run higher in remote studies.

Example scenario: a manufacturer that serves dealers in several cities wants to test its dealer portal. Instead of bringing dealers to the office, the team plans five remote sessions over video calls. As a result, dealers work on their own computers in their real work setting.

Should you choose moderated or unmoderated testing?

Remote testing comes in two main forms. In a moderated test, the facilitator watches live and talks with the participant. In an unmoderated test, the participant completes the tasks alone, on their own schedule, while software records the session.

Our advice: run the first round moderated. In the first round, you do not yet know what you do not know, so follow-up questions bring the best findings. Then, for later rounds that confirm fixes, unmoderated tests can save time.

On the other hand, whichever format you pick, always pilot the task text first. In unmoderated tests, this step matters even more.

How should you prioritize the findings?

After five sessions, you will hold dozens of observations. Fixing all of them at once is not realistic. Therefore, rate each problem by severity. Nielsen Norman Group's article on severity ratings suggests looking at three factors together: frequency, impact, and persistence.

Frequency means how many users hit the problem. Impact means how hard it is to get past. Persistence means whether users keep stumbling after they learn the workaround. In addition, an issue that is easy to overcome can still earn a higher rating if it hurts how people see the brand.

The article proposes this 0 to 4 scale:

• 0: I don't agree that this is a usability problem at all.
• 1: Cosmetic problem only; fix it only if extra time is available.
• 2: Minor usability problem; give the fix low priority.
• 3: Major usability problem; it is important to fix, so give it high priority.
• 4: Usability catastrophe; fix it before you release the product.

Have two or three team members rate the problems separately rather than one person. Then take the average. This way, one person's bias does not set the priority order.

How do you turn findings into design changes?

Once you finish rating, write an "observation, cause, recommendation" set for each important problem. The observation states what happened, the cause explains the source, and the recommendation describes the fix. For example: "4 of 5 people could not find the quote button; it sits under 'About' in the main menu; move it to the top level."

Watch out for two traps. First, avoid copying the fix a user suggests. Users point out problems well, but their solutions are not always right. Second, avoid trying to solve everything with one big redesign. Instead, choose small changes you can test.

Next, assign each recommendation to an owner and a date. If the report ends up in a drawer, the test was wasted. A short visual deck also gets read more than a long document. One screenshot and a short video clip per finding is enough.

If your findings call for a broader review, use the systematic steps in our article on how to run a UX audit. Usability testing shows real behavior, while an expert audit scans the whole site against known principles.

What are the most common mistakes in usability testing?

Over the years, most mistakes we have seen come from execution, not from the method itself. Here are the ones we run into most:

• Recruiting from the team: People who know the design never feel the confusion a new visitor feels.
• Giving clues in scenarios: Naming the button in the task hides label problems.
• A helpful facilitator: Jumping in when someone gets stuck erases your most valuable data.
• Testing too late: Changes after launch cost more, while early prototype tests cost less.
• Stopping after one round: You never learn whether your fixes worked.
• Forgetting accessibility: Consider including participants who use screen readers or keyboards.

On that last point, accessibility is a specialty of its own and builds on the WCAG guidelines. You can find the basics in our article on web accessibility and WCAG standards.

Also, if you wonder how these problems affect revenue, see our article on UX mistakes that kill sales.

Can you run usability testing on a prototype?

Yes, and often this is the most productive time to do it. The think-aloud method works at any stage of development and for most interface types. So you can test everything from a paper sketch to a clickable prototype.

The biggest advantage of early testing is cost. Changing the menu in a prototype takes minutes. On a live site, the same change also affects content, redirects, and search engine settings. For this reason, when our design team starts a new project, we plan the first test round on the prototype.

In a prototype test, tell participants it is not a finished site. Mention up front that some links may not work. However, the flow for each task you test must be clickable from start to finish. Otherwise, people keep landing on empty screens and the test loses its meaning.

If you want test rounds built into a new site project, our web design service includes prototype testing as part of the plan. That way, real users try the design before it goes live.

Usability testing checklist

Review this list before every test round. We suggest you do not start sessions until you can tick every item.

Preparation

• A one-sentence goal and a success criterion are on paper.
• User groups are clear: 5 people for one group, or 3 to 4 per group for several.
• Participants come from outside the team and match the audience.
• Privacy notice, recording consent, and a thank-you gift are ready.
• Three to six task scenarios avoid interface wording and step lists.
• A colleague tried the scenarios in a pilot session.

Session day

• Device, browser, and recording setup start from a clean state.
• The participant knows we test the site, not them.
• A short think-aloud demo opens the session.
• Leading questions stay out, and every intervention goes into the notes.
• A 10-minute debrief follows each session.

Analysis

• Each problem has a rating for frequency, impact, and persistence.
• At least two people scored each problem on the 0 to 4 scale.
• Every important problem has an observation, cause, and recommendation.
• Each fix has an owner and a date.
• The second test round sits on the calendar.

When should you bring in outside help for usability testing?

Your own team can run a small round of usability testing with ease. After all, you can learn the basics of the think-aloud method in a day. Still, in some cases outside support speeds things up.

For example, outside help makes sense when your design team finds it hard to judge its own work. It also helps when you must manage several user groups, or when you need a team that turns findings straight into a new design. Moreover, an experienced facilitator knows how to keep people talking without steering them.

At Talha Aslan and team, we build test rounds into the design flow of web projects: prototype, first round, fixes, second round. If you want to set up this process for your site, tell us about your project and request a quote on our web design services page. For conversion ideas after testing, our guide to the CRO process for business websites is a good next read.

In short, good testing needs a steady habit more than a big budget. Five users, well-written scenarios, and honest prioritization make your design a little stronger with every round.