User Scenario

Purpose

A User Scenario tells the story of a specific person using the proposed solution in a realistic context. Unlike feature lists or wireframes, it embeds the concept in the messy reality of human life — the emotions, the distractions, the constraints. Writing the scenario forces the team to confront whether their solution actually fits.

At a glance

• Group size: 2–8
• Duration: 30 minutes
• Difficulty: Low to moderate
• Facilitation style: Guided narrative writing
• Setting: Any room; individual or pair work

How to run

1. Choose the persona (5 min): Select a specific user persona or real user to anchor the scenario.
2. Set the context (5 min): Define when, where, and why the user encounters the solution. What just happened? What’s the emotional state? What’s the goal?
3. Write the scenario (15 min): Narrate the step-by-step journey: what the user does, sees, thinks, and feels at each stage. Include friction points and moments of delight.
4. Read and critique (5 min): Read the scenario aloud. Others listen for: "Is this realistic?" "Where does it break?" "What assumptions are embedded?"

Materials needed

• Persona cards or user profiles
• Template: Context > Trigger > Step 1 > Step 2 > … > Outcome > Feeling
• Paper and pens or shared document

Pitfalls & common mistakes

• Happy path only: The scenario should include friction, errors, and interruptions — not just the ideal flow.
• Generic user: "A user opens the app" is not a scenario. Use a specific person with a name, context, and emotion.
• Too many steps: Focus on the critical path. A 30-step scenario is a specification, not a story.
• No emotional layer: If the scenario doesn’t mention how the person feels, it’s a process diagram, not a user scenario.

Inclusion & accessibility

• Write scenarios for diverse users, including those with disabilities, different tech literacy, and different cultural contexts.
• Allow verbal storytelling instead of written scenarios.
• Include accessibility touchpoints in the scenario itself (screen reader interaction, voice commands, etc.).

Variations

• Video scenario: Film a team member acting out the scenario instead of writing it.
• Day-in-the-life scenario: Embed the solution usage within a full day’s narrative.
• Failure scenario: Write a scenario where everything goes wrong — test the recovery path.

When NOT to use this

• When the concept is too abstract to narrate step by step — prototype first.
• When quantitative validation is needed — scenarios are qualitative tools.
• When the team is so deep in the problem that scenarios become echo chambers of existing assumptions.

Source & further reading

• Carroll, John M. — *Making Use: Scenario-Based Design of Human-Computer Interactions* (MIT Press, 2000)
• Cooper, Reimann & Cronin — *About Face: The Essentials of Interaction Design* (Wiley, 2014)
• Rosson & Carroll — *Usability Engineering* (Morgan Kaufmann, 2002)