How to Map User Journeys

A user journey map shows the experience of a specific person trying to accomplish a specific goal over time. Done right, it makes abstract user problems visible and concrete enough to act on. Done wrong, it's a pretty diagram that everyone agrees with and no one acts on.

What a journey map is (and isn't)

A journey map is not a user flow. A user flow shows how a user navigates through your interface — click this, then that. A journey map shows the human experience around your product — what the user is thinking, feeling, and doing across the whole context of their goal.

A journey map is not a feature list. It doesn't capture what features you want to build. It captures where the experience breaks down, which informs what to build.

A journey map should cover a specific persona trying to accomplish a specific goal. "All users using our product" is too broad. "Alex, Operations Manager, onboarding a new team member to the tool" is the right scope.

The components

Stages: The high-level phases of the journey. For a SaaS product, stages might be: Discover → Evaluate → Sign Up → Onboard → Use → Renew. Keep stages at 4–7; more than that and the map becomes unreadable.

Actions: What the user is doing in each stage. Concrete, behavioral: "Googles alternatives," "reads review on G2," "watches product video," "invites team members." These are observable actions, not UI interactions.

Touchpoints: Where the user interacts with your product or brand. Website, onboarding email, in-app tutorial, support chat, renewal reminder. Each touchpoint is an opportunity to improve or break the experience.

Emotions: How the user feels at each stage. Use a simple scale — positive, neutral, frustrated — or an emotional arc across the journey. The emotion line is often the most striking part of the map: it shows visually where the experience drops.

Opportunities: What could be improved at each stage? These are design and product questions, not solutions. "How might we reduce friction during sign-up?" not "Add a social login button."

Optional layers: thoughts (what the user is thinking), backstage actions (what your team does that the user doesn't see), and pain points (explicitly named problems).

Research first, assumptions second

A journey map built entirely on assumptions is an opinion document. It's useful for getting stakeholders to debate the experience, but dangerous to act on directly.

Ideally, you have interview data, support data, and analytics before you build the map:

Interviews: 8–12 users walking you through how they accomplished the goal. "Tell me about the last time you had to onboard a new team member. Walk me through what happened from the start."

Support tickets: What do users ask for help with? Where are they stuck? Support data shows you where the emotional low points are.

Analytics: Drop-off data, time in each stage, feature adoption rates. This tells you where behavior diverges from the intended flow.

Without research, run an assumption mapping session first. Build the map as a team, then explicitly label every assumption. Mark which ones are high confidence (validated by data) and which are low confidence (guesses). This shows you what to research.

Try Miro Free

Journey maps vs service blueprints

These two artifacts are related but answer different questions.

A journey map focuses on the user's experience — their perspective, emotions, and actions.

A service blueprint goes deeper. It maps everything that happens to deliver that experience — including backstage processes, staff actions, and supporting systems. It shows both what the user experiences and what the organization does to deliver it.

Use a journey map when your goal is to understand and improve the user experience. Use a service blueprint when you need to understand operational complexity or design a new service from scratch.

Most design teams need journey maps more often than service blueprints.

Running a journey mapping workshop

Building a journey map collaboratively is often more valuable than the artifact itself. The process surfaces disagreements, aligns on what the experience actually is, and builds shared ownership.

A 2-hour workshop structure:

1. Setup (15 min): Share the persona and goal. Make sure everyone has the same context.
2. Individual sticky notes (20 min): Each participant silently adds actions, touchpoints, and emotions for each stage. Use different colors for each category.
3. Cluster and discuss (40 min): Group similar notes, debate differences. Where people disagree on the emotion, that's a signal — your team has different mental models of the experience.
4. Identify low points (20 min): Mark the stages with the lowest emotion score. These are the priority areas.
5. Generate opportunities (25 min): For each low point, generate "How Might We" questions.

Run this in Miro or FigJam. Both have journey map templates. Miro's template library is broader; FigJam integrates directly with Figma for teams already in that ecosystem.

Sharing and acting on the map

A journey map that lives in a file no one opens changes nothing.

Figma is good for the polished, shareable version — a designed artifact that looks credible enough to present to leadership and embed in proposals.

Notion is good for the living document — linking the map to relevant research, tagging product areas, and making it findable when teams are planning.

After the map is built: prioritize the opportunities, connect them to your product roadmap, and assign ownership. The map should generate a list of specific problems to solve, not a general sense that the experience could be better.

Review and update the map when significant product changes launch or when new research contradicts existing assumptions. A journey map from three years ago is archaeology, not strategy.