Activity ⚡ High

Journey Mapping

A journey map forces the team to see the product as the user experiences it — not as you designed it. It makes the gap between your intended design and the user's actual experience visible in one artefact.

Onboarding Flows Checkout & Payment Support & Error Recovery Cross-Platform Service Design Acquisition & Activation

01 — TL;DR

Two sentences.

A journey map is a visualisation of what a user thinks, does, and feels as they move toward a goal — across every touchpoint, not just the ones your team owns. It makes the gap between your intended design and the user's actual experience visible in one artefact, so the team can act on it together.

The format has roots in service design research from the 1980s and was formalised by firms like IDEO and the Nielsen Norman Group for digital product contexts. Its real value isn't the map itself — it's the alignment it forces: when engineering, design, and product all look at the same experience model, they stop optimising in silos.

02 — When to Use

Apply this when…

→ You are redesigning a flow that spans more than one screen or product surface

→ Users are completing the task but reporting frustration — qualitative signal without a clear root cause

→ The team has conflicting assumptions about what the user experience actually is

→ You are handing a project to a new team and need a shared starting point

→ A process involves offline steps, emails, or third-party touchpoints that your analytics don't capture

When NOT to apply it

Skip it when the problem is already narrowly scoped to a single component or screen. Also skip it when you have no user research to populate the map with — a journey map built from assumptions is just a fiction with sticky notes. Not useful under a 48-hour deadline or when the product is so early-stage that no real user journey exists yet.

03 — How It Works

The mechanism

A journey map works by shifting the unit of analysis from "screens we built" to "goals the user is trying to achieve." It surfaces the full arc of an experience — including the moments that happen outside your product — so the team can see friction, emotion, and breakage in sequence rather than in isolation.

The underlying research

Journey mapping draws on mental models research, particularly Indi Young's work on how users build internal models of processes to navigate them. Users don't experience your product as a set of features — they experience it as a sequence of attempts to accomplish something. When your product's structure doesn't match their mental model of the task, friction appears.

What it means in practice

Mapping the journey makes invisible moments visible: the email a user forwards to their manager before approving a purchase, the second browser tab they open to verify information, the support ticket they file instead of retrying a failed flow. These off-product moments are often where the real problems live, and they never appear in your funnel analytics.

The counter-intuitive nuance

Most teams assume the map will confirm what they already know. It rarely does. The highest-value insight from a journey map is almost always a phase the team didn't think was their problem — a pre-product awareness step, a post-product follow-up task, or a handoff to another team that nobody owns. The map is most useful when it makes someone uncomfortable.

How to measure or test for it

Validate the map against real session recordings, support ticket themes, and a minimum of five user interviews. A journey map built without these inputs is a hypothesis document, not a research artefact. Treat any stage on the map where your team can't point to a data source as a research debt item.

Living document, not finished artefact

A journey map is a snapshot, not a permanent truth. If your product ships a significant onboarding change, the map is outdated. Teams that treat the map as a finished document rather than a living research artefact build on stale assumptions within two quarters. Schedule a review cadence when you create it.

04 — Real Example

Airbnb's host onboarding and the moment they almost lost their best users

Airbnb's host onboarding is a textbook application of journey mapping because the team explicitly documented that the hardest part of becoming a host happened before the product was ever opened — hosts needed to photograph their space, set expectations with their household, and mentally commit to hosting strangers. The app couldn't fix any of that, but Airbnb could.

The result was a pre-digital layer of support: professional photography services, host community groups, and educational emails that addressed the emotional journey, not just the transactional one. The product onboarding became faster and cleaner because the real blockers had been handled upstream — and this insight only surfaced because the team mapped beyond their own screens.

Airbnb · Host Onboarding

Extended the map beyond the product boundary

Pre-digital support layer unlocked growth

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product that ignores the journey before or after their own screens? Submit a screenshot and the stage it breaks down. Every approved example gets attributed to you.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Journey Mapping violated in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Mapping the happy path only. Teams plot the journey as it should go, not as it does go. A journey map that never shows a frustrated face or a detour to a competitor's help page isn't a map — it's a PR document. Every map must include at least one failure mode per stage or it hasn't been validated against real behaviour.

✗ Building it in a room without users. A journey map produced in a two-hour workshop from team assumptions is a hypothesis artefact. That's fine as a starting point, but teams ship from it as if it were research. Any stage not grounded in at least one user data source — interview, session recording, support ticket — should be explicitly flagged as "unvalidated."

✗ Stopping at the product boundary. Journey maps that begin at "user opens app" and end at "user completes task" miss the most actionable insights. The decision to use your product, the workaround the user runs after leaving it, and the conversation they have with a colleague — these are on the map too.

✗ Making the map, then shelving it. The map gets presented to stakeholders, praised, printed, and forgotten. It needs to be tied to a backlog. Every stage with a friction rating above a defined threshold should become a research or design ticket within the same sprint. If the map doesn't change what the team works on next, it was a waste of three days.

07 — Variations & Related Principles

Connected ideas

Journey mapping sits at the intersection of user research and systems thinking. It's most powerful when combined with the frameworks that govern individual interaction moments — because it shows you which moments matter most before you invest in optimising them.

The most important pairing is Journey Mapping with Jobs to Be Done. A map without JTBD is a timeline of events; a map with JTBD is a model of motivation. When you know what job each stage is serving, you can identify which friction is worth removing and which friction is actually doing useful work — like a confirmation step that prevents costly errors.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo or Team · No prep

The Five-Stage Sketch

Pick one flow your product owns end-to-end — onboarding, upgrade, or a support recovery.

1. On paper or a whiteboard, draw five boxes in a row and label them with the five stages a user moves through to complete that goal. Don't use your product's screen names — use the user's goal language ("Decides to upgrade" not "Hits the pricing page").

2. Under each stage, write one thing the user is doing, one thing they are thinking, and one thing they are feeling. Pull from memory if you have research; flag it as a hypothesis if you don't.

3. Draw a line above the stages representing emotional experience — high means smooth and confident, low means frustrated or stuck. Be honest. If you've read any support tickets this month, they'll tell you where the line dips.

4. Circle the lowest point on the line. That is your primary research and design target. Write one specific question you don't currently know the answer to about that stage. That question is your next user research prompt.

10 minutes