How to Run a Usability Testing Session

A usability testing session watches a real person try to complete a specific task in your product, while you observe exactly where they hesitate, get confused, or fail — revealing friction that's often invisible to the team who built the product and already knows how it's supposed to work. Done well, it's one of the fastest ways to catch real usability problems before they affect your full user base.

Quick facts

• The core method: give a real person a specific task, watch them attempt it, and note exactly where they struggle.
• Usability testing reveals task success, distinct from Happiness — someone can eventually complete a task while still finding it frustrating.
• A moderator should observe and take notes without helping, even when watching someone struggle — intervening defeats the purpose of the test.
• 5 participants often reveal the majority of major usability problems, according to widely cited usability research.

How to run a usability testing session, step by step

1. Define specific, realistic tasks, not vague instructions. "Try to invite a teammate to your workspace" is testable; "explore the app" is too open-ended to reveal much about a specific flow.
2. Recruit participants who genuinely represent your target user, not just colleagues or people conveniently available, who may already have insider knowledge that skews their behavior.
3. Prepare a simple script with the tasks, in order, plus a few open-ended questions to ask afterward.
4. Observe without helping, even when a participant visibly struggles. Providing a hint the moment someone hesitates defeats the entire purpose — real users won't have a moderator standing by to help them.
5. Take detailed notes on exactly where confusion or failure happens, not just whether the task was ultimately completed. The specific point of struggle is usually more informative than the final outcome.
6. Ask open-ended follow-up questions after each task, like "what were you expecting to happen there?" — this reveals the reasoning behind an observed struggle, not just that it happened.
7. Synthesize findings across multiple sessions, looking for patterns rather than treating any single participant's experience as definitive.

Why observing without helping is so important

It's genuinely difficult to watch someone struggle with something your team built without wanting to jump in and help — but doing so erases exactly the information the test is designed to reveal. A real user in production won't have someone standing by to clarify confusing wording or point out a hidden button. If a moderator repeatedly intervenes, the resulting session tells you very little about how the product actually performs for someone using it unsupported.

A worked example: testing a checkout flow

Task given to participant: "You'd like to buy this item and have it shipped to a friend's address instead of your own. Please complete the purchase."

What the moderator observes: The participant successfully adds the item to cart, but hesitates for nearly 30 seconds at the shipping address step, eventually clicking on a small, easy-to-miss "ship to a different address" link they almost didn't notice.

Follow-up question: "What were you looking for when you paused there?"

Participant's answer: "I expected there to be an obvious button to change the shipping address, not a small text link buried under the main form."

This single observation — a specific, real point of confusion, plus the reasoning behind it — is far more actionable than a survey question asking generally "how easy was checkout?" would have revealed, since it pinpoints exactly what to fix and why.

How many participants are actually needed

Widely cited usability research (originating from Jakob Nielsen) suggests that testing with just 5 participants typically reveals around 80% of major usability problems in a given flow, with diminishing returns from additional participants for a single round of testing. This makes usability testing relatively fast and cheap to run regularly, rather than needing a large, expensive study every time — running smaller, more frequent tests is often more valuable than occasional large ones.

Common mistakes when running usability tests

• Helping participants when they struggle, erasing the exact signal the test is meant to capture.
• Giving vague, open-ended tasks that don't test a specific, real flow clearly enough to reveal actionable friction points.
• Recruiting participants who aren't representative of real target users, like colleagues who already understand the product's internal logic.
• Only noting whether a task succeeded or failed, without capturing where and why the struggle happened. The specific point of confusion is usually more useful than the binary outcome.
• Drawing firm conclusions from a single participant's session. Look for patterns across multiple sessions before treating an observation as a real, general problem.

FAQ

How long does a usability testing session typically take? Most sessions run 30-60 minutes, covering a handful of specific tasks — longer sessions risk participant fatigue, which can affect the quality of later-task observations.

Should usability testing be moderated or unmoderated? Moderated sessions (where a researcher is present, live or via video call) allow real-time follow-up questions and richer observation; unmoderated sessions (where a participant completes tasks independently, often recorded) are faster and cheaper to run at scale but capture less nuance — both have a place depending on your goals and resources.

Can usability testing be done on a low-fidelity prototype, or does it need a finished product? It can and often should be done on a low-fidelity prototype or even paper mockup — catching usability problems before significant engineering investment is one of the main benefits of testing early, rather than waiting for a fully built product.

How is usability testing different from a user interview? A user interview asks people to describe their experiences and needs in conversation. Usability testing observes them actually attempting a specific task in real time — the two methods reveal different things and work well together, often within the same research session.