Practices

A practice here is a named conversation with a defined output. Not a meeting: a meeting has an agenda, a practice has an artefact it is judged by.

The set is small on purpose. Most teams already run two or three of these; the work is usually not adding a ritual but changing who is in the room, what they bring with them, and what comes out.

The sequence

Practice	Scale	Question it answers	Output
Journey mapping	One person, one goal	What is this person actually trying to do, and what does it cost them today?	A journey with its decision points and its pain
Story mapping	A whole product or release	Which stories exist, in what order, and what is the thinnest usable slice?	A map with a journey backbone, sliced
Example mapping	One story	What does this story actually mean, in concrete cases?	Rules, examples, uncovered states, open questions
Four amigos	One story	Have all four perspectives been heard before code?	Shared understanding, and the above
Design critique	One design	Does this serve the journey, and where does it fight the system?	Decisions, not approvals

What they run against

All of them assume the contracts already exist. The design system and the core component library go into these sessions as inputs; they are not what the sessions produce.

That is what makes the sessions fast. A room that has to invent an empty state before it can specify a rule is doing two jobs at once and doing both badly. A room that can answer the system already has one, and it looks like this closes the question in ten seconds and spends its twenty-five minutes on what is genuinely undecided.

The contracts do grow out of these sessions, but by exception: a state card nothing covers becomes a change request against an established contract, decided upstream by its owners. It does not become a local invention inside one story.

Where UI and UX enter

This is the question the hub exists for, so here is the short answer, with the long ones on the pages themselves.

In journey mapping, UX is not “entering” anything — it owns the session. The output is the input to everything else.

In story mapping, the designer is in the room because the map’s backbone is the journey. Mapping it without them means reconstructing the journey from memory. The addition to the practice is a UX row under the backbone and a rule for slicing: a release slice must be usable, not merely functional — and it is only honest when everyone knows which pieces the library already supplies.

In example mapping, the designer is the fourth amigo, and the addition is a class of rule that engineering-only rooms systematically miss: the hard states. Empty, partial, slow, denied, offline, too many, too long, wrong locale. Each is checked against the design system first, and the useful output is the short list it does not cover.

In design critique, the direction reverses: the developers and the quality engineer are in the designer’s session, so that “can we build this” and “the library already does something close to this” are heard while the design is still cheap to change.

What they produce together

The practices are worth running as a set because their outputs chain. Each one’s artefact is the next one’s input.

        design system + core component library     (established, above the work)
                          │ inputs
                          ▼
journey map ──> story map ──> example map ──> the feature, assembled
     │                             │                    │
     │                             └─ change request ───┘ (the exception)
     │                                  back up to the contracts
     └────────────────────────────> journey tests ──> usability testing

The journey appears twice on purpose: once as the backbone that decides what gets built, and once at the far end as the thing the journey tests walk and the usability sessions put in front of a person. When those have drifted apart, the tests are checking a product nobody designed.

The anti-pattern all of them replace

The handover. Research handed to design, design handed to engineering, engineering handed to QA, each with a document and a sign-off. Every handover is a lossy compression of a conversation, and the loss is invisible at the moment it happens — which is why the practice of adding more documentation to a handover never works.

The practices are not faster than handovers. They are cheaper, because the rework they prevent happens later and costs more.

Where they connect

• The process puts them in sequence with everything else.
• Contracts is what they consume.
• User-first is the disposition that makes the designer’s presence non-negotiable rather than nice to have.
• UX artefacts is what happens to the outputs afterwards: which ones become digital, and which ones may stay on a wall.