role · designer

Designer

The Designer is the moment-keeper. They name the step in the journey the cycle is changing, draw the smallest flow that proves it, and keep the copy of the change honest about what is and isn't happening.

What good looks like

A competent Designer produces three artefacts every cycle:

1. A journey map for the initiative — the steps the named person takes, with the one or two that are changing this cycle marked.
2. A flow for the cycle's first story — the smallest end-to-end interaction, including the empty, loading, error, and success states.
3. A copy set — every piece of user-facing text the change touches, written once, owned by the Designer, signed by the PO.

A Designer who produces these three has the moment held. A Designer who skips the journey leaves the team designing UI without context. A Designer who skips the copy lets engineering invent strings that survive into production.

The Designer's stance

The Designer is responsible for	The Designer is not responsible for
The journey — what the person is doing across the change	The product's strategy
The flow of the change — every state	The data model behind the flow
The copy of the change	The marketing site
The design system's coherence over time	Every visual decision being final on day one
The accessibility of the change	The accessibility of code they did not write

The Designer holds the chain by holding the lived experience of the change.

Three artefacts to read first

1. Journey Mapping
2. Walking Skeleton
3. Story Writing

First 30 days

Day 1–3 — Read the canon

Read Before We Build Parts 2, 3 (Person & Moment, Journey Mapping). Read What We Shape Parts 3, 4 (Walking Skeleton, Story Writing). Read As We Build Part 1 (Domain Language).

Output: in three sentences, explain why the journey is named before the flow.

Day 4–7 — Sit next to the named person

The Designer is at the observation session alongside the PO. Sit next to one of the named people. Sketch their current journey on paper. Don't redesign — record.

Output: a journey map of the current state, with workarounds and skipped steps marked.

Day 8–14 — Draw the smallest flow

Pick the first story. Draw the flow — every state. Empty. Loading. Error. Success. One screen at a time. Pair with the PO to make sure the moment is the moment.

Output: flow with all four states, signed by the trio.

Day 15–21 — Write the copy

Every string the change touches. Empty-state copy. Error messages. Success message. Confirmation. The DM that goes out if it breaks. Write it. The PO signs.

Output: copy doc with every string, in context, ready for the developer.

Day 22–25 — Hold the amigos for design

Show the flow at amigos. Walk QA through the empty/error/success cases. Bring at least one anti-flow ("here's what someone might do that breaks this").

Output: amigos notes, plus at least one Gherkin scenario seeded by the flow.

Day 26–30 — Watch the first 48h

When the change ships, the Designer is watching — for journey-level breakage, not bugs. Did the moment land? Was the flow ever taken? What did the named person actually do?

Output: a journey-level note distinct from the bug report. Names what changed in the lived experience, not in the codebase.

Deepening — self-rate yourself

Journey discipline

• I can name, in 10 minutes with a Feature Brief, the journey step the cycle is changing — and the steps it is not.
• My journey maps mark workarounds the person has stopped noticing.
• I refuse to design until the journey is named.

Flow discipline

• Every flow I hand the team has four states: empty, loading, error, success.
• The flow contains the negative case — what a person does that breaks the assumption.
• I can defend cutting a feature from the cycle's flow when it doesn't change the moment.

Copy discipline

• Every string the change touches lives in one doc, owned by the Designer.
• Error messages name what to do next, not what went wrong.
• I can identify a string that engineering invented in production within ten minutes.

Design system

• New patterns are committed only after they have shipped twice.
• I can defend removing a pattern from the system without it being a personal moment.
• A new Designer onboards to the system without me being in the room.

Cross-role craft

• I sit at amigos every cycle.
• I read the signal reading next to the brief.
• I can identify, from a postmortem, which level the design contributed to — and own that.

Stuck if…

…the team is designing UI without a journey

The brief was signed without a journey map. Stop. Re-open Before We Build · Journey Mapping. UI without journey is decoration.

…copy is being written in pull requests

The string set wasn't owned by the Designer. Engineering is improvising. Pull the strings into the copy doc; treat the PR strings as drift to be corrected.

…the flow grew past one screen and you didn't notice

The story is too large. Re-read Slicing & Prioritization. One flow per story; one moment per flow.

…the same modal keeps coming back in different shapes

Design system drift. Open the system inventory. Either it's a pattern that should be committed, or it's a pattern that should be killed — both, not neither.

…signal reading says the moment landed but you can tell it didn't

Trust the moment, not the metric. A signal that confirms a thing the lived experience disagrees with is a poorly chosen metric. Re-open the brief's prediction fields.

…leadership keeps asking for a redesign

The journey hasn't been re-read for too many cycles. Hold a journey review with leadership, not a redesign meeting.

See also

• Skill path — Designer foundations
• Canon — Before We Build · What We Shape
• Practice — Writing Feature Briefs (the trio's third signature)
• Checklists — Trio sign-off
• Areas — 4 · Design & UX · 3 · Product Definition
• Clinics — A brief that didn't witness · A brief written from the solution backwards