Scenarios must include failure and exception
Aliases: failure scenarios · exception paths · happy-path-only
What it is
The write-up says “ID is sharp, accepted first time.” The field more often has blur, expiry, lighting, a child grabbing the phone, a call in the middle. Failure and exception scenarios are not a spoilsport appendix. They are the ways through that will not go through, which the proposal still has to cover. Without them, the scenario only demonstrates the world the designer hoped for, and leaves recover, cancel, retry, and asking for help in undesigned space.
Why it happens
The happy path is shorter to tell and easier to treat as “the main flow.” Exceptions are imagined as rare, so they do not deserve their own story. In fact they rewrite the shape of the main flow: after timeout, is the whole order void or can it resume? After a witness refuses, can someone else step in? If those decisions never enter a scenario, engineering will implement the cheapest abort, while research still writes usability tasks as first-time success. Exceptions also change who is present: failure often produces a second person (family, clerk, agent). The single-protagonist model in the main scenario then collapses.
Studying it
From logs, tickets, and observation, list real interruptions and failure types, and check whether the scenario set has a story for each—not a single line at the end of the main story that says “if it fails, show a message.” Walk or test with exception scenarios and record where the proposal has no next frame. Compare problems found on the main path only with main path plus two high-rate exceptions. Outcomes: exceptions with no next frame, and extra roles that appear only in failure.
Where it stops holding
You cannot write a scenario for every theoretical error code. Pick exceptions that change the structure of later action (irreversible, change of person, change of day, data loss), not every validation reddening. Extreme disaster recovery has its own playbook genre; it need not be stuffed into the everyday set. A board shown to outside investors may walk the main path only; the internal design set cannot be that set alone. Catastrophes that have never occurred and are pure invention should be tagged as stress-test hypotheses and not filed with observed failures.
Applying it
- Pair every main scenario with at least two structure-changing exceptions: one from an observed failure, one from a system refusal.
- Write the exception through to what the person does next; stopping at error copy is not done.
- Put one actually triggerable failure inside a usability task, rather than asking about failure only as a verbal probe.
- In review, drop the main path and keep the exception set. If the proposal has no executable next step in failure, do not declare the main path designed.