The Journey Map Is a Decision Tool

A journey map should help you choose what to change and how to test it. I start with one person's experience and keep the supporting evidence close.

It is easy to spend time getting the diagram right. Before doing that, I want to know which decision the map needs to help us make.

What makes a journey map useful for product decisions?

It depends on the decision. To understand today's experience, build a map from research and mark gaps. To explore a proposed service, map the hypothesis and test it. When the problem depends on internal work, add a service blueprint. In each case, finish with a proposed action and a way to assess it.

A journey map shows how a particular person moves through an experience toward a goal.

That working definition follows NN/g's journey mapping guidance. As of October 2026, its guide recommends a clear viewpoint and connects the experience to opportunities and ownership.

Whose experience are you mapping?

First, choose whose experience you are following. A customer asking for a refund and the support agent handling it see different parts of the same service. I keep that viewpoint clear.

Take a hypothetical refund service. I start when the customer decides to ask for their money back. I follow it until they understand what happened and receive the agreed outcome.

The support team's work belongs in supporting notes or a blueprint. That lets us connect the internal process while keeping the customer's experience clear in the main map.

Check the endpoint carefully. Every department can have its task marked complete while the customer is still waiting for money. The map needs to show that gap.

How do you build a map from evidence?

Here is the order I use to build it:

1. Reconstruct recent cases. Follow each person's account before combining the material into shared stages.
2. Compare the timelines. Keep materially different paths separate, including cases that failed or needed help.
3. Attach evidence to the important moments. Distinguish reported experience from observation and interpretation.
4. Add an opportunity and a proposed test. Name the person who can act on the finding.

Suppose the customer reports repeatedly checking their account after approval. I record that account, then look at the confirmation they received. What did it tell them to expect?

An empty emotion field can tempt you to fill it. I use the person's words when they describe how they felt. If the team infers uncertainty, I label it as an inference.

I keep the original material accessible as the map develops. Someone should be able to check an account and question our interpretation. That helps us improve the explanation.

What fields help you make the decision?

I use a format the team can keep current, such as a shared document or spreadsheet. A simple file is enough to start. I use these fields to connect the experience to a decision:

Field	What it helps you decide
Supporting evidence	Whether the finding is ready to act on
Consequence for the person	Whether this moment deserves attention
Internal owner	Who can change the cause
Proposed test	What evidence would support the change

These fields are my practical adaptation. I want to follow the reasoning from what someone experienced to what we propose doing about it.

For the refund, I try a clearer confirmation message. Explain accurately what happens after approval, then check whether the customer understands it. That gives us a small first test.

If the message depends on unavailable payment information, that dependency belongs beside the proposed test. It changes what the team can deliver.

Does journey mapping improve business results?

I judge the map by the change it helps us choose. To assess a business benefit, we need evidence about that change. Finishing the document gives us something different.

McKinsey's 2016 analysis reported a 50% wider satisfaction gap for journey performers than touchpoint performers in one surveyed industry.

That compares the top and bottom quartiles of companies on those measures. It describes an association in customer-experience surveys, with limited methodological detail in the article.

It leaves the effect of journey mapping itself unmeasured. I set a baseline for the change we actually plan to make. Then we can check what happens after testing it.

For a refund confirmation, useful measures might include repeated status enquiries and whether customers understand the next step. Check the records available before choosing a target.

How do you decide which moment to improve first?

I compare what the problem costs the person with what we know about its cause. Then I check what changing it requires. Sometimes a policy decision sits ahead of any development work.

Make that dependency visible before prioritising development. Ask the responsible owner whether the proposed change is feasible and what else it affects.

Clearer confirmation might help our hypothetical customer. Receiving the refund sooner might matter more. I use the research and operating records to choose which problem to test next.

I keep possible solutions separate from the problem on the map. That gives us room to compare clearer communication with an integration, or a different owner for the work.

How should the map change during development?

I update the map when a test changes our explanation or direction. I record what happened and leave the remaining questions visible. That keeps it useful during development.

Teresa Torres ties ongoing discovery to a desired outcome. The map can give that work a common reference, provided the team keeps its evidence current.

Move the chosen outcome and boundaries into the PRD. During Iterative development, check whether the proposed change improves the experience at the point we identified.

That connection starts Before the PRD. If the cause sits in internal handoffs, see Your Best AI Opportunity May Be Between Two Screens.

We use the same connection between Discovery and Requirements in the process. See the available offers, or book a call with the journey and the decision it needs to inform.

Give the map a decision to support. Keep using it as you learn what needs to change.

What else should you know about journey maps?

What should a journey map include?

Include the actor, scenario, stages, and evidence about the experience. Add opportunities and ownership so the map can guide a decision.

Can we make a journey map before research?

You can map assumptions to plan research. Label them clearly and replace them with evidence before treating the map as today's experience.

Should every stakeholder go on the same map?

Keep a clear viewpoint for each journey. Use related maps or a service blueprint when you need to connect different roles and internal responsibilities.

How do we know a journey map was useful?

Check whether it changed the priority, identified an owner, or guided a test. Measure the resulting change against the user's intended outcome.