---
name: journey-mapping
description: Use when mapping experiences across stages or channels.
---

# Journey Mapping

Out of scope: a single in-product screen, route, or control change; use `navigation-controls` or `interaction-patterns` unless the question spans stages, touchpoints, or channels.

Choose an experience map that answers the product question, and make its evidence level visible. A map is a synthesis artifact, not proof of behavior by itself.

## Workflow
1. Define the user or service actor, goal, start/end boundaries, time horizon, and relevant channels or backstage actors.
2. Pick the right artifact: journey map for a broader goal across time and touchpoints; user flow for in-product steps and decisions; service blueprint when frontstage and backstage service delivery matter; empathy map for organizing what is known about a defined user; story map for product activities and delivery planning.
3. Build stages and touchpoints from supplied research, service records, analytics, or direct observation. Label each item as observed, reported, source-supported, inferred, or hypothesized; do not invent quotes, emotions, pain points, or personas.
4. Separate the current experience from a proposed future state. Identify breaks, user needs, responsible handoffs, and opportunity hypotheses without claiming causality from a map alone.
5. Prioritize the most consequential uncertainty and define a follow-up validation step. State the evidence and participant limitations, as well as what remains unverified.

For map selection and evidence boundaries, read `references/journey-artifacts.md`. Hand off in-product navigation paths to `navigation-controls`, research planning to `ux-discovery`, and content taxonomy to `information-architecture`.

**Map output:** name the actor and goal, scope and channels, stages/touchpoints, evidence labels, current vs. proposed state, key opportunity, and next validation step. Mark unsupported stages or fields unknown instead of filling gaps.