“Click Settings and add a colleague” gives a participant a route through an interface. If the purpose of a usability test is to find out whether that route is discoverable, the instruction has already answered an important part of the question. A task scenario instead describes the situation and the outcome someone needs, leaving them to decide how to get there.
For a fictional project-management product, that might be: “A new colleague joins your project on Monday. Give them access to the project so they can see the team’s work.” The scenario provides a reason to act without naming the menu or button, allowing the researcher to observe how the participant interprets the available choices.
Write from the participant’s situation
Begin with a goal that is plausible for the audience and relevant to the study. A task that makes sense to an administrator may be unfamiliar to a person who only views reports, so the same instruction is not necessarily suitable for both. Establish the participant’s role and the circumstances needed to make the task meaningful.
Include information a real user would already possess. Someone booking a train needs a destination and a date, while someone choosing a subscription may need to know how many colleagues will use it. Leaving out those details can force the participant to invent a situation, making it harder to understand whether a difficulty came from the product or the task itself.
Nielsen Norman Group’s guidance on task scenarios explains how realistic goals can be translated into test prompts. The useful discipline is to provide enough context for action without turning that context into a story the participant must memorise.
Avoid making the interface the answer
Compare “Use the Invite members button” with the colleague-access example. The first prompt tests whether someone can follow a named instruction; the second leaves room to observe whether they recognise the route. This distinction also matters in tree testing, where repeating a navigation label in the task can make a weak label appear easier to find.
Avoid descriptions that tell participants how they should feel, such as “This is a simple task” or “People often find this confusing”. If the study requires an assessment of ease, collect it after the attempt using a consistent question. The task wording should not supply the assessment in advance.
Not every study needs to avoid procedural instructions. Training research may deliberately investigate how well people follow a guide, but that is a different objective from testing discoverability and should be described accordingly.
Define completion before running the study
The participant-facing scenario and the researcher’s scoring rules serve different purposes. For the colleague-access task, the research plan might distinguish opening the invitation form, sending an invitation with the intended permissions, and completing the process only after help. Decide which outcome counts as success and record assistance consistently.
Check that the prototype or test environment supports the task. A missing interaction can look like a usability failure unless the researcher knows where the prototype stops. If several goals are combined, consider whether they should be separate tasks so that completion and difficulty can be interpreted clearly.
Pilot the task in its intended format
Try the scenario before the full study and observe how it is understood. In an unmoderated session, the wording must work without immediate clarification; in a moderated session, the researcher still needs to avoid rescuing an ambiguous task in ways that differ from participant to participant.
Review the order of tasks as well as the wording. An earlier task may teach the location needed for a later one, which can affect comparisons. Plan the sequence or rotation around that possibility and document the choices. The broader usability-testing guide explains how tasks fit into the study, while prototype testing covers the constraints introduced by unfinished designs.