Journey Mapping

journey-mapping

A journey map is a shared picture of how a person experiences a process over time, from their point of view, not the org's. Its job is not to be pretty. Its job is to (1) create a shared truth a team can point at, and (2) surface the specific moments where the experience breaks so you know where to invest. A map that ends without prioritized opportunities is decoration.

Before you map: scope it

A journey map is only meaningful with a fixed viewpoint. Nail these first, or the map will be a vague average of nobody:

• Persona / actor. ONE specific person type, with goals and context. "Users" is not a persona. If you have research personas, use one; if not, name a concrete archetype and its motivation.
• Scenario + goal. The specific journey and what the person is trying to accomplish ("first-time user setting up the product and reaching first value"). One scenario per map. Onboarding and renewal are different maps.
• Scope boundaries. Where does the journey start and end? Widen too far and it's shallow; narrow too far and you miss the handoffs where experiences usually break.
• Grounding. Is this current-state (what happens today, from evidence) or future-state (the experience you intend to design)? Say which. Current-state maps must be built from real signal (interviews, support tickets, session recordings, analytics, a dogfood pass), not assumptions. If you're assuming, label the assumption rows explicitly so they can be validated.

The anatomy (rows of the map)

Lay stages across the top as columns. For each stage, fill these rows:

1. Stage / phase — the chunk of the journey (e.g. Discover → Onboard → First use → Habit → Renew). Name them in the user's language, not the funnel's.
2. Actions — what the person actually does in this stage, concrete steps.
3. Thoughts / questions — what's going through their head; the questions they need answered to continue. Verbatim quotes if you have them.
4. Emotions — the emotional curve across the journey (rising/falling, a plotted line). This is what makes a map more than a flowchart; the low points are where you focus.
5. Touchpoints / channels — where the interaction happens (app screen, email, support, physical, third party).
6. Pain points — friction, confusion, drop-off, unmet need, moments of doubt. Be specific and locate each at a stage.
7. Opportunities — for each pain point, what could fix or improve it. This feeds prioritization.

For a service blueprint (when the backstage matters), add rows below the line of visibility: frontstage staff/system actions, backstage processes, and supporting systems. Use a blueprint instead of a plain journey map when the fix likely lives in operations or systems the user never sees.

The emotional curve is the point

Plot emotion as a line across the stages. The deepest troughs are your priorities — those are the moments a user might quit, churn, or badmouth the product. The peaks are moments to protect and amplify (and candidates for asking for a review or referral). A journey map with a flat emotional row was filled in lazily; real experiences have highs and lows.

Pay special attention to:

• The first low point after commitment (people forgive early friction less once they've already invested).
• Transitions and handoffs between stages, channels, or teams. Experiences break at the seams far more than in the middle of a stage.
• Moments of truth — the few interactions that disproportionately shape the overall impression.

Storyboarding the key moment

Once the map exposes the critical moments, storyboard them. A storyboard is a small sequence of frames (sketches or described panels) showing a specific user moving through a specific moment, step by step, in context. It turns an abstract stage into a concrete scene a team can react to and a designer can build against.

For each key moment, produce a short panel sequence:

Panel 1:  — the setup and trigger
Panel 2: 
Panel 3: 
Panel 4:  — resolution or friction

Keep it to 3-6 panels per moment. Show the pain-point version and, if proposing a fix, the improved version beside it so the delta is visible. Storyboards are most useful for the trough moments the map just exposed — don't storyboard the whole journey, storyboard the moments that decide it.

Deliverable

Prefer a visual artifact over a wall of text. Options, in order of preference:

• An SVG or HTML map: stages as columns, the rows above, and the emotion curve drawn as a line across the top. Hand-author real vector text so it stays legible.
• If a diagramming tool is available (Excalidraw, a design tool, d3), use it.
• A structured table only as a fallback for text-only channels.

Always end with a short prioritized opportunities list: the top pain points ranked by severity × frequency (or reach × impact), each tied to its stage and a proposed direction. That ranked list is the reason the map exists — it tells the team where to spend next.

How to run this skill

1. Scope (persona, scenario+goal, boundaries, current vs future, grounding source). Ask for what you're missing.
2. Gather evidence if current-state: pull from interviews, tickets, analytics, recordings, or run a dogfood pass. Label any assumption rows.
3. Lay out the stages in the user's language.
4. Fill the rows stage by stage: actions, thoughts, emotions, touchpoints, pain points.
5. Draw the emotion curve and mark the troughs, transitions, and moments of truth.
6. Storyboard the two or three decisive moments (pain version, and fix version if proposing one).
7. Rank opportunities and hand off the prioritized list.

Pitfalls

• Inside-out mapping. Writing the map from the company's process instead of the person's experience. If your stages are your internal funnel names, you're mapping your org, not their journey.
• The average user. A map for "everyone" describes no one. Fix the persona.
• No evidence. A confidently-drawn current-state map built entirely from assumption is worse than no map, because it launders guesses into shared "truth." Label assumptions; validate the high-stakes ones.
• Stopping at the picture. The map is the middle of the work, not the end. No prioritized opportunities means no decision came out of it.
• Mapping everything. Too broad a scope yields a shallow map. One persona, one scenario, real depth.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: exiao
• Source: exiao/pm-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.