# Usability Testing Scenarios: Write Tasks That Reveal Where a Flow Breaks Create realistic usability test scenarios without giving away the interface: use a scenario card, neutral wording, and observable completion evidence. - Canonical URL: https://www.harmate.com/en/blog/usability-testing-scenarios-write-tasks-that-reveal-where-a-flow-breaks - Author: Harmate Team - Published: 2026-11-15 - Updated: 2026-11-15T01:50:00.673287+00:00 - Language: en ## Content # Usability Testing Scenarios: Write Tasks That Reveal Where a Flow Breaks A usability test scenario gives someone a goal without telling them which controls to use. It creates a realistic starting point and gives the observer something concrete to record. A scenario is a prompt, not a prediction of user behavior. ## Start with a real goal Write down the decision your team needs to make, then describe the situation that gives a participant a reason to act. For example, if you are reviewing a draft-resumption flow, the decision might be whether people can leave a long form and continue later. A suitable context could be: “You are filling in an application for a program. You have answered several questions, but need to stop and continue tomorrow.” Keep interface details out of the prompt. “Click Save, then open Drafts” supplies a route. “You need to stop now and pick this up tomorrow. Show me what you would do” leaves the route open. Nielsen Norman Group likewise recommends realistic goals without wording that gives away the path. [Read the task-scenario method](https://www.nngroup.com/articles/task-scenarios-usability-testing/). ## Make the task observable Before a session, define what evidence would count as completing the task. Avoid internal states such as “understands autosave.” Instead, write an observable criterion: “After returning, the participant finds the edited answer and explains which visible signal led them to believe it was retained.” This lets the observer record what happened without pretending to read someone’s mind. A scenario card can contain: - **Decision under review:** what product choice the study should inform. - **Participant context:** the situation and relevant eligibility, without inventing a persona as evidence. - **Starting state:** page, data, and build version shown to every participant. - **Prompt:** the exact neutral wording the moderator will use. - **Completion evidence:** observable actions or result that satisfy the task. - **Neutral probes:** short questions such as “What are you looking for?” or “What makes you think that?” - **Recording fields:** action sequence, quote with context, issue hypothesis, counterevidence, and next check. ## Worked scenario: resume a draft **Starting state:** A fictional questionnaire is open on page three of six. The first two pages contain completed answers; no draft has been saved yet. **Prompt:** “You are partway through an application and need to stop now. You want to continue tomorrow. Show me what you would do.” **Completion evidence:** The participant leaves the task in a state they believe they can resume, returns to the same draft, and locates prior answers. Record the actions and the signal they cite. Do not call a single session a general usability finding. **Neutral follow-up:** “What would you do next?” If asked whether work is saved: “What would you look for to decide?” ## Second scenario: check a changed answer **Starting state:** A saved questionnaire is open. One answer was changed in the previous step; the participant has navigated to another page. **Prompt:** “You changed an answer and want to make sure it will still be there when you come back. Show me how you would check.” **Completion evidence:** The participant returns to the changed answer and states whether it persisted, citing a visible cue. Record the cue and actions; do not tell them where to look. ## Pilot and revise Read the prompt aloud before inviting participants. If a colleague cannot tell what situation they are in, clarify the context without naming a control. Check that the starting state actually permits the task and that the success criterion can be observed. This rehearsal checks the test instrument; it is not participant evidence. After sessions, separate observation and interpretation. “Participant opened the menu, then returned to the form” is an observation. “The save status was hard to find” is a hypothesis. Report the observed cases; do not turn a few sessions into a population rate. A scenario makes the next observation possible; it does not prove in advance what the design should be. After the action, ask an open question about what the participant looked for. The [semi-structured interview guide](https://www.harmate.com/en/blog/semi-structured-interview-guide-method-steps-and-15-examples) offers follow-ups that let people explain what they did. Use the [observation template](https://www.harmate.com/en/blog/observation-checklist-focus-the-inquiry-without-rating-a-person) to keep a record.