Experience Mapping: Expose the System Behind the Outcome

A customer sees one outcome. The organisation produces it through many people, systems, policies, and handoffs.

That difference is where an experience map earns its place.

A useful experience map is a cross-boundary evidence model of how an outcome is produced over time. It connects actors and visible touchpoints with the backstage work, rules, dependencies, and transfers that shape what happens.

It is broader than a chronological journey and narrower than a model of the whole organisation. Its job is to expose where responsibility, information, and authority fail to travel with the experience.

The map should end in a decision: what to change, what to investigate, which boundary to renegotiate, or which uncertainty to leave visible.

Choose the artefact before opening the canvas

Several maps can contain rows, arrows, and touchpoints while answering different questions. Treating them as interchangeable produces a large diagram with no analytical centre.

A user journey map follows one bounded pursuit

A journey map reconstructs how a defined actor tries to reach a defined end state. It preserves sequence, branches, delays, channel changes, and the person’s changing context.

Use the journey-mapping evidence model when the decision depends on the path taken by one bounded population.

An experience map joins several perspectives around an outcome

An experience map asks how that outcome is produced across actors, channels, organisations, and time. It can include a buyer, user, approver, agent, operator, or affected third party when their work changes the same outcome.

It does not average those actors into one person. Their goals, evidence, authority, and consequences remain separate while the map makes their interdependence visible.

A service blueprint explains delivery mechanics

A service blueprint links customer actions to visible employee or system activity, backstage actions, and support processes. It is the better instrument when the question is how a defined service encounter is delivered.

An experience map may point to a blueprint where delivery detail explains a break. It need not absorb the blueprint’s full operating sequence.

A process map follows prescribed work

A process map shows how work is intended to move through activities and decisions. It often begins with the organisation’s procedure rather than a person’s outcome.

Compare process and experience when the designed route differs from what people actually do. Do not relabel the process as an experience because it has a sentiment lane.

Archetypes preserve meaningful differences between people

An archetype describes a recurring behavioural or contextual pattern that changes a product decision. It does not show how several actors and systems jointly produce an outcome.

Use evidence-backed user archetypes to decide which differences the experience map must preserve. Do not turn archetypes into swimlanes without evidence that they participate in this outcome.

Qualitative research produces bounded claims

Qualitative research investigates situations, meanings, and plausible mechanisms. An experience map can organise its findings alongside other evidence, but cannot repair weak sampling or convert interpretation into prevalence.

Use the qualitative-research claim standard before synthesis. The map is a model built from evidence, not a research method that creates evidence by itself.

Systems design changes technical behaviour

An experience map can reveal that state disappears at a handoff or that failure recovery has no owner. It cannot choose the architecture that should correct the problem.

The system-design guide for product managers covers authority, visible delay, failure, recovery, workload, and safe change after the relevant product promise is clear.

Write the map contract

“Map the customer experience” has no stopping condition. Before collecting evidence, write a contract for the decision surface.

Record:

• outcome: the observable change that matters, stated without naming your feature;
• actors: who acts, decides, supplies evidence, delivers work, or carries consequences;
• trigger and end: what starts this episode and what counts as completed, abandoned, transferred, or unresolved;
• time horizon: minutes, months, renewals, or another meaningful clock;
• service boundary: channels, teams, partners, policies, and systems currently in scope;
• decision: the choice the map is expected to inform;
• exclusions: adjacent journeys and actors deliberately left out;
• evidence period: when the represented events occurred.

The boundary should follow the outcome far enough to include off-product work and divided ownership. It should stop before “everything connected to the customer” becomes the scope.

GOV.UK guidance on creating an experience map follows users from needing a service until they stop using it.

It recommends consolidating several users’ experiences only when their stages and steps are sufficiently similar. This is public-service practice guidance, not evidence that one boundary works for every commercial product.

Reconstruct episodes before consolidating them

A workshop can compare evidence. It cannot substitute for evidence.

Build an episode record for each observed case before drawing the shared map:

• actor, goal, trigger, and relevant context;
• actions, decisions, waits, loops, and exits;
• channels, artefacts, and information exchanged;
• people, teams, and organisations involved;
• visible product or service state;
• backstage work and dependencies, where known;
• consequence when the outcome stalls or changes;
• source, date, population, and material limitation.

Use interviews about recent concrete events, observation, support and operations records, product data, policy documents, and artefacts people exchanged. Each source sees a different part of the system.

Do not infer a person’s reason from an event log. Do not use one memorable account as prevalence. Do not treat the designed process as evidence of what happened.

Halvorsrud, Kvale, and Følstad reconstructed mobile-broadband onboarding through interviews, paper diaries, call-centre and dispatch logs, and internet-traffic data.

They recruited 39 customers; 23 returned diaries and completed a second interview, and 16 of those journeys reached an established subscription line during the study.

The cases exposed ad hoc, irregular, failed, and missing touchpoints relative to the planned journey.

This was one Scandinavian telecom onboarding context with substantial non-completion of the study path. It shows what triangulation can reveal; it does not show that mapping itself improves service outcomes.

Build a map that can be challenged

The map needs enough structure to locate a mechanism, not enough decoration to imply certainty.

Use columns for meaningful phases or episodes rather than an ideal funnel. Use separate lanes for:

1. Outcome state: what progress, failure, transfer, or recovery means here.
2. Actors and authority: who acts, who decides, and who bears the consequence.
3. Actions and decisions: what each actor actually does.
4. Time: active effort, waiting, expiry, repetition, and deadline pressure.
5. Channels and touchpoints: where interaction occurs, including routes outside the product.
6. Information and artefacts: what must move, in which form, and what gets lost or recreated.
7. Visible state: what the person can see and safely conclude.
8. Backstage work: staff action, system behaviour, policy, supplier, and manual recovery.
9. Handoffs and dependencies: trigger, sender, receiver, required context, acknowledgement, and fallback.
10. Evidence status: observed, reported, measured, inferred, assumed, or conflicted.
11. Responsibility gap: missing owner, split authority, incompatible incentives, or an owner without control.
12. Decision: investigate, change, monitor, escalate, or accept with a stated reason.

These labels are an editorial scheme, not a validated measurement instrument. Adapt the lanes, but retain provenance and the separation between experience, explanation, and decision.

Bitner, Ostrom, and Morgan’s service-blueprinting paper separates customer actions, visible contact, backstage activity, and support processes across a service sequence.

The 2008 paper explains a design technique through cases. It does not report a controlled comparison showing that blueprints improve business or customer outcomes.

Patrício and colleagues extend service design across the service concept, service system, and individual encounter. They describe applications to a new retail grocery service and a bank-service redesign.

That paper offers an interdisciplinary method and application cases, not a causal estimate of effectiveness. Its useful warning is that encounter-level detail can miss the wider system in which the encounter gains meaning.

Make every handoff inspectable

An arrow is not a handoff model.

For each consequential transfer, record:

• the event that starts it;
• the actor sending work or information;
• the actor expected to receive it;
• the state and context that must travel;
• how receipt becomes visible;
• who can resolve ambiguity or refusal;
• what happens after delay or failure;
• which actor carries the cost while ownership is unclear.

The last question matters. Organisations often assign ownership to the team that receives the ticket while leaving the affected person to reconcile the experience.

GOV.UK guidance on mapping a user’s whole problem asks teams to inspect online and offline touchpoints, backend processes, involved parties, and required evidence.

It also recognises journeys that cross organisations. That is official guidance for UK public services, not an outcome study or a universal governance model.

Review the map as a contested model

Do not ask a large room whether the map “looks right.” Run a structured challenge with people who hold different parts of the evidence and different decision rights.

Send the map contract, episode records, and unresolved conflicts before the review. Keep presentation short. Spend the session testing the model.

Review in five passes:

1. Boundary: Are the outcome, actors, start, end, and exclusions coherent?
2. Evidence: Can every material claim be traced? Where are inference and assumption masquerading as observation?
3. Variation: Which cases branch, contradict the composite, or disappear in it?
4. Delivery: Which rule, system, role, or handoff could plausibly produce each break?
5. Authority: Who can decide, who must contribute, and where does no one control the whole mechanism?

The facilitator records disputes instead of forcing consensus. A disagreement between policy, event data, and frontline accounts may be the most decision-relevant part of the map.

Close with a disposition for every material break:

• change now under an existing obligation;
• investigate a named uncertainty;
• test a bounded intervention;
• renegotiate ownership or service boundary;
• monitor with a defined trigger;
• accept the condition and record the consequence.

“Opportunity” is too vague. Each disposition needs an owner, the next decision, evidence required, and the condition for returning to the map.

A fictional access-review experience

The following example is fictional. It illustrates the artefact and claims no product, service, or business result.

A B2B workspace requires customers to review privileged access every quarter. Product records review decisions, but the outcome is an accountable access state, not a completed screen.

The map includes an administrator, resource owner, security reviewer, support agent, and an integration that supplies employment status. Their goals and authority remain separate.

Episode records show a hypothetical branch: an owner does not respond, the administrator exports a list, a manager approves it by email, and support manually clears the overdue state.

The process map says the review is overdue. The experience map shows that authority moved to email while product state, audit evidence, and support action stopped agreeing.

The relevant handoff has no acknowledgement contract. The administrator cannot see whether the owner received the request, and support can alter status without attaching the off-product decision.

The map produces three different dispositions. Research must test why owners do not respond. Product and Security must define acceptable evidence. Operations must decide whether manual clearance is a recovery path or a policy breach.

“Redesign the review flow” would hide those separate mechanisms. The map is useful because it prevents one interface project from pretending to resolve all three.

Version claims, not posters

An experience map expires when the represented experience or its evidence changes materially.

Keep a compact header with the actor and outcome boundary, evidence period, included cases, known gaps, owner, last decision, and change triggers.

Useful triggers include a new channel, role, supplier, policy, operating model, or product state; a recurring exception; a changed risk; or evidence that contradicts a central mechanism.

Review the affected section after a trigger. Do not redraw the whole artefact on a ceremonial cadence.

Retain prior versions and the decisions attached to them. A change in the map may mean the service changed, the evidence improved, or the previous explanation failed.

Judge the map by harder questions than visual quality:

• Did it reveal a responsibility or authority gap that the process concealed?
• Can readers separate evidence from explanation?
• Are incompatible actor perspectives still visible?
• Did the team choose a narrower investigation or intervention?
• Can someone tell when the model must be challenged again?

The map is complete enough when it helps the organisation see how one outcome crosses its internal boundaries, then make those boundaries a subject of decision rather than a burden left to the user.

Sources

• Halvorsrud, Kvale, and Følstad: Improving service quality through customer journey analysis
• Bitner, Ostrom, and Morgan: Service Blueprinting: A Practical Technique for Service Innovation
• Patrício, Fisk, Falcão e Cunha, and Constantine: Multilevel Service Design
• GOV.UK Service Manual: Creating an experience map
• GOV.UK Service Manual: Map and understand a user’s whole problem

Read next

• Customer Success and Product: Turn Account Work into Product Capability applies a related service lens when account recovery, manual work, and repeatable product capability are being confused.