`user-journey-map`

Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first. Use when the user wants a journey map, customer experience map, "map the user's path through onboarding", touchpoint analysis, or "where do users feel friction".

Pack product-managerTier standardJob Decide what to buildv0.1.2

npx skilldrop-cli install user-journey-map

Other ways to install

With the sibling skills it hands off to:

npx skilldrop-cli install user-journey-map --with-related

The whole pack it belongs to:

npx skilldrop-cli install --pack product-manager

By hand, from a clone of the repo:

cp -R packs/product-manager/skills/user-journey-map ~/.claude/skills/

In Claude Code, with the product-manager plugin installed, invoke it as:

/product-manager:user-journey-map

Try it

A realistic prompt from the skill's acceptance evals:

Map the customer journey for freelance designers trying our invoicing app. We believe they drop off between signup and sending their first invoice. No research data yet — this is the team's hypothesis.

What a good result looks like

One persona, one outcome, both named in the title. A map for "users" is a map of nothing.
The evidence level is declared at the top and every pain that deviates from it is tagged individually.
Stage edges live in the persona's life, not on the product's surface — the trigger precedes the product; the end state is the persona's outcome.
Every emotion score carries its reason. A bare number row is decoration.
Opportunities are outcomes, not features. The moment "add a button" appears, the map has started doing design's job without design's process.
The dips, the peak, and the ending are explicitly marked, and exactly 1–2 opportunities are named as the targets. Ranking is the deliverable.
The Mermaid renders. Scores 1–5, one section per stage — check syntax before emitting.

Example output

Worked example: trial-to-activation journey for a B2B monitoring SaaS · the skill's own worked example, source

Worked example

Input given to the skill:

Map the journey for engineering managers trialing our infrastructure-monitoring product. We think most trials stall before the first dashboard shows real data. No user research yet — this is what the growth team believes is happening. Trial starts when an alerting incident burns the team; success is the manager seeing their own production data on a dashboard and sharing it with the team.

Output:

Journey map: Engineering manager "Priya" → own production data on a shared dashboard

Evidence level: [assumption-based] — growth-team hypothesis, no primary research yet. This map directs research; treat pains as hypotheses to verify, not findings. Start trigger: a production incident goes unnoticed for 40 minutes and the postmortem lands on Priya's desk · End state: Priya shares a dashboard of her own production data with her team

Stages

	Feel the burn	Evaluate options	Start the trial	Connect real data	First shared win
Actions	Reads the postmortem; asks "why didn't we see this?"; searches "kubernetes monitoring alerts"	Skims 3 vendor sites; asks peers in a Slack community; shortlists 2	Signs up with work email; lands on an empty dashboard	Installs the agent on a staging cluster; hunts for the right Helm values; waits for data	Sees staging metrics; wants prod but needs security sign-off; shares a screenshot in team channel
Emotion (1–5 + why)	2 — on the hook for an outage nobody saw	3 — options exist, but every site says the same words	4 — signup was fast, feels like progress	2 — empty dashboard + config hunt; unclear if it's working or broken	3 — win is real but staging-only; prod approval looms
Pains	Postmortem pressure with no tooling answer	Undifferentiated marketing; can't tell depth from demos	Empty dashboard with no next step	No feedback during agent setup — silence until data arrives; Helm docs assume expertise	Security review blocks prod; sharing is screenshot-only
Opportunities	Meet the searcher with the incident story, not a feature tour	Let Priya see the product on realistic data before signup	First session ends with data visible, even if sample	Setup progress is visible minute-by-minute; failure states name their fix	The shared artifact is live, not a screenshot; security answers are self-serve

Emotion arc

journey
    title Priya → own production data on a shared dashboard
    section Feel the burn
      Read the postmortem: 2: Priya
      Search for tooling: 3: Priya
    section Evaluate options
      Compare vendors: 3: Priya
    section Start the trial
      Sign up: 4: Priya
      Land on empty dashboard: 2: Priya
    section Connect real data
      Install agent, wait in silence: 2: Priya
    section First shared win
      See staging data: 4: Priya
      Hit prod sign-off wall: 3: Priya

Peaks and ending

Steepest dips: signup-high (4) → empty dashboard (2) — the sharpest single drop in the journey; agent install silence (2) — longest time spent at the bottom
Highest peak: staging data appears (4)
Ending emotion: 3 — a real win immediately blunted by the prod-approval wall; the journey ends on friction, which the peak-end rule says colors the whole trial

Opportunities, ranked

#	Opportunity (outcome-shaped)	Dip severity	Reach	Evidence	Target?
1	The first session ends with data on the dashboard, even sample data	4→2, sharpest drop	every trial	`[assumption-based]`	✅ named target
2	Setup progress is visible minute-by-minute; silence never means "unknown"	2, longest dwell	every self-serve install	`[assumption-based]`	✅ named target
3	Security answers are self-serve so prod approval starts during trial	ending friction	enterprise segment	`[assumption-based]`	deprioritized — smaller reach; revisit after research
4	Evaluation shows the product on realistic data pre-signup	3, mild	top of funnel	`[assumption-based]`	deprioritized — funnel, not activation

Hand-off

Target #1 → verify with session recordings first ([assumption-based] — 5 recordings would confirm the drop), then prd-draft for the empty-state experience
Target #2 → user-story-splitter (install-feedback states are already story-shaped)
Fix measurement → success-metrics: candidate first-success event is "real data visible in first session"
Backstage causes implicated: agent packaging (Helm defaults), security-review process → platform team, security team

Why this output passes the quality bar: one persona, one outcome, both in the title; evidence level declared and repeated where it matters (the map admits it's a hypothesis and names the research that would confirm it); stage edges live in Priya's life (the postmortem, not the landing page); every emotion score has a reason; opportunities are outcomes ("first session ends with data"), not features ("add sample data mode"); dips, peak, and ending are marked; exactly two targets are named and the rest explicitly deprioritized.

How it's checked

Measured against plain Claude Code (2026-10-23): it met 80% of its checks, against 58% without it, and a blind judge preferred the agent without it. How skills are checked

25 assertions across 4 acceptance evals, and 9 trigger queries. Every skill's checks

What the output must do

One specific persona and one outcome are named in the map's title
Evidence level is declared as assumption-based at the top and framed as a hypothesis that directs research
The start trigger is an event in the persona's life (e.g. a client asks for an invoice), not 'visits the landing page'
3-6 stages, each a phase of the persona's goal — not one stage per screen
Every stage has all four rows: actions (persona's words, frontstage only), emotion score 1-5 with a reason, pains, opportunities
Opportunities are outcome-shaped, not feature suggestions like 'add a button'
The steepest dips, the highest peak, and the ending emotion are explicitly marked
A Mermaid journey diagram is emitted with valid syntax: one section per stage, actions scored 1-5
Opportunities are ranked and exactly 1-2 are named as targets; the rest are explicitly deprioritized with reasons
Hand-offs route committed work to prd-draft/user-story-splitter and measurement to success-metrics
No journey is drafted — with no persona or outcome derivable, the output is BLOCKED: need persona + outcome
The BLOCKED output names both missing anchors and what to rerun with
No invented persona, stages, or Mermaid diagram appear
Identifies landlord confirmation (3,100 to 1,500) as the largest drop in the funnel, rather than adopting the programme manager's view that document upload is the main problem
Does not propose removing the landlord-confirmation step, which the funding rules require; improvements work within it
Reports the overall success rate correctly as about 1 in 4 (1,180 of 4,800), catching the manager's '1 in 3'
Flags that all six interviews were in English while about 40% of applications were started in Spanish, so the experience of Spanish-language applicants is not evidenced
Pains and emotions trace to the interview notes or funnel data; does not invent quotes, statistics, or research not in the notes
Stays within about two pages
Delivers the map without asking questions first
Covers the whole span from first inquiry to the couple receiving their photos
Fits on one page
Ends with a clear pointer to the few places to fix first, specific to a solo wedding photographer (for example slow replies to inquiries, contract and deposit, or the long wait for photos)
Does not present invented client quotes, survey results, or statistics as real findings; pains the user did not mention are framed as likely or as things to check
Plain language for a solo business owner, without UX jargon

When it should and shouldn't activate

Should activate:

Map the customer journey through our onboarding flow
Where do users feel the most friction in the purchase experience?
Create a journey map for a new user's first week
Turn this pile of user feedback into a customer experience map
Map the touchpoints from trial signup to activation

Should leave to another skill:

Design the screen-by-screen flow for the checkout wizard
Diagram how the order service talks to the payment service
Map our internal ticket-escalation process
Write the PRD for the onboarding redesign

Hands off to

prd-draft — when a friction point on the journey is worth fixing. Turn the named friction into numbered requirements.
success-metrics — when the fix needs a measure before it is built. Design the measurement for the journey step being changed.

Source

SKILL.md · the whole folder on GitHub.

user-journey-map