Everyone on a project carries a model of the service in their head. The developer has one. The product owner has one. The person on the phone with users all day has a very different one. None of them is wrong, but none is complete either.
A map takes the models out of people's heads and puts them on the wall. Now you can point at step four and say "this is where it breaks", and everyone knows what you mean. Maps aren't documentation. They're tools for conversation.
A lot of how we work here builds on Jim Kalbach's Mapping Experiences.
Maps are about value
Kalbach describes maps as a way to align people around value. Value happens where a person and an organisation meet: the person gets something they need, and the organisation gets something back. Maps that show both sides in one view, he calls alignment diagrams. Customer journeys and service blueprints belong to that family.
He also draws on Sheth, Newman and Gross, who split value into five kinds: functional, social, emotional, epistemic and conditional. Most teams only map the functional one. The other four are often where the interesting things hide.
Decide the purpose before you draw
Answer two questions before you draw a single box: What is the map for, and who is it for? A map for the team looks different from a map for top management. Also decide the point of view, where the experience starts and ends, and what to leave out.
Skip this, and you get the classic: a beautiful map on the wall that nobody looks at again.
Pick the right type
- Customer journey: how a customer moves through their relationship with an organisation. Good for pain points.
- Service blueprint: the service from what the customer does down through everything behind the scenes. Good when the problem lives inside the organisation. The format goes back to G. Lynn Shostack in the 1980s.
- User story map: the user's journey from left to right, with user stories under each step. Good for deciding what to build first. Made popular by Jeff Patton.
- Experience map: how people experience a whole area, like looking for a job, whichever organisation they meet.
Rule of thumb: if the question is "what do we build now?", you need a user story map. If it's "why does this keep breaking?", you need a service blueprint.
Insight first, drawing second
A map is never better than what it's built on. A map built on assumptions is just a very confident guess. Use interviews, observation, data and customer service enquiries.
A little consistency in the language goes a long way. Actions start with a verb, thoughts are questions, feelings are adjectives, and opportunities start with a verb of change like simplify or remove.
The map isn't the point
The conversation around the map is the point. We bring a rough draft, because a blank wall scares people and a draft that's a bit wrong gets them talking. We walk through it step by step, mark the few moments that make or break the relationship, and switch to "what could be different?" once today's situation is on the wall.
And we never leave without knowing who does what next. A map without follow-up is wallpaper.