Journey mapping
A journey map describes one person pursuing one goal, step by step, in their terms rather than the software’s. It is the first artefact, ahead of the screens and ahead of the schema.
It is not a flowchart of the system. If the map contains a box labelled “validation service”, it has stopped being a journey map.
What is on it
Section titled “What is on it”Per step, five things. The last one is the one most maps omit and the one that makes the map trustworthy.
| Row | Holds |
|---|---|
| Step | What the person does, as they would describe it |
| Intent | What they are trying to achieve by doing it |
| Pain | What goes wrong today, and how much it costs them |
| Emotion | Confident, rushed, anxious, distracted, resigned |
| Evidence | How you know: a session, a support ticket, a metric — or the word assumption |
The Emotion row earns its place by changing design decisions rather than decorating them. The anxious step is where a confirmation belongs; the rushed step is where one must be removed; the distracted step is where the interface has to survive being abandoned halfway and returned to an hour later.
What it costs when it goes wrong
Section titled “What it costs when it goes wrong”The single most useful number on the map, and the one that sets the budget for everything downstream. Time, money, embarrassment, or risk — in the person’s units, not yours.
A step that costs someone four seconds of mild irritation and a step that costs them a rejected mortgage application both look like one box on a whiteboard. Without the cost, both get the same investment, which means one is overbuilt and the other is underbuilt.
What they do today instead
Section titled “What they do today instead”Every journey has an incumbent, and it is almost never nothing. A spreadsheet, a phone call, a colleague who knows, the old system nobody switched off.
Two reasons this belongs on the map: it is the thing you are actually competing with, and it is where the real requirements are hiding. The workaround people built for themselves is a specification written in behaviour rather than in words.
Where the map goes
Section titled “Where the map goes”| Output | Goes to |
|---|---|
| The steps | The backbone of the story map |
| Intent, Pain, Emotion, Evidence | The UX row under that backbone |
| Pain and its cost | The investment decision per step |
| The steps, again | The names of the journey tests |
That last row is the loop worth closing deliberately. The journey named here is the journey the test suite walks at the far end. When they have drifted apart — and they drift silently — the tests are checking a product nobody designed.
Running it
Section titled “Running it”Ninety minutes, with the people who have the evidence: the end user first, and otherwise the people closest to them — support, sales, operations. The product owner and a developer attend; the designer runs it.
Do it before story mapping, not instead of it. They answer different questions: this one asks what is this person’s life like, and the story map asks what do we build, in what order.
The failure modes
Section titled “The failure modes”The idealised journey. Everything works, in order, first time. Recognisable because it has no Pain row worth reading. Usually produced by mapping the journey you intend rather than the one that exists.
The system journey in disguise. The steps are the software’s steps — authenticate, select, submit, confirm. It looks like a journey and carries none of the information a journey is for.
The map in amber. Drawn once at kickoff, cited with increasing authority, never revisited. The Evidence row is the defence: it makes the age and the source of every claim visible, so a map going stale looks stale.