Usability Testing Tasks: Write Scenarios That Reveal Real Problems
A usability test can produce misleading results if the task tells participants exactly where to click or asks them to do something they would never do in real life. A good task scenario gives a believable reason to use the product while leaving the path open for observation.
The goal is to learn whether people can complete meaningful activities—not whether they can follow a script that describes the interface.
UX Survey Question Design: Ask Questions People Can Answer
Start with a user goal
Write down what a person needs to accomplish before choosing a screen or feature to test. “Find a way to compare two plans” is a goal; “click the Plans tab, choose Compare, and select two rows” is an instruction that gives away the answer.
Use a context that helps the participant understand why the task matters. For example, “You are choosing a plan for a small team and need to understand which one includes shared reports” gives a reason to compare options without prescribing where to look.
Keep the scenario realistic for the participant group. Tasks that involve implausible purchases, made-up personal details, or unfamiliar jargon can make participants behave differently from how they would in their own context.
Use neutral, non-leading language
Avoid mentioning the control, navigation label, or design pattern you want someone to discover. Do not say “Use the filter” if the research question is whether people can find and use filters. Ask for the outcome instead.
Check that the task does not contain a hidden “right answer” in its wording. Terms used in the task should reflect how participants describe the need, not only the vocabulary in the interface.
If a participant asks for help, use a neutral prompt such as “What would you do if I weren’t here?” or “What are you expecting to happen?” Record the question and the point where it occurred; do not silently rescue the task and mark it successful.
Pilot tasks before the session
Read each task aloud and ask a colleague to complete it using only the scenario. Look for ambiguous names, missing context, impossible prerequisites, and steps that accidentally reveal the route.
Pilot with someone who resembles the intended participants when possible. A task that makes sense to the product team may rely on internal terminology or knowledge that users do not have.
Prepare a discussion guide with the introduction, consent and recording information, task text, neutral follow-up prompts, and a consistent closing. A guide helps sessions stay comparable without turning the moderator into a script-reading machine.
Observe behavior and separate evidence from interpretation
Capture what the participant does, says, and expects. Note pauses, backtracking, wrong turns, questions, and task outcomes. Avoid writing conclusions such as “the layout was bad” in the observation column; save interpretation for synthesis after the session.
When reporting results, explain the context and number of participants. A small qualitative study can reveal usability problems and generate hypotheses; it should not be presented as a precise estimate of how many users in a population will encounter them.
Make tasks accessible and respectful
Recruit people who represent the service's likely users, including disabled participants where relevant. Allow participants to use their own assistive technology or settings when needed. Do not blame the participant for a difficulty; the interface is what the study is investigating.
For research planning and synthesis, see the UX research methods guide, inclusive testing guide, and research synthesis guide.