Most design decisions made in a conference room are guesses. A usability test turns those guesses into evidence, and it doesn’t take a research lab to run one. Five participants and a clear task script will surface more real friction than a thousand user opinions.
What You’re Testing (and What You’re Not)
A usability test is not a focus group. You’re not asking participants whether they like the design or what they’d want instead. You’re watching them try to complete a task, and noting where they succeed, where they hesitate, and where they give up.
That distinction matters for how you write tasks. Tasks are scenario-based instructions, not leading questions. “Find out how much the standard plan costs” is a task. “Is the pricing page easy to understand?” is not. The first reveals behaviour. The second invites opinion and gets you nothing useful.
A single test session typically covers three to five tasks. More than that and fatigue degrades what you observe in the later tasks.
Writing the Test Plan
A test plan is a short document, one to two pages, that commits everyone to the same scope before a single session happens. It should cover:
- Research questions. What do you need to know? “Can new users find and complete the checkout flow without assistance?” is a research question. “How do users feel about the checkout?” is not.
- Tasks and scenarios. Each task maps to a research question. Write the scenario in plain language that gives context without naming the interface element. “You want to buy one item as a gift and have it shipped to a different address” is better than “Use the checkout page to complete a purchase with a separate shipping address.”
- Participant criteria. Who counts as your target user? Role, prior product experience, technical comfort level. Be specific enough that you can evaluate candidates against it.
- Method. Moderated or unmoderated? Remote or in-person? What tools will you use to record or observe?
- What success looks like. Define this before the sessions so you can’t unconsciously shift the goalposts afterward.
If you’ve already mapped out your user flows and journey maps, this step goes faster. Those maps document the paths users are supposed to take, which makes them a natural foundation for task scripts.
Recruiting Participants
Five participants is the classic number for moderated qualitative testing. It’s not a hard rule, but it holds up well in practice. By session four or five, you’re usually hearing the same friction points repeated. Diminishing returns set in quickly.
The harder challenge is recruiting people who actually match your user criteria. For B2B products, this often means pulling from a CRM, working through a sales contact, or using a specialised panel provider. For consumer products, you have more options but also more noise.
Screen candidates with two or three qualifying questions before confirming them. Watch for participants who work in UX (they moderate their own behaviour), people who’ve never encountered any similar product unless that’s genuinely your target, or people who are unusually eager to please. All three patterns produce data that doesn’t represent your actual users.
Running the Session
A moderated session has a shape. Open by explaining that you’re testing the product, not the participant. Say it clearly: there are no wrong answers, and errors reveal where the design needs work, not where the person failed. This matters because participants who feel evaluated perform differently from participants who feel like collaborators.
Give each task as a written scenario rather than reading it aloud. Reading introduces tone variations that can unintentionally steer the participant toward or away from a response.
During the task, say as little as possible. Silence is hard, but it’s the job. When a participant hesitates for more than a few seconds, resist the instinct to help. Ask “What are you thinking right now?” or “What would you expect to happen here?” rather than directing them toward the answer.
The moderator’s job is not to make the session go smoothly. It’s to make the session reveal what would actually happen without you in the room.
Keep notes structured around observations, not interpretations. “The participant clicked the secondary button instead of the primary and then said ‘I wasn’t sure what that did’” is an observation. “The participant was confused by the CTA” is already an interpretation and will shape your analysis prematurely.
This skill builds with practice. UX research methods covers the broader toolkit, including when to reach for usability testing versus other methods.
Synthesising What You Observed
Raw notes are not findings. Synthesis is the step where you look across all sessions, identify patterns, and form conclusions that can drive decisions.
A practical synthesis process:
- Write each observation on a separate note (physical or digital).
- Cluster notes that represent the same friction point or behaviour.
- Name each cluster with a neutral description: “Users read the headline but don’t scroll to the feature list.”
- For each cluster, ask whether it’s a design problem, a content problem, or a task-writing problem.
That last question gets skipped often. Sometimes a cluster reveals that your task scenario was ambiguous, not that the product is broken. Separating design problems from methodology problems keeps your recommendations honest.
Severity rating helps prioritise. A friction point that caused task failure in four of five sessions is a different order of urgency from one that caused a slight hesitation in two. You don’t need a formal scoring system, but you do need some sense of frequency and impact before you walk into a debrief.
Turning Findings Into Decisions
A usability test report without recommendations is just an observation report. Useful, but incomplete.
For each finding, state the problem, the evidence, and a suggested direction. Not a final solution. “Three of five participants didn’t realise the filter bar was scrollable. Consider adding a scroll indicator or reducing the number of default filters visible.” That’s something a designer can act on. “Users had trouble with filters” is not.
Prioritise by the combination of severity and effort to fix. A high-severity finding that takes a day to address should move faster than a medium-severity finding that requires a structural redesign. This is where design sprints earn their keep: they give you a structured format for rapidly prototyping and testing solutions to critical findings before committing to a full build.
Avoid treating every finding as equally urgent. Teams that try to fix everything between test rounds often ship nothing. Pick the two or three changes that will have the most impact on task completion, fix those, and test again.
How Strynal Approaches Usability Testing
At Strynal, usability testing is part of how we build confidence in a design before it goes to production. Our UI/UX service includes research planning, session moderation, and synthesis as standard parts of the design process because we’ve seen what happens when teams ship interfaces that haven’t been tested with real users.
We’re pragmatic about scope. Not every project warrants a full research programme. Sometimes five sessions and a clear findings document are enough to answer the critical questions. Sometimes one round of testing mid-design is more valuable than three rounds at the end. We size the research to the decisions that actually need to be made.
If your team is shipping work that hasn’t been tested with users, or you’ve run sessions and struggled to turn the findings into action, get in touch and we can help structure what that process looks like for your project.