On this page
User testing helps a team see how people understand and use an app while trying to accomplish something. It is most useful when the session addresses a decision the team can still change. A demonstration in which the facilitator explains every step may show the product's intended route, but it provides little evidence that an unfamiliar person can find that route independently.
Begin with a focused research question. You might need to know whether people can recover a saved draft, understand a permission request, or distinguish a successful submission from a pending one. Choose tasks and participants that can provide relevant evidence about that question.
Define what the session can and cannot establish
A usability session can reveal confusing wording, missing information, inaccessible interactions, and unexpected ways of approaching a task. It does not by itself prove security, reliability, market demand, or the absence of defects across every device.
Keep the scope clear when sharing results. If participants tested a prototype with simulated data, say so. If the session covered only one workflow, do not describe the entire app as validated.
Write down the decision that follows the research. The team might revise the navigation, compare two concepts, or investigate a technical constraint. This gives the findings a destination beyond a presentation of interesting observations.
Recruit people whose circumstances matter
Look for actual or likely users with the relevant task context. A frequent administrator and a first-time requester may use the same app differently. Include those differences when they affect the question rather than treating all participants as interchangeable.
Consider access needs, device use, language, and familiarity with the task. Arrange an appropriate session format and any necessary support. Do not assume that testing with colleagues covers the experience of people who were not involved in the design.
Explain participation, recording, data use, and withdrawal clearly. Collect only the information needed for the research and use the organization's appropriate consent and retention practices. A research session should not require unnecessary disclosure of private records.
Write tasks as goals, not instructions for the interface
A task should describe a believable situation and the result the participant wants. “Find out whether your reservation was accepted” leaves room to observe navigation. “Tap Reservations, then open the second card” tells the participant the route you wanted to test.
Use realistic fictional details when possible. They should be complete enough to make the task understandable without involving real payments, messages, or sensitive accounts. Explain any simulated behavior that a participant could otherwise mistake for a live action.
Pilot the task with someone who did not write it. If they misunderstand the scenario itself, revise the wording before interpreting later confusion as a product problem.
Let the participant work before helping
Ask the participant to explain what they are thinking where that is suitable for the method and person. Then give them room to act. Avoid confirming every choice or pointing toward the intended control as soon as they hesitate.
Use neutral prompts such as asking what they expect to happen next. A question that names the correct button can accidentally teach the interface and change the evidence you collect.
If the participant becomes stuck, record the point and provide proportionate help so the session can continue. Distinguish unaided completion from completion after assistance. Both can provide useful information, but they mean different things.
Separate observations from interpretations
An observation describes what happened: the participant opened three menus, returned to the start, and asked whether the request had been saved. An interpretation proposes why: perhaps the status language was unclear or the confirmation was easy to miss.
Keep those layers separate in the notes. This makes it easier for the team to consider alternative explanations and avoids presenting a facilitator's first impression as a settled fact.
Record relevant context such as the build, device, task setup, and prototype limitations. A broken link in the research environment should not be mistaken for evidence about the intended production flow.
Include the important edges of the journey
A successful first submission is only one part of many apps. Returning later, editing a record, declining a permission, or recovering from an interruption may determine whether the product remains usable.
Choose the edges that relate to the research question and risk. Do not force every participant through a long catalogue of artificial failures. Several focused sessions may produce clearer findings than one exhausting tour.
For accessibility, use appropriate evaluation methods and relevant assistive technology where needed. Watching a person without a disability complete a keyboard task is not a substitute for understanding the broader accessibility requirements of the product.
Turn findings into proportionate changes
Group observations by the problem they reveal and describe the effect on the task. A confusing label that blocks completion deserves different attention from a minor preference about color. Consider severity, recurrence, and the limits of the sample without treating a small count as a population statistic.
Link each proposed change to the evidence and the intended outcome. Avoid redesigning unrelated areas simply because the research session created momentum for a larger overhaul.
Where the cause remains uncertain, plan a focused follow-up. A new prototype or a short technical investigation may help distinguish between competing explanations before the team commits to a solution.
Continue learning after release
Live support questions and usage patterns can reveal problems that did not appear in the initial sessions. Use them to select later research questions, while respecting privacy and the limits of the data.
Check whether the change actually improved the task. A new design may remove one obstacle and introduce another. Keep the review tied to user outcomes rather than the team's satisfaction with the redesign.
The useful deliverable from user testing is a clear account of what people attempted, what happened, what the evidence suggests, and what the team will do next. That record supports better decisions without pretending that a small research round has answered every question about the app.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Service Manual: Moderated usability testing Moderated testing observes people attempting realistic tasks and requires thoughtful participant, task, and session planning.
- W3C: Evaluating web accessibility Accessibility evaluation benefits from appropriate methods and people with disabilities; tool results alone are incomplete.