§ Discovery
/scenarios
Anchor design decisions in concrete moments, not abstract use cases.
What it does
Personas describe types; jobs describe motivations; journeys describe sequences. Scenarios are the lightest of the Discovery artifacts and the most concrete — short narratives anchoring a named persona doing a specific job in a specific moment where the design will be encountered. Output is `.scenarios.md`, the artifact designers keep on the wall while making specific design decisions.
A scenario is one moment, not one flow. Where /journey maps a sequence, /scenarios captures the lived specificity of a single moment — Tuesday morning at 6:45am, kitchen counter, coffee brewing, fourteen unread notifications, half-attention. The specificity is the point: a scenario lets the design team test whether a design serves the moment as it actually exists, rather than the moment as the design team imagines it.
Specimen
/scenarios · Stillpoint
Scenario
Maya — morning kitchen
Persona · Maya (Daily Practitioner)
Job · Maya F1 — settle the nervous system before the day’s demands arrive.
Confidence · Drafted from .personas.md + .jtbd.md context — no observational research yet. The kitchen + coffee + kettle + cat details are plausible specifics that match Maya’s context-of-use (private moments, kitchen table) but are invented.
Decisions this scenario informs
- Whether the personalization banner placement on the home is serving Maya’s morning context.
- What attention level the home’s first surface can assume.
Tuesday morning, 6:45am. Maya stands at the kitchen counter, coffee brewing, the kettle just starting to make noise. Her phone is in her hand; the lock screen shows fourteen overnight notifications she has not read yet. She wants 5 quiet minutes before any of them. She opens Stillpoint with the intention of starting a short practice. Her attention is half-with-the-phone and half-with-the-kettle; she’s dressed for the day but not yet engaged with it. The cat is in front of the cabinet she needs to open. The next twenty minutes will set the tone for the morning — she’s aware of that, lightly, without making it a project.
Design implication
The home’s first surface needs to make “begin the recommended practice” reachable without scanning, scrolling, or choosing — Maya’s attention level can’t carry a multi-step front-door, and any friction here pushes the small-good-choice into a small-bad-task.
Scenario
Jordan — first-time curious, on the couch
Persona · Jordan (Skeptical First-Timer)
Job · Jordan F1 — sample what the practice actually feels like in 5 minutes or less.
Confidence · Drafted from .personas.md + .jtbd.md context — no observational research yet. The Sunday-couch-podcast-paused setup is invented but consistent with Jordan’s context (occasional, exploratory, low-commitment).
Decisions this scenario informs
- Whether the personalization banner serves first-impression for Jordan, or whether it would feel presumptuous to be told what to practice on first open.
- How much orientation context the home page needs to provide for someone who has never used Stillpoint.
Sunday afternoon, 3:20pm. Jordan is on the couch, phone in hand, podcast paused. They downloaded Stillpoint a few minutes ago after a friend mentioned it — not enthusiastically, just in passing. They’ve tried two other meditation apps over the last few years; both lasted one session. They expect this one to do the same. They open the app with low investment and high skepticism. Their attention is mostly available — there’s nothing else they need to do for the next half-hour — but their patience for being sold to or warmed up is near zero. If the first surface signals “lifestyle product” in any visible way, they will close the app within ten seconds and not come back.
Design implication
The home’s first 5-10 seconds carry disproportionate weight for Jordan — the opening visual + first copy line either pass the “honest, not packaged” test or fail it. A personalization banner that names a recommended practice may help (low friction, no choice required) or may feel presumptuous (the app doesn’t know me); the framing of the recommendation matters more than its presence.
/scenarios writes .scenarios.md — short narratives anchoring a named persona doing a specific job in a specific moment. The lightest of the Discovery artifacts and the most concrete; what designers keep on the wall while making specific design decisions.
When to use it
- Personas and jobs exist but design decisions feel abstract — the team wants concrete moments to test against.
- A specific surface (a home page, a dialog, an empty state) needs design decisions and you want a scenario to anchor them.
- The team is debating attention assumptions (“how much can we ask of the user here?”) and a scenario would clarify the actual context of use.
- Two scenarios from different personas would surface a tradeoff worth designing for explicitly.
- You want a quick HCD artifact without committing to the depth of /journey.
How to use it
By default /scenarios drafts one or two scenarios per significant decision surface, anchored to specific personas + jobs. Each scenario names the persona, the job, the lived narrative, and the design implication. Output is `.scenarios.md` — short, readable, designed to live on the wall during design work.
- /scenarios Maya morning kitchen
- /scenarios Jordan first-time on the couch
Anti-patterns it addresses
- Generic use-case descriptions (“user logs in to view dashboard”) instead of lived narratives. The whole point of a scenario is its specificity — a use case with a name attached isn’t a scenario.
- Scenarios that describe the design instead of the moment (“the user sees the personalization banner and taps Begin practice”). Scenarios should describe the world the design enters, not the design itself.
- Aspirational scenarios where the persona is fully attentive, fully informed, and ready to engage. Real scenarios capture half-attention, interruption, fatigue, skepticism — the conditions the design has to work in, not the conditions the design wishes for.
- Twenty-scenario inventories that try to cover every possible context. Scenarios are most useful when there are few of them and each one carries weight; padding undermines the artifact’s role.
- Scenarios without design implications. The closing line of every scenario should answer “so what does this mean for the design?” — without it, the scenario is fiction rather than a design tool.