Usability testing is the most direct research method there is: you give a real person a real task and watch what happens. No proxy metrics, no opinions about a mockup, just the moment someone tries to use the thing and either flows through it or gets stuck. This guide covers how to plan, run, and make sense of a usability test, so the sessions earn their place in the roadmap.
What usability testing actually is
A usability test puts a participant in front of a product, or a prototype, and asks them to complete realistic tasks while you observe. You are not asking "do you like this?" You are watching whether they can do the thing, where they hesitate, and where they go wrong.
It answers a specific kind of question: can people use this, and where does it break down? It is an evaluative method, best used once you have a design to put in front of someone, not for open ended discovery. If you are not yet sure usability testing is the right tool for your question, start with how to choose a UX research method.
Moderated or unmoderated
The first decision is whether you will be in the room.
Moderated testing means you guide the session live, in person or over a call. You can probe ("what made you pause there?"), adapt, and catch the unexpected. It is richer and slower, and it is the right choice for complex flows or early, rough prototypes.
Unmoderated testing means participants complete tasks on their own, usually through a tool that records their screen and voice. It is faster, cheaper, and scales well. It is the right choice for simpler, well defined tasks where you do not need to ask follow ups.
Many teams use both: unmoderated to cover breadth quickly, moderated when they need to understand the why behind a problem.
How many participants you need
This is the most asked question in usability testing, and the answer surprises people: you need fewer than you think.
For most qualitative usability tests, five to eight participants per distinct user group will surface the large majority of serious issues. The reason is that usability problems are not evenly distributed; the big ones tend to trip up almost everyone, so they show up in the first few sessions. The popular "five users" guideline, associated with Nielsen Norman Group, comes from exactly this observation.
A caveat worth holding: five users finds most major problems, not all problems, and not subtle ones. If you have genuinely different user groups, test five or so within each group rather than five across all of them.
Writing good tasks
The task is where most usability tests are won or lost. Two rules carry most of the weight.
Describe a goal, not a click path. "Find a winter coat under 100 pounds and add it to your basket" is a good task. "Click the menu, then click coats, then filter by price" is not a task, it is an instruction, and it tests nothing.
Make it realistic and let them fail. Use scenarios close to why someone would really use the product. Resist the urge to rescue people the moment they struggle; the struggle is the data. Stay quiet, count to ten in your head, and let the moment play out.
A few more habits that help:
- Start with an easy task to build confidence
- Keep tasks independent where you can, so a failure on one does not poison the next
- Avoid leading language that hints at the answer ("use the handy filter")
Running the session
A clean usability session has a shape:
- Warm up. Put the participant at ease. Remind them you are testing the product, not them, and that there are no wrong answers.
- Encourage thinking aloud. Ask them to narrate what they are looking at and expecting. This "think aloud" protocol is the heart of the method: it turns a silent click into a window onto their reasoning.
- Give one task at a time. Hand over the task, then get out of the way. Note where they hesitate, what they say, where they go.
- Probe after, not during. Save your "what were you expecting there?" questions for the end of a task, so you do not contaminate the attempt.
- Wrap up. A couple of open questions about the overall experience, then thank them.
Resist the two classic moderator sins: helping too soon, and asking leading questions. Your job is to be a calm, curious, slightly boring presence.
Making sense of what you saw
Raw sessions are not findings. After testing, you synthesise.
- Capture observations as you go, ideally with timestamps, separating what happened (behaviour) from what you think it means (interpretation).
- Group issues by where they occurred and how severe they were. A useful severity lens: how many people hit it, and how badly it blocked them. A problem that stops everyone from checking out outranks a cosmetic confusion one person shrugged off.
- Prioritise ruthlessly. Not every observation deserves a ticket. Lead with the issues that block real tasks.
If you are grouping observations across several sessions, affinity mapping is the workhorse technique for turning a pile of notes into clear themes.
Common mistakes to avoid
- Testing too late. A usability test after the build is shipped is an autopsy. Test on a prototype, while you can still change things.
- Confusing liking with usability. "They said it looked nice" is not a success. Did they complete the task?
- Over recruiting the wrong people. Eight perfect participants beat twenty random ones. Screen for the behaviour that matters.
- Treating it as a one off. Usability testing works best as a habit, small and frequent, not a single grand event.
The quiet superpower
Usability testing's real value is not the list of issues it produces. It is what happens when a product owner watches a real person fail at something they were sure was obvious. That moment changes minds in a way no report ever does. Get stakeholders watching sessions, even one, and your findings stop being your opinion and start being something the whole team saw with their own eyes.
People of Research is a community and newsletter for UX researchers, behavioural scientists, and everyone who learns by watching real people use real things. Join us and get the good stuff in your inbox.