Journey Mappingas an instrument you think with

Journey mapping has become one of the most over-produced and least useful artefacts in design. It goes the same way almost every time. A team runs a workshop, covers a wall in sticky notes, adds an emotion line, photographs it, and sends round a polished version as a deliverable. Months later, you cannot point to a single decision the map changed.

The method itself is sound. Journey mapping is one of the most useful instruments Heart has for thinking about experience. The failure is treating it as a deliverable when it should be an instrument. A deliverable is made to show that work happened. An instrument is used to produce a specific kind of understanding. The same artefact on the wall can be either, depending entirely on what the team did with it.

As an instrument, it answers a question you could not reach any other way: where do the person’s needs, the system’s behaviour, and the business’s intent fall out of line with each other? You can only see that across time. Friction that looks acceptable at any single step compounds, step by step, into a whole that wears people down, and single-step analysis never catches it.

A journey map becomes an instrument through how it is made:

• Anchor on a specific person in a specific situation: ‘A small-business owner onboarding to our accounting product’ is a journey. ‘SMB users’ is a segment, too broad to have a journey at all. How specific you get is what decides whether the map turns up real misalignments or generic ones. Write down the actual task, the context, and the constraints the person was under.
• Map what actually happens, not what is supposed to happen: The temptation is to draw the designed flow, the steps the product intends. A real journey map records what a real person did: the abandonments, the backtracks, the six tabs open at once, the call to support, the message to a colleague asking for help. The design work lives in the gap between intended and actual.
• Include the backstage: Every journey has a frontstage, what the person meets, and a backstage, the systems, people, and decisions behind that encounter. Lynn Shostack’s service-blueprint framing (4.4) is the structure to use.¹ The backstage is where the map gets its diagnostic power. Someone abandons at one step, but the reason usually sits in an earlier failure they never saw.
• Choose the decision the map is meant to inform: A map pointed at a real decision stays focused on what affects it. The decision might be: where do we put our engineering time? Which onboarding redesign do we pilot? Which hand-off between product and support is costing us the most trust? That focus is the whole difference between a map that changes something and one that decorates a wall.