User Journey Design
Map complete user experiences from awareness through mastery.
When to use this skill
- Mapping how a user experiences a product or service end-to-end over time
- Identifying friction points and emotional lows in an existing experience
- Designing a future-state experience for a new feature or product
- Creating service blueprints that show both user and organizational actions
- Documenting the touchpoints between a user and your product
When NOT to use this skill
- Static navigation structure or sitemaps → use
navigation-design
- Creating user personas or archetypes → use
persona-definition
- Designing research interviews → use
elicitation
- Writing microcopy for specific UI elements → use
ux-writing
- Technical flow diagrams or process flows → use workflow/systems tools
Decision tree
What are you trying to understand?
│
├─ How users experience our EXISTING product over time
│ └─ Current-state journey map: observe → document → identify pain points
│
├─ How users SHOULD experience a NEW or redesigned product
│ └─ Future-state journey map: define ideal → map stages → identify gaps
│
├─ How both the user AND the organization act across touchpoints
│ └─ Service blueprint: map front-stage (user) + back-stage (org) + support processes
│
└─ Where users drop off or struggle in a specific flow
└─ Focused journey fragment: zoom into the problem stage → map in detail
Journey scope?
│
├─ Full product lifecycle (awareness → mastery)
│ └─ 5-7 stages, broad but structured
│
├─ Single flow (e.g., checkout, onboarding, API integration)
│ └─ 3-5 stages, narrow and deep
│
└─ Documentation path (getting started, troubleshooting, API reference)
└─ Use pre-built templates: Getting Started / Troubleshooting / API Integration
Journey Types
| Type |
Focus |
When to use |
| Current state |
As-is experience |
Auditing existing UX, finding friction |
| Future state |
To-be design |
Redesigning or building new experiences |
| Service blueprint |
Org + user view |
Aligning front-stage and back-stage processes |
Core Elements
- Stages: Awareness -> Evaluation -> Onboarding -> Usage -> Mastery
- Touchpoints: Interaction points (where the user meets your product)
- Actions: What users do at each stage
- Thoughts: Questions, assumptions, mental models
- Emotions: Confidence <-> Frustration scale (1-5)
- Pain Points: Friction, confusion, blockers
- Opportunities: Improvements, quick wins, strategic changes
Journey Template
# [Persona] Journey: [Goal]
## Stage 1: [Name]
| Element | Details |
|---------|---------|
| Goal | [what they want at this stage] |
| Actions | [what they do] |
| Touchpoints | [where the interaction happens] |
| Emotion | [1-5 scale: 1=frustrated, 5=confident] |
| Pain Points | [what goes wrong or causes friction] |
| Opportunities | [how to improve the experience] |
Documentation Journeys
Getting Started: Land -> Find quickstart -> Setup -> Run example -> Success
Troubleshooting: Error -> Search -> Find article -> Try fix -> Resolve
API Integration: Discover -> Credentials -> Read ref -> Test -> Production
Anti-Patterns
- Mapping the happy path only — showing only the ideal flow without error states, detours, or alternative paths. Fix: for each stage, ask "what if this goes wrong?" and map the recovery path.
- Journey without a persona — mapping "the user" instead of a specific persona with defined goals, context, and constraints. Fix: always anchor the journey to a named persona from
persona-definition.
- Ignoring emotional state — documenting actions and touchpoints but not how the user feels at each stage. Fix: the emotion score is the most actionable data point; friction always correlates with emotional lows.
- Too many stages — 10+ stages make the map unreadable and unfocused. Fix: group into 4-7 major stages; use sub-stages only when zooming into a specific section.
- Service blueprint without back-stage — showing only the user-facing experience without the internal processes that enable it. Fix: a real service blueprint has three layers: front-stage (user sees), back-stage (org does), support processes (systems that enable).
- Journey map as artifact, not tool — creating the map once and never revisiting it. Fix: treat journey maps as living documents; revisit after feature launches, user research, or quarterly reviews.
- Mixing personas in one map — mapping "users" without differentiating personas causes pain points to average out and hide critical differences. Fix: create separate maps per key persona; a power user's troubleshooting journey differs fundamentally from a beginner's.
1---2name: user-journey-design3description: Map user journeys with touchpoints, emotional states, pain points, and opportunities across the full arc of a user's experience over time. Use when the user asks to map a user journey, create a customer journey map, design a service blueprint, document touchpoints and friction points, or visualize the end-to-end experience of a user across multiple interactions. NOT for static navigation structure or sitemaps (use navigation-design). NOT for creating user personas or archetypes (use persona-definition). NOT for designing research interview flows (use elicitation). NOT for writing microcopy at specific touchpoints (use ux-writing).4---56# User Journey Design78Map complete user experiences from awareness through mastery.910## When to use this skill1112- Mapping how a user experiences a product or service end-to-end over time13- Identifying friction points and emotional lows in an existing experience14- Designing a future-state experience for a new feature or product15- Creating service blueprints that show both user and organizational actions16- Documenting the touchpoints between a user and your product1718## When NOT to use this skill1920- **Static navigation structure or sitemaps** → use `navigation-design`21- **Creating user personas or archetypes** → use `persona-definition`22- **Designing research interviews** → use `elicitation`23- **Writing microcopy for specific UI elements** → use `ux-writing`24- **Technical flow diagrams or process flows** → use workflow/systems tools2526---2728## Decision tree2930```31What are you trying to understand?32 │33 ├─ How users experience our EXISTING product over time34 │ └─ Current-state journey map: observe → document → identify pain points35 │36 ├─ How users SHOULD experience a NEW or redesigned product37 │ └─ Future-state journey map: define ideal → map stages → identify gaps38 │39 ├─ How both the user AND the organization act across touchpoints40 │ └─ Service blueprint: map front-stage (user) + back-stage (org) + support processes41 │42 └─ Where users drop off or struggle in a specific flow43 └─ Focused journey fragment: zoom into the problem stage → map in detail4445Journey scope?46 │47 ├─ Full product lifecycle (awareness → mastery)48 │ └─ 5-7 stages, broad but structured49 │50 ├─ Single flow (e.g., checkout, onboarding, API integration)51 │ └─ 3-5 stages, narrow and deep52 │53 └─ Documentation path (getting started, troubleshooting, API reference)54 └─ Use pre-built templates: Getting Started / Troubleshooting / API Integration55```5657---5859## Journey Types6061| Type | Focus | When to use |62|------|-------|-------------|63| Current state | As-is experience | Auditing existing UX, finding friction |64| Future state | To-be design | Redesigning or building new experiences |65| Service blueprint | Org + user view | Aligning front-stage and back-stage processes |6667## Core Elements68691. **Stages**: Awareness -> Evaluation -> Onboarding -> Usage -> Mastery702. **Touchpoints**: Interaction points (where the user meets your product)713. **Actions**: What users do at each stage724. **Thoughts**: Questions, assumptions, mental models735. **Emotions**: Confidence <-> Frustration scale (1-5)746. **Pain Points**: Friction, confusion, blockers757. **Opportunities**: Improvements, quick wins, strategic changes7677## Journey Template7879```markdown80# [Persona] Journey: [Goal]8182## Stage 1: [Name]83| Element | Details |84|---------|---------|85| Goal | [what they want at this stage] |86| Actions | [what they do] |87| Touchpoints | [where the interaction happens] |88| Emotion | [1-5 scale: 1=frustrated, 5=confident] |89| Pain Points | [what goes wrong or causes friction] |90| Opportunities | [how to improve the experience] |91```9293## Documentation Journeys9495**Getting Started**: Land -> Find quickstart -> Setup -> Run example -> Success96**Troubleshooting**: Error -> Search -> Find article -> Try fix -> Resolve97**API Integration**: Discover -> Credentials -> Read ref -> Test -> Production9899## Anti-Patterns1001011. **Mapping the happy path only** — showing only the ideal flow without error states, detours, or alternative paths. Fix: for each stage, ask "what if this goes wrong?" and map the recovery path.1022. **Journey without a persona** — mapping "the user" instead of a specific persona with defined goals, context, and constraints. Fix: always anchor the journey to a named persona from `persona-definition`.1033. **Ignoring emotional state** — documenting actions and touchpoints but not how the user feels at each stage. Fix: the emotion score is the most actionable data point; friction always correlates with emotional lows.1044. **Too many stages** — 10+ stages make the map unreadable and unfocused. Fix: group into 4-7 major stages; use sub-stages only when zooming into a specific section.1055. **Service blueprint without back-stage** — showing only the user-facing experience without the internal processes that enable it. Fix: a real service blueprint has three layers: front-stage (user sees), back-stage (org does), support processes (systems that enable).1066. **Journey map as artifact, not tool** — creating the map once and never revisiting it. Fix: treat journey maps as living documents; revisit after feature launches, user research, or quarterly reviews.1077. **Mixing personas in one map** — mapping "users" without differentiating personas causes pain points to average out and hide critical differences. Fix: create separate maps per key persona; a power user's troubleshooting journey differs fundamentally from a beginner's.
viktorbezdek