Usability testing is the practice of observing people attempt realistic tasks so you can understand where an interface helps or obstructs them. Learn to define a task, moderate without coaching, record behaviour, and turn findings into a specific revision. This roadmap uses a fictional library reservation prototype. The result should be an evidence-linked issue list and a tested improvement, not a claim that a small session proves the entire product is usable.
Write the research question and task
Ask whether a person can reserve an available book for collection at a chosen branch. Prepare a prototype with a search result, book details, branch selection, and confirmation. Use fictional accounts and records. Define success before the session: the participant reaches confirmation for the intended book and branch without the moderator telling them which control to use.
Write a scenario such as “You want to collect this book from the Riverside branch tomorrow; show what you would do.” Do not say “Click Reserve and choose Riverside,” because that supplies the route being tested. Nielsen Norman Group discusses realistic task scenarios that avoid giving away interface actions Source 1. Keep the scenario brief enough that the participant can remember the goal.
Prepare a session that protects the evidence
Explain that you are testing the design, not the person. Obtain informed agreement for participation and any recording. Use only fictional credentials, and keep notes free of unnecessary personal details. For a learning session, a short task with an optional recording is often sufficient. Make the participant comfortable stopping or asking for a break.
Pilot the prototype so broken links do not consume the session. Note which interactions are simulated and decide how you will respond if someone chooses an unsupported path. GOV.UK’s moderated-testing guidance describes watching people perform tasks and using their commentary to understand the experience Source 2. Keep your own explanation of the interface out of the task unless a technical failure requires intervention.
Prepare a note sheet with time, action, quote, outcome, and possible issue. Separate what happened from why you think it happened. A participant pausing at branch selection is observable; “they dislike dropdowns” is an interpretation that needs more evidence.
Observe a fictional failure and propose a repair
Use this invented practice observation: the participant finds the book, presses Reserve, and reaches confirmation without noticing that the default branch is Central. They expected Riverside. The task was not completed correctly, even though the interface displayed a success message. Record the wrong branch and the missed decision rather than calling the participant careless.
Propose an explicit branch choice before confirmation and a review summary that names the branch. This is a hypothesis about an improvement. Test it with a new attempt or another participant without explaining the change in advance. The expected result is a correct Riverside reservation and a clear account of where collection will happen.
Nielsen Norman Group’s introductory testing guidance distinguishes observing task behaviour from simply collecting opinions Source 3. A participant saying the page looks nice does not answer whether they chose the correct branch. Keep aesthetic feedback in a separate note if it is relevant, but prioritise evidence tied to the defined task.
Prioritise findings and report limitations
Describe each issue with location, observation, consequence, and suggested next action. Rank the wrong-branch issue above a minor alignment preference because it prevents the intended outcome. Consider severity and the evidence available; frequency in a tiny sample is not a population estimate. Avoid percentages that make a handful of sessions look statistically representative.
Create a before-and-after report with the task, original observation, design change, retest result, and unresolved questions. Include prototype limitations, recruitment details, and moderator interventions. If you only practised with fictional notes, label the whole analysis a simulation and do not claim that real participants validated the design.
The next learning step is another task with a different failure mode, such as no available copies or changing a reservation. Keep tests focused so you can explain which change addressed which problem. A long list of vague usability recommendations is less useful than one well-evidenced issue that leads to a clear, checked improvement.
- DefineSet the task and success criterion.
- ObserveWatch behaviour without directing the route.
- DiagnoseConnect the issue with its task consequence.
- RetestCheck whether a targeted revision helps.
| Checkpoint | What to produce | How to review it |
|---|---|---|
| Task | Reserve at Riverside | Goal states outcome without button instructions |
| Observation | Central selected accidentally | Record the actual branch on confirmation |
| Revision | Explicit branch choice and review | Decision becomes visible before final action |
| Retest | Correct branch selected | No moderator coaching required |
- Evidence
- Confirmation names the wrong collection branch.
- Interpretation
- The default branch was easy to overlook.
- Testable change
- Require a visible branch decision before confirmation.
Common questions
Is usability testing the same as asking for feedback?
Feedback can include preferences and suggestions, while usability testing observes attempts to complete tasks. Both can be useful, but they answer different questions. A person may like a page and still reserve at the wrong branch. Define the outcome, watch what happens, and treat opinions as additional context rather than proof of task success.
How many tasks should a beginner session include?
Start with one or two realistic tasks that fit the time and prototype. This leaves room to observe hesitation and recovery without rushing. Add more only when they serve distinct questions. A long task list can produce shallow notes and participant fatigue, making it harder to understand the source of an important problem.
Should I help when someone gets stuck?
Give them time to explore unless there is distress or a technical failure. Use a neutral prompt about what they are thinking rather than naming the next control. If you intervene, record when and why. Assisted completion should not be reported as independent success because the help changed the task conditions.
Can a small test prove the design is good?
A small qualitative test can reveal problems and inform revisions, but it does not certify every task or user group. State who participated, what they attempted, and what the prototype supported. Use the findings proportionately. Absence of a problem in a few sessions is not proof that the problem cannot occur.
What makes a useful issue description?
Name the screen, describe the observed behaviour, explain the consequence for the task, and identify the next action. Include a short evidence reference such as a note or timestamp. “Navigation is confusing” is too broad; “the default Central branch was confirmed instead of Riverside” gives the team something specific to investigate.
How should I rank usability issues?
Consider whether the issue blocks the goal, causes a wrong outcome, creates serious recovery effort, or is merely cosmetic. Also consider how strong the evidence is. Do not let a minor problem dominate because it was easy to count. In this exercise the wrong collection branch matters more than an uneven card margin.
Can I test my own interface with myself?
You can perform a walkthrough to find broken links and obvious omissions, but you already know the intended route. That makes it a limited substitute for observing another person. Use self-review as preparation, then involve appropriate willing participants where possible. Label simulated observations honestly if you are practising analysis without real sessions.
What should I include in the final case study?
Show the task, success definition, method, anonymised observations, issue priorities, design change, and retest outcome. Mention limitations and any help you gave. Keep recordings private unless participants explicitly agreed to the intended use. The reader should be able to follow the evidence from a task failure to a justified revision.
Continue your learning
UX Research Learning Roadmap: Plan, Run and Summarise a Small Study. Wireframing Roadmap: Turn a User Task into Clear Screen Layouts.
Sources and further reading
- NNG: task scenarios — Realistic task wording that does not reveal interface actions.
- GOV.UK: moderated testing — Observe participants completing tasks.
- NNG: usability testing — Task observation and qualitative usability evidence.
Skills & Learning Desk
MP Job Hub’s organisational byline for sequenced practice, course evaluation and useful learning habits.
Skill roadmaps · Learning resources · Practice projects
View profile →Read our research process or request a correction.
