User Journey Mapping: Build an Evidence Model

The map shows a clean sequence: discover, compare, sign up, activate, succeed.

Support hears a different story. Customers leave the product to ask a colleague for a document, repeat identity checks on another channel, and call an agent who re-enters data the company already holds.

The map is not simplified. It is wrong in the places where the service becomes expensive and difficult.

A useful user journey map is an evidence model of how a bounded group tries to achieve a goal over time. It preserves branches, delays, hand-offs, failures, and uncertainty well enough to change a decision.

The diagram is only its interface.

Bound the journey before drawing it

“Map onboarding” is not a research boundary. Different actors can enter with different knowledge, authority, risk, and definitions of success.

Write a journey statement:

For this actor in this context, understand how they move from this triggering need to this observable end state, so we can decide this product or service question.

Define six boundaries:

• Actor: the person doing the work, including their role and relevant circumstance;
• goal: the change they are trying to make, not the product feature they use;
• start: the event that creates the need, which may happen before product discovery;
• end: the state in which the goal is complete, abandoned, transferred, or unresolved;
• current or proposed: observed service today or a future hypothesis;
• decision: the choice the team expects the map to inform.

Keep current-state evidence separate from a proposed journey. Combining them creates a polished fiction in which desired steps look observed.

GOV.UK guidance on creating an experience map describes what users do, think, and feel over time, from needing a service until they stop using it.

It recommends separate maps when participant groups follow substantially different stages or steps.

That is public-service guidance, not a universal segmentation rule. Its useful challenge is to avoid averaging incompatible journeys into a person nobody researched.

Build individual histories before the composite

A workshop can organise evidence. It cannot manufacture it.

Reconstruct individual journeys first. Use sources that reveal different parts of the experience:

• observation in the user’s environment;
• interviews tied to specific recent events;
• support cases, complaints, and assisted-service notes;
• product and operational event data;
• search, call, email, paper, or partner touchpoints;
• artefacts people create or exchange to complete the task;
• policy, eligibility, and process records.

GOV.UK’s contextual research guidance defines the method as observing people performing an activity in their everyday environment.

Its scope is government user research. The relevant advantage is seeing equipment, interruptions, workarounds, other people, and off-product activity that an interview or event log may miss.

For each participant, retain sequence, elapsed time, repetitions, channel changes, dependencies, and the point where the journey ended. Do not force every history into the planned process.

Then build the composite by comparing histories. A common stage belongs on the map because evidence supports it, not because the workshop needs another column.

The continuous-research system explains how to manage evidence demand, provenance, coverage, and expiry across open product decisions.

Mark what the evidence can support

Each journey element needs provenance.

Use evidence labels such as:

• Observed: directly seen or recorded for a bounded participant or population;
• Reported: described by a participant, agent, or stakeholder;
• Measured: represented in validated operational or product data;
• Inferred: the best current explanation connecting available evidence;
• Assumed: included to complete the model but not yet adequately tested;
• Conflicted: credible sources support different accounts.

These are editorial labels, not grades of scientific certainty. Record the source, population, date, and material limitation beside the relevant step.

“Users feel anxious” is weak without evidence and context. “Four recent applicants described uncertainty after submitting because no channel showed whether evidence had been accepted” preserves population, moment, and cause as reported.

Do not treat a quote as prevalence or an event count as explanation. Qualitative and quantitative evidence answer different questions.

When the sources disagree, keep the disagreement visible. A process owner may describe the designed path while event data shows repetition and users describe an off-platform workaround.

That contradiction is often more valuable than a single tidy lane.

Preserve branches and missing touchpoints

Journeys are not funnels drawn sideways.

A funnel usually compares defined populations at selected events. A journey map reconstructs the person’s changing context, actions, channels, dependencies, and experience around those events.

Use the separate funnel-analysis guide when the decision depends on population, sequence, clocks, identity, and conversion definitions.

On a journey map, show:

• alternative entry points;
• optional and mandatory steps;
• loops and repeated attempts;
• pauses caused by another person or organisation;
• channel switches;
• workarounds outside the service;
• abandonment and return;
• assistance and escalation;
• missing interactions the user expected.

Halvorsrud, Kvale, and Følstad proposed customer journey analysis for a structured account of multichannel service delivery from the customer’s perspective.

Their broadband-onboarding case studies reconstructed individual journeys through interviews, diary studies, and process tracking.

They identified ad hoc touchpoints, irregular sequences, failures, and missing touchpoints as forms of deviation from planned delivery.

This is a framework developed through one service context, not proof that its notation or deviation types cover every product. The important transfer is methodological triangulation between the planned and actual journey.

Do not label every deviation as user error. A repeat, branch, or workaround may be a rational response to incomplete information, organisational delay, or risk the product does not acknowledge.

Add the service only where it explains the experience

The journey lane follows the user’s goal. It should not become an internal process map with an emotion row attached.

Add service information when it helps explain a break:

• channel or touchpoint;
• visible product state;
• responsible team or organisation;
• backstage process or dependency;
• evidence the user must supply;
• rule, policy, or hand-off that changes the path;
• system event that makes the visible state true.

For complex services, maintain a separate service landscape or blueprint linked to the journey. That preserves the user’s perspective while making ownership and operational causes inspectable.

GOV.UK’s guide to mapping a user’s whole problem recommends examining online and offline touchpoints, backend processes, involved parties, and required evidence.

It explicitly notes that complicated journeys can cross organisational boundaries.

The guidance addresses public services, where legal and institutional hand-offs can be unusually prominent. Product teams should transfer the end-to-end question, not copy the government artefact uncritically.

If nobody owns a broken transition, record that as a finding. Assigning every step to the nearest product team hides the governance gap.

Show time as experienced, not scheduled

The designed process may contain five steps. The experienced journey may contain three weeks of waiting between two of them.

Record:

• active effort;
• elapsed delay;
• expected and actual response time;
• number of attempts;
• time spent finding status or help;
• expiry, deadline, and restart conditions;
• work performed while the outcome remains unknown.

Do not draw a smooth emotional curve from workshop intuition. Attach emotion, confidence, or perceived effort to specific evidence and moments.

A long delay may be acceptable when expectations, status, and consequence are clear. A short delay may be harmful when the user does not know whether money moved or a deadline was met.

Journey time is therefore not one metric. Active work, waiting, recovery, and uncertainty create different product choices.

Turn a break into a decision candidate

“Improve the confusing step” is not yet a product decision.

Create a break record:

1. Observed break: what happens and for which bounded group?
2. Consequence: abandonment, delay, harm, cost, repeated work, or loss of control?
3. Mechanism: why might the break produce that consequence?
4. Evidence: what supports and challenges that explanation?
5. Ownership: who controls the cause, transition, or recovery?
6. Intervention: which part of the mechanism would change?
7. Downstream effect: where might the burden move?
8. Test: what evidence would distinguish improvement from displacement?

Rank breaks by consequence, frequency within the relevant population, strategic importance, and ability to intervene. Do not multiply the fields into a pseudo-objective score.

A low-frequency failure can deserve priority when the harm is severe. A frequent annoyance can remain secondary when it does not block the goal and would consume capacity needed for a material break.

Map the downstream journey before calling an intervention successful. Removing a form field may improve digital completion while transferring missing information to support or delaying fulfilment.

Maintain the map as a versioned claim

A current-state map expires when the population, policy, channel, product state, or operating process changes materially.

Put a small evidence header on the map:

• actor and inclusion boundary;
• journey start and end;
• research and data period;
• source mix and coverage gaps;
• owner;
• last material review;
• change triggers that require revalidation;
• decisions made from this version.

Do not schedule a ceremonial redraw every quarter. Review the map when evidence or the service changes enough to affect a decision.

Useful triggers include a new channel, policy change, segment expansion, major workflow release, repeated support pattern, or measurement conflict.

Retain previous versions. The difference between them shows whether the service changed, the evidence improved, or the original model was wrong.

A fictional supplier-onboarding journey

Consider an explicitly fictional marketplace onboarding small suppliers. The planned journey moves from invitation to identity check, catalogue upload, and first listing.

Individual histories reveal another path. Some suppliers ask an accountant for ownership evidence, fail a mobile upload, switch to email, and wait without knowing whether review started.

The composite map labels the email workaround as observed in a bounded research sample. Operational data confirms repeated uploads but cannot explain why they happened.

The service landscape shows that email attachments enter a separate queue with no shared status. Compliance owns the decision, Operations owns the queue, and Product owns the visible application state.

The decision candidate is not “redesign onboarding.” It is whether to create one evidence-submission state across web and assisted channels, with explicit receipt, review status, and recovery for rejected files.

The team would test completion, repeated submissions, assisted contacts, time in unknown status, and compliance errors. It would also inspect whether burden moved to reviewers.

No result is claimed. The example shows how a map turns off-product behaviour and divided ownership into a bounded product decision.

Judge the map by the decisions it changes

Map quality is not the number of touchpoints, workshop participants, colours, or emotional annotations.

Ask instead:

• Can a reader distinguish evidence, inference, and assumption?
• Are materially different journeys still visible?
• Does the map include the user’s whole goal rather than the product’s screen boundary?
• Can the team locate delay, repetition, hand-offs, and missing states?
• Is ownership explicit where the journey breaks?
• Did the map change an intervention, test, priority, or service boundary?
• Is there a trigger for revisiting the claim?

GOV.UK’s cross-channel Service Standard guidance asks teams to connect online and offline evidence.

It also asks them to understand how changes in one channel affect another.

That is an assessment standard for UK public services, not an outcome study. Its enduring question is whether the product improves a journey or merely moves its failure somewhere less visible.

A journey map earns its place when it makes that movement visible before the organisation ships it.

Sources

• Halvorsrud, Kvale, and Følstad: Improving service quality through customer journey analysis
• GOV.UK Service Manual: Creating an experience map
• GOV.UK Service Manual: Contextual research and observation
• GOV.UK Service Manual: Map and understand a user’s whole problem
• GOV.UK Service Standard: Provide a joined up experience across all channels

Read next

• Continuous Research: Build an Evidence Flow, Not an Interview Habit
• Funnel Analysis: Make the Decision Model Explicit
• Cross-Functional Collaboration: Make Expertise Change the Decision
• Experience Mapping: Expose the System Behind the Outcome