Why you need a map

I learned mapping by osmosis. A bit at university, a bit from mentors, a lot from trial and error. For years I could make a decent journey map without being able to explain why it worked. Then I read Kalbach and things clicked.

Here's the short version.

Why map at all?

A map shows how things connect, so people can talk about them.

That's it. That's the trick.

Everyone on a project carries a model of the service around 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. Nobody's model is wrong, but nobody's is complete either.

A map takes those 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 falls apart", and everyone knows what you mean.

Maps aren't documentation. They're conversation tools.

Maps align for value

Kalbach frames the purpose of mapping as aligning for value. Value happens where an individual and an organization meet: the person gets something they need, and the organization gets something back. Designing around that exchange is what he calls value-centered design.

A diagram that shows both sides of the exchange in one view is what he calls an alignment diagram. Journey maps, service blueprints and experience maps all belong to that family.

Kalbach also draws on consumer research by Sheth, Newman and Gross, which describes five types of value:

• Functional: can I get the task done? Reliability and performance.
• Social: value from connecting with other people.
• Emotional: the feelings you have along the way.
• Epistemic: curiosity, learning and personal growth.
• Conditional: value that depends on the situation. Pumpkins in October.

Most teams only map functional value. The other four are often where the interesting stuff hides.

Step 1: Decide purpose and audience

Before you draw a single box, answer two questions:

1. What will this map be used for? Finding pain points? Getting leadership to share one picture of the customer? Planning releases?
2. Who is it for? A map for your team looks different from a map for the executive group.

Then make it concrete by choosing:

• Point of view: whose experience are you mapping?
• Scope: where does the experience start and end?
• Focus: what goes in, and what stays out?
• Structure: chronological, hierarchical, something else? Decide before you start.

Skip this step and you get the classic: a beautiful map on the wall that nobody looks at again.

Step 2: Pick the right type

All of these tell an aggregate story of behavior across a group of people. What differs is how they tell it.

• Customer journey map: how a customer moves through their relationship with an organization, from first contact to (maybe) leaving. Great for pain points and moments of truth.
• Service blueprint: the service in chronological order, from what the customer does down through the frontstage, backstage and support processes that make it happen. Great when the problem lives inside the organization. The format goes back to G. Lynn Shostack in the 1980s.
• User story map: the user's journey laid out left to right, with user stories hanging under each step. Great for deciding what to build and slicing releases. Popularized by Jeff Patton.
• Experience map: broader than any one product. It shows how people experience a whole domain, like looking for a job, regardless of which organization they deal with. Great for strategy and spotting new opportunities.

Rule of thumb: if the question is "what do we build next?", you want a story map. If it's "why does this keep breaking?", you want a blueprint.

Step 3: Research first, draw second

A map is only as good as what it's built on. Base it on research: interviews, observation, data, support requests. A map built on assumptions is just a very confident guess.

When you write the content, a little consistency goes a long way:

• Actions start with a verb: "download app", "call support"
• Thoughts are questions: "Is this included in the fee?"
• Feelings are adjectives: unsure, relieved, annoyed
• Pain points start with an -ing word: "waiting for approval"
• Touchpoints are nouns: email, app, front desk
• Opportunities start with a verb of change: reduce, remove, simplify

Step 4: Run the mapping session

The map isn't the point. The conversation around it is. Here's how I usually run one:

1. Invite a mix. People who own parts of the service, people who talk to users, and someone who can make decisions. At least one person who does the actual work day to day.
2. Bring a rough draft. A blank wall scares people. A draft that's a bit wrong gets them talking.
3. Walk it together. Step by step. Ask "what's really happening here?" and "who's involved that we can't see?"
4. Mark the moments of truth. The few interactions that make or break the relationship. They're usually emotional, and they're usually where your effort belongs.
5. Hunt for opportunities. Once the current state is on the wall, switch to "what could be different?"
6. Leave with decisions. Who does what next? A map without follow-up is wallpaper.

If you want the long version, Kalbach describes the whole process in four modes: initiate, investigate, illustrate and align.

Principles to keep you honest

• Show the big picture. Zoom out far enough to see the ecosystem.
• Include several dimensions. Actions, thoughts and feelings on one side. Processes, roles and metrics on the other.
• Show the value exchange. Where does each side get something?
• Make it visual and self-evident. If it needs a ten-page explanation, it's a report.
• Make it relevant. Tie it to the goals and challenges the organization actually has.

Why it matters

Experiences are personal, holistic and situational. You can love roller coasters and still regret one right after a big lunch. That's hard to capture in a spreadsheet.

A map won't capture it perfectly either. But it gets everyone looking at the same thing. That's usually where the real work starts.