The process
One feature, end to end. Each step names who is in the room, what comes out, and what would catch it if the output turned out to be wrong.
The steps are not a phase gate. A team runs several of them in the same week, and the later ones routinely send work back to the earlier ones — which is the point: it is cheaper to be sent back from step 3 than from production.
Step 0: what already exists
Section titled “Step 0: what already exists”Before the feature does. This is not a step in the feature’s life; it is the condition the rest of the process assumes.
- The design system — the visual contract.
- The core component library — the technical contract, versioned and consumable.
Both are established, owned and enforced. Every step below consumes them. Where a step finds something they do not cover, that becomes a change request against them — step 4 — and it is the exception rather than the flow.
If neither exists yet, establishing them is its own piece of work, done once and amortised across every feature after it. Attempting it inside a story produces a design system per story.
1. Understand the person
Section titled “1. Understand the person”Who: the end user, the product owner, the UX designer, a domain expert. Out: a journey map — what someone is trying to accomplish, in their words, what it costs them when it goes wrong, and what they do today instead.
This is the cheapest moment to discover you are building the wrong thing, and the only moment when that discovery costs a conversation.
Caught by: nothing automatic. This is why the people are in the room.
2. Map the work
Section titled “2. Map the work”Who: the same people, plus a developer and a quality engineer. Out: a story map — the journey along the top, the stories that realise it underneath, sliced into releases.
The designer is in this room, not upstream of it. The map’s backbone is the journey, so mapping it without the person who studied the journey means reconstructing it from memory. A slice of the map has to be usable, not merely functional, and that is a judgement someone has to be present to make.
The library is in the room too, as knowledge rather than as a document: slicing is only honest when everyone knows which pieces already exist. A slice that looks thin and quietly requires three new core components is not thin.
Caught by: the slice review — take the thinnest release slice and walk it as a user. If it cannot be walked, it is not a slice.
3. Open one story
Section titled “3. Open one story”Who: the four amigos — product owner, developer, quality engineer, UX designer. Out: an example map: rules, concrete examples, the hard states, and red cards for what nobody can answer.
This is where the interface’s hard states get discovered, because they are hidden in the rules rather than in the happy path: empty, partial, slow, denied, offline, too many, too long, wrong locale.
With the design system in the room, most of them are already answered — the system has an empty state, a denied state, a loading treatment, and the designer says so in ten seconds. The session’s real output is the short list of states it does not cover.
Caught by: the shape of the map. Many red cards means the story is not ready and must not be estimated.
4. Handle what the contracts do not cover
Section titled “4. Handle what the contracts do not cover”Who: the designer and the developer from step 3, with the owners of the contract concerned. Out: a change request — against the design system, the core library, or both. Or, more often, a decision that composition covers it and nothing upstream needs to change.
This is the only step that touches the contracts, and it is deliberately narrow. Three possible answers, and naming which one you are giving is most of the value:
- The core already covers it. Compose and move on. This is the common case and it gets more common as the library matures.
- It is genuinely local. One screen, with a reason. Solve it in the product layer, visibly, without touching the core.
- It is general and missing. A real change request, decided by the owners, landing upstream where every feature inherits it.
Caught by: review by the contract’s owners — and, longer term, by the drift report in keeping them aligned, which is where quiet local inventions show up.
5. Assemble the screen
Section titled “5. Assemble the screen”Who: the front-end developer. Out: the feature, assembled from components already under contract.
This is the step everyone thinks of as “the work”, and by this point most of its decisions were taken before the feature started. What is left is composition, data, and the states this particular screen adds — which is a genuinely smaller job, and one whose mistakes are visible rather than subtle.
Caught by: the contracts themselves. A raw colour, a missing state or an unreachable control fails before review.
6. Check the journey
Section titled “6. Check the journey”Who: the quality engineer, with the designer reviewing the real thing. Out: journey tests that walk the whole path in a browser, in the user’s words, with the accessibility scan in the same pass.
Visual regression runs here too, but as a change detector rather than a verdict: it reports that something moved and a human decides whether that was meant. See journey-first for why the weight sits where it does.
Caught by: this is the catch. If it fails, a user was going to be stuck.
7. Test it with people
Section titled “7. Test it with people”Who: five participants who did not build it, and one observer from the team who stays quiet. Out: usability findings — blocking problems, friction, and occasionally a finding about an established pattern that affects every screen using it.
Step 6 proves the journey is passable. This step is the only one that tells you whether anyone actually gets through it. On a prototype for anything whose journey is new; on the built thing before it is widely released.
Findings about a shared pattern go back to step 4 as change requests — and those are the most valuable output this process produces, because they improve every feature at once.
Caught by: nothing. This step is the instrument.
8. Watch it in use
Section titled “8. Watch it in use”Who: the product owner, the designer, the end user again. Out: evidence — where people abandon, where they hesitate, what they asked support about.
The journey agreed in step 1 was a hypothesis, and step 7 tested it with five people in a quiet room. This is the step that says whether it holds at scale, with their own data, under their own deadlines. It feeds straight back into step 1 for the next feature.
Caught by: nothing. This step is the other instrument.
What each step owes the next
Section titled “What each step owes the next”| Step | Hands forward | What goes wrong if it is skipped |
|---|---|---|
| 0 Contracts | What the interface is made of | Every feature reinvents it, slightly differently |
| 1 Understand | The journey and its cost | Everything downstream optimises the wrong thing |
| 2 Map | Sliced, walkable stories | Releases that are functional and unusable |
| 3 Open | Rules, examples, and the uncovered states | States designed under deadline by one person |
| 4 Change requests | Contract growth, upstream | A second design system, in the product repository |
| 5 Assemble | The feature | — |
| 6 Journey tests | A checkable “a person can do this” | Regressions found by users |
| 7 Usability | Evidence that a person does | A passable journey nobody can follow |
| 8 Observe | Evidence for the next step 1 | A journey that stays a hypothesis forever |
Where the machine helps
Section titled “Where the machine helps”Steps 0, 4, 5 and 6 have mechanical halves — publishing tokens, scaffolding a component from its contract, turning an example map into scenarios, sweeping for accessibility violations. Those are what MCP is for, and it is deliberately the last section of this site rather than the first: automation multiplies whatever discipline it finds.