📖 Complete Guide

User Journey Mapping: Building a Map That Actually Changes the Product

Most journey maps end their lives as a beautiful poster nobody looks at again. The difference between decoration and a decision-making tool is what you put in the last row. Here's the six-row template, a one-day workshop that uses real evidence, a worked SaaS example, and how to turn the map into shipped changes.

📅 Updated July 2026 ⏱ 12 min read ✍️ By Kompassify
A user journey flow for a SaaS product showing the stages users move through from signup to activation and where they drop off

There is a journey map on a wall in most product companies. It is large, it is colourful, it took three days and a facilitator, and if you ask when it last changed a decision the room goes quiet. Meanwhile the actual journey it describes has moved on — two of those screens were redesigned last quarter and the email in stage three was switched off in March.

This is a shame, because journey mapping is genuinely one of the most useful things a cross-functional team can do. It forces a group of people who each own a fragment of the experience to look at the whole thing in order, from the outside. The failure isn't the method — it's stopping one row too early. A map that documents pain is a poster. A map whose last row names a change, an owner and a next step is a plan.

This guide covers what a user journey map is and how it differs from its relatives, the six rows every map needs, a one-day workshop process built on real evidence, a worked SaaS onboarding example with the emotion curve, how to convert the map into shipped in-product changes, and how to keep it alive rather than let it decay on a wall.

Key Takeaways

  • One user, one goal, one journey. Maps that try to cover everyone cover no one specifically enough to act on.
  • Six rows: stages, actions, touchpoints, thoughts, emotions, opportunities. The last one is the reason to do the exercise.
  • Bring evidence, not opinions. Funnel data, session recordings, support tickets and five to eight real conversations before anyone opens a template.
  • Plot the emotions as a curve. The dips are your backlog, in priority order, and they are visible at a glance to people who won't read the rest.
  • Every dip becomes a named opportunity with an owner and a next step — otherwise the map has no mechanism to change anything.
  • Match the intervention to the dip: confusion → clearer words or a tooltip, abandoned task → a walkthrough, stalled setup → a checklist, unseen feature → a hotspot.

What Is a User Journey Map?

A user journey map is a visual model of one user type pursuing one goal, laid out in stages, annotated with what they do, where they do it, what they think, how they feel, and what could be better. It's a shared artefact more than an analytical one: its main job is to get product, design, engineering, support and marketing looking at the same experience in the same order, so that disagreements become visible instead of structural.

User journey map, defined. A stage-by-stage picture of one user segment's path toward one goal, capturing actions, touchpoints, thoughts and emotions, and ending in a prioritised list of opportunities. Narrow by design: the value comes from specificity, not coverage.

Four artefacts get called "journey maps" and only one of them is what a product team usually needs:

Artefact Covers Best for
User journey map One user, one goal, inside the product Fixing a specific experience — onboarding, setup, a workflow
Customer journey map The whole relationship, including pre-purchase Aligning marketing, sales, product and success
Service blueprint The user's path plus everything backstage Diagnosing operational and systems causes
Funnel Conversion rates between defined steps Measuring where people drop, at scale

The funnel row is worth dwelling on, because funnels and journey maps are complements rather than alternatives. A funnel tells you that 44% of users abandon at "connect a data source"; a journey map tells you that they abandon because they don't have the credentials, don't know who in their company does, and have no way to hand the step to a colleague. One gives you the size of the problem, the other gives you the fix — which is why the strongest teams build the map after reading the funnel numbers, not instead of it.


The Six Rows Every Journey Map Needs

1. Stages — the phases of the journey

Four to seven, named from the user's perspective rather than yours. "Deciding whether this will work for us" is a stage; "MQL nurture" is not. For a SaaS onboarding journey the natural set is roughly: discover → sign up → set up → first use → first value → habit.

2. Actions — what the user actually does

Concrete and observable, in the user's words. "Pastes an API key they got from a colleague on Slack" rather than "authenticates". The specificity is the point: vague actions produce vague opportunities.

3. Touchpoints — where each action happens

The screen, the email, the notification, the documentation page, the support conversation. This row is where cross-team ownership becomes visible, and it routinely surfaces the surprise that one stage is owned by four different teams who have never spoken about it.

4. Thoughts — what's in their head, in their words

Real quotes from research or support tickets wherever possible. "I don't know if this saved" and "am I going to get charged for this?" are worth more than any paraphrase, and they're what make the map persuasive to people who weren't in the room.

5. Emotions — the curve that makes the map readable

A simple line or set of faces, high to low, across the stages. This is the row executives read and the row that makes priorities self-evident: the deepest dip that sits closest to your revenue is where the next sprint goes.

6. Opportunities — the row most maps skip

For each dip: what specifically would improve it, who owns it, and what the next step is. Without this row you have a description of a problem; with it you have a backlog with evidence attached. If you can only do two rows properly, do emotions and opportunities.


How to Build One in a Day

A focused product journey map does not need a three-week programme. It needs preparation, two to three hours in a room, and a written-up outcome.

1. Choose one segment and one goal (30 minutes, before the workshop)

"A first-time admin at a 20-person company getting to their first shared report." Not "our users". If you have segments defined already, pick the one with the most upside — usually the biggest group with the worst activation. Write the goal at the top of the board and defend it for the whole session.

2. Gather the evidence (half a day)

Four sources, none optional: your funnel data for where people actually drop; session recordings for what the drop looks like; a month of support tickets tagged by topic; and five to eight conversations with users who recently made this journey. The conversations are what supply the thoughts row, and they are the difference between a map that surprises the team and one that flatters it.

3. Lay out stages, actions and touchpoints (45 minutes)

Fast and collaborative — sticky notes or a shared board, everyone writing simultaneously. Expect and welcome the first argument: teams routinely discover they disagree about what happens between signup and setup, and that disagreement is often the most valuable output of the day.

4. Add thoughts and plot emotions (45 minutes)

Read the real quotes out loud as you place them. Then plot the curve as a group — where people feel confident, where they feel lost. Disagreement about a point on the curve almost always means nobody has actually watched a user at that stage, which is itself a finding worth writing down.

5. Convert every dip into an opportunity (45 minutes)

The part that makes the day worth it. For each low point: what would fix this, what's the smallest version of that fix, who owns it, what happens next. No dip leaves the room without a name attached to it. End the session by picking the two you'll ship first — not the ten you'll consider.

The workshop failure to avoid: building the whole map from internal knowledge because gathering evidence would delay things by a week. A map made of assumptions is worse than no map, because it launders opinion into an artefact that looks like research and then gets cited for a year.


A Worked Example: SaaS Onboarding Journey Map

Here is the template filled in for a familiar journey — a new admin getting from signup to a first shared report. The emotion row is where the priorities announce themselves:

Row 1. Sign up 2. Set up 3. Connect data 4. First report 5. Share & repeat
Actions Creates account with work email, skips the profile fields Names the workspace, clicks through the welcome tour Opens integrations, looks for credentials, asks a colleague Picks a template, changes the date range, exports Sends the link, sets a weekly reminder
Touchpoints Signup form, verification email Welcome screen, product tour Integrations page, docs, Slack, support Report builder, empty state, export dialog Share modal, notification email
Thoughts "Fine, let's see what this does." "I'll skip this — I'll figure it out." "Where do I even get this key? Is this going to expose our data?" "Is this number right? It doesn't match our other tool." "OK, this actually saves me an hour a week."
Emotion 🙂 😐 😟 🙂 😀
Pain Tour explains the UI, not the outcome; skipped by most Blocked on credentials they don't hold; no way to delegate No explanation of how figures are calculated
Opportunity Ask one intent question to branch the path Replace the tour with a 3-item checklist showing progress Add "invite a teammate to finish this step" + a demo-data path Tooltip on each metric explaining the source and formula Prompt to schedule it — turn a win into a habit
pain points — where the curve dips opportunities — what ships next

Read the emotion row alone and the priority is unmistakable: stage three is where this product loses people, and it loses them for a reason no redesign of the reports screen would have touched. Note also the shape of the opportunities — none of them are "rebuild the integrations page". They're a question, a checklist, a delegation path, a tooltip and a prompt. Journey maps built on evidence tend to produce small, specific, shippable work, which is exactly why they're worth the day.


From Map to Shipped: Matching Fixes to Dips

The most common reason a good map produces nothing is that the opportunities are phrased as projects. Break them down by matching each type of dip to the intervention that fits it:

What the dip looks like The likely cause The fix that fits
Hesitation at a single control Unclear label or unstated consequence Rewrite the microcopy; add a tooltip
A multi-step task abandoned midway Too much unexplained work at once A guided walkthrough on real data
Setup stalls and never resumes No sense of progress or what remains An onboarding checklist with saved state
A valuable feature is never found Discoverability, not quality A hotspot at the moment of relevance
Blank screen, no first move An empty state that explains nothing Turn the empty state into a starting line
The user asks a question you can predict Answer lives outside the product In-app support at that step
Why they dipped is genuinely unclear You're guessing at motive An in-app survey at that exact step

Most of these are guidance-layer changes rather than product rebuilds, which matters for a practical reason: they can ship in days. A map whose top three opportunities are all a quarter of engineering work will be quietly abandoned. A map whose top three can be live next week gets a second edition.

An activation flow report showing where users progress and stall across the journey stages mapped in a user journey map
(The funnel gives the map its dips a size; the map gives the funnel's drop-offs a reason. Neither is much use alone.)

Keeping the Map Alive

Version it, date it, and own it

A map with no date is assumed current forever. Put the date and the segment in the title, name a single owner, and set a recurring review — quarterly is enough for most products. A map nobody owns decays into folklore within two releases.

Attach live numbers to the stages

Put the current conversion rate on each stage boundary. The map stops being a static picture and starts being a scoreboard: when a stage's number moves, the annotation next to it explains why it mattered.

Close the loop publicly

When an opportunity ships, mark it on the map and note what happened to the number. Three visible wins are what convert journey mapping from "that workshop we did" into something the team asks to repeat.

Re-map when the journey genuinely changes

Not on a schedule for its own sake, but when a redesign, a new segment or a pricing change alters the path. Re-mapping a changed journey takes a fraction of the first effort, because the template and the evidence habits already exist.


Journey Mapping: Do vs. Don't

✅ Do

  • Map one segment pursuing one goal
  • Bring funnel data, recordings, tickets and interviews
  • Use the user's own words in the thoughts row
  • Plot emotions as a curve so the dips are obvious
  • Give every dip an owner and a next step
  • Prefer opportunities that ship in days
  • Date the map and review it quarterly
  • Mark shipped fixes and what they moved

❌ Don't

  • Map "all our users" across every possible path
  • Build the whole thing from internal assumptions
  • Name stages after your funnel or org chart
  • Stop at describing the pain
  • Let the opportunities all be quarter-long projects
  • Print it, frame it, and never touch it again
  • Confuse it with a service blueprint or a funnel
  • Run the workshop without anyone from support

Turning Journey Map Opportunities Into Live Changes

The gap between a good map and a better product is usually delivery speed. With Kompassify most journey-map opportunities become live changes without a release:

Kompassify is GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.

Ship the Fixes Your Journey Map Found

Kompassify lets you turn journey-map opportunities into live product changes — tooltips, guided walkthroughs, onboarding checklists and hotspots on top of your existing product, no code and no release cycle. Target the exact segment you mapped, then watch the dip flatten. GDPR compliant, EU-hosted, and free for under 100 monthly active users.

Start for Free →

Frequently Asked Questions

What is a user journey map?

A user journey map is a visual model of the path a specific type of user takes toward a specific goal, showing at each stage what they do, where they do it, what they are thinking, how they feel, and where the product could serve them better. It is deliberately narrow: one user type, one goal, one journey. The point is not to document everything a user could do, but to make the shape of one important experience visible enough that a cross-functional team can agree on where it breaks.

What is the difference between a user journey map and a customer journey map?

Scope. A customer journey map covers the whole commercial relationship — awareness, evaluation, purchase, support, renewal, advocacy — including everything that happens outside the product. A user journey map focuses on someone using the product to accomplish something: signing up and reaching first value, setting up an integration, completing a recurring workflow. Product and onboarding teams almost always want the user version, because its rows map directly to screens they can change.

What should a user journey map include?

Six rows. Stages, which are the phases of the journey. Actions, which are what the user does in each stage. Touchpoints, which are where it happens — screens, emails, notifications, support. Thoughts, ideally in the user's own words from research. Emotions, plotted as a curve so the dips are obvious. And opportunities, which is where each pain becomes a specific, ownable change. The last row is what separates a map that ships work from a poster that decorates a wall.

How do you create a user journey map?

Pick one user segment and one goal, gather evidence before the workshop (funnel data, session recordings, support tickets, five to eight user conversations), then run a two-to-three hour session: lay out stages, fill in actions and touchpoints, add real quotes for thoughts, plot the emotion curve, and mark the dips. Finish by converting every dip into a named opportunity with an owner and a next step. A map built entirely from internal assumptions describes your org chart, not your users.

How long does journey mapping take?

For a focused product journey, about a day of workshop time plus a few days of preparation. Half a day to pull the evidence, two to three hours in the room, and a couple of hours to write it up and assign the opportunities. Programmes that stretch over weeks usually widen the scope until the map covers everything and decides nothing — narrower scope and faster turnaround produce more shipped changes.

Why do most journey maps fail?

Because they stop at description. A map that documents pain without naming who fixes what and by when has no mechanism to change anything, and after a month it describes a product that has already moved. The other failure modes are scope — mapping every user and every path until nothing is specific enough to act on — and evidence, or the lack of it: a map assembled from internal opinion will confidently mislead a whole team.

How do you act on a journey map inside the product?

Match each dip in the emotion curve to the intervention that fits it. Confusion at a step usually needs a tooltip or clearer wording; an abandoned multi-step task needs a guided walkthrough; a stalled setup needs a checklist that shows progress and what remains; a missed feature needs a hotspot. With a no-code platform like Kompassify you can ship those on top of your live product without a release, target them to the exact segment the map was drawn for, and measure whether the dip flattened. Kompassify is GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.