Design & UX · master area
User Flow Design
Happy path → edges → errors. Nodes are named states. The flow is drawn before any screen exists — because the order of decisions is what determines whether the moment works.
Owners: Designer Phase it lives in: What We Build (Volume III) The corpus principle this enacts: Name every state the person can be in.
Where it lives in the chain
- What We Build · Design Shaping — the canon
- What We Build · Fidelity grows with understanding — why the flow precedes the pixels
How to do this
- Principle — Chain-level thinking — enough to amigos, not enough to ship
- Related practice — Holding amigos — every node is a scenario candidate
- Clinic — A story without a state — the failure this craft prevents
What a session looks like
The designer maps the happy path first — the canonical sequence Gal takes when nothing surprises her. Then the edges — what happens when the input is empty, partial, oversized, in the wrong language, submitted twice. Then the errors — what happens when the server returns 500, when the network drops, when permission is revoked mid-flow. Each node is a named state: empty, loading, partial-submission, success, validation-error, server-error, permission-revoked. The state names travel into the wireframes, into the Gherkin, into the test names, into bug reports. A flow with three nodes and four arrows is one the team can argue about. A flow that says "and then they fill in the form" is not yet a flow.
Related crafts
- Current-State Flow Mapping — the before-picture
- Wireframing & Prototyping — the next fidelity step
- Interaction Design — what happens inside each node