What is usability testing?
In a usability test, a participant attempts a task while a researcher observes what happens. You can learn where someone hesitates, misinterprets a label, misses feedback, or cannot recover from a failure. The aim is to understand the interaction well enough to make a better product decision.
Nielsen Norman Group's introduction describes the main elements as a facilitator, tasks, and a participant. This guide applies that structure to a small fictional SaaS study. The resources include an original session script and a synthetic observation log; no real participant research was conducted for the worked example.
Use a customer interview to understand someone's situation and past experience. Use a usability test to observe an attempt with a particular interface. Both can inform product discovery, but asking someone whether they like a proposed feature is different from watching them try to complete a task.
Choose a decision and a realistic task
Begin with the decision you need to make. Our fictional reporting app wants to know whether an agency operator can find and create a client-specific export without help. The study is intended to inform labels, selection controls, and completion feedback before a wider pilot.
Write the starting situation and intended result in the participant's language. The example prompt says: You are preparing the monthly update for Client A. Save a file containing only that client's rows so you can send it to them later. It does not name the filter control or tell the participant where to click.
Prepare a safe test account with clearly fictional data, a known starting state, and an expected result. Check the task yourself to confirm it is possible, then reset the account before the session. If the prototype cannot complete an operation, define how you will handle that limitation without treating it as participant error.
| Task | What the observer watches |
|---|---|
| Save a file containing only Client A's rows | Whether the participant finds the selection and recognizes the export result |
| Check which client is included before saving | Whether the scope of the export is understandable |
| Continue after a simulated export failure | Whether the participant notices the failure and can choose a useful next action |
Recruit people whose work matches the task
Define relevant experience before recruiting. For this example, the participant should prepare recurring client reports and understand what information belongs to each client. A friend who knows the founder's interface may be convenient but may not reveal the same questions as a new agency operator.
Recruit for the variation that affects the decision: first-time versus returning use, role, device, or accessibility needs. Choose a manageable initial round and review what you learn before expanding. There is no universal participant count that makes every task, audience, or risk adequately studied.
Be clear about the purpose, expected time, recording, who can see the material, and whether any compensation is offered. Obtain appropriate consent before recording and give the participant a way to stop. Use the beta recruitment guide for relevant invitations while keeping research participation distinct from a promise to buy.
Use a moderator script that leaves room for discovery
Explain that you are evaluating the product and that difficulties are useful observations. Invite the participant to say what they are looking for or expecting. Read one task at a time and let them attempt it without immediately correcting their path.
Use neutral follow-ups such as What are you looking for now? or What did you expect to happen? Avoid leading prompts that reveal the control or praise a particular route. If help becomes necessary, record what you said and mark the remainder of the attempt as assisted.
Agree a stopping rule in advance: the participant says they would give up, the task reaches the planned time boundary, or continuing would create an inappropriate burden. Stop or move on respectfully. A participant's struggle is information about the task and interface, not a reason to pressure them into finishing.
After the attempt, ask about expectations and the result. Do not interpret a friendly comment as proof that the task was easy. A person may report that everything looks fine after needing several prompts; retain both observations.
Record behavior separately from interpretation
The observation log has separate fields for what happened, the participant's words when relevant, an interpretation, an outcome, and the next check. Use participant codes instead of names in the working log. Capture only the data needed for the study and follow the agreed access and retention rules.
In the fictional example, P01 opens the report menu twice and asks whether Export includes every client. That is the observation. The interpretation is that export scope may be unclear. A proposed label change is an idea to test, not a finding that has already been validated.
The task outcome is also specific: P01 completes the download only after a moderator prompt, so the row says assisted completion. P02 completes it independently. P03 stops after a simulated failure. These three invented sessions demonstrate recording conventions; they cannot estimate how common each issue is among real customers.
Turn observations into a bounded product decision
Group observations by the part of the task they affect. Separate unclear scope, a hidden control, and missing failure feedback even if they occur during the same workflow. For each issue, describe the consequence, the evidence, and uncertainty about its cause.
The fictional team chooses to make the selected client visible beside the export action and clarify the error message. It then plans another round with relevant participants. That is a proposed response to the observations, not evidence that the revised interface improves completion.
Prioritize using the effect on the task and the confidence in the observation. One severe failure can deserve investigation even when it appears once. Conversely, counting every hesitation as an equally important defect can produce busywork. Keep design preferences separate from barriers to the intended result.
Use conversion optimization when the investigation concerns a broader journey. A small qualitative study can identify problems and possible explanations; it does not establish a population conversion rate or the causal effect of a redesign.
Download the script and run a small first round
The text download contains a study brief, recruitment criteria, consent discussion prompts, a moderator introduction, the three original tasks, neutral follow-ups, stopping rules, and a debrief. The CSV contains the fictional observations plus blank rows for your own permitted notes.
Adapt the script to the interface and decision before inviting anyone. Pilot it with a colleague to catch impossible tasks and accidental clues, then reset the account. At the end of each session, save the evidence securely, record what remains uncertain, and choose the next investigation. Source and resources checked October 27, 2026.