User Journey
What is a user journey?
A user journey (or journey map) is a visualisation of a user’s experience over time: the stages they go through, the touchpoints they have, what they do, think, and feel, and where they run into problems or delight. It’s a story from the user’s perspective, not just a flow through your UI.
Use it when: you need to see the full experience (including emotion and context) across channels and time, to find pain points and opportunities, or to align the team on “what it’s like to be the user”.
Copy/paste template
- Stages: 4–7 phases (e.g. Discover, Sign up, First use, Regular use, Renew).
- For each stage: What they do | What they think/feel | Touchpoints | Pain points | Opportunities.
- Persona or segment: One journey per user type so the map is specific.
- Optional: Backstage (what your org does); channels (web, email, support).
Keep it to one page or one view so it’s scannable.
Why user journeys matter
- Show the full experience, not just one flow, so you see context and emotion.
- Surface pain points and moments of truth that a user flow alone might miss.
- Align the team around a shared story of the user’s experience.
- Prioritise improvements by impact on the journey (e.g. “first use” vs “renew”).
What a good user journey includes
Checklist
- [ ] Stages – clear phases from start to end of the journey.
- [ ] User actions – what they do at each stage.
- [ ] Thoughts/feelings – what they think or feel (from research or empathy maps).
- [ ] Touchpoints – where they interact with your product, people, or channels.
- [ ] Pain points and opportunities – so the map drives action.
- [ ] One persona/segment – don’t mix different users in one journey.
Common formats
- Current-state journey: as it is today; use for diagnosis and prioritisation.
- Future-state journey: as we want it to be; use for vision and design.
- Sprint or day-in-the-life: one slice of time (e.g. “first day”) for focus.
Examples
Example (the realistic one)
Persona: First-time buyer. Stages: Research → Sign up → First purchase → Delivery → Post-purchase. Stage “First purchase”: Does: adds to cart, enters payment. Thinks: “Is this safe?” “Will it arrive on time?” Touchpoints: product page, checkout, confirmation email. Pain: “Too many form fields.” Opportunity: “Show trust badges; offer guest checkout.” You use this to prioritise checkout improvements and trust messaging.
Common pitfalls
- No user input: the journey is what the team assumes. → Do this instead: base it on user research or interviews; label assumptions.
- Too many stages: 15 steps and no one reads it. → Do this instead: 4–7 stages; collapse detail into sub-steps if needed.
- Generic user: “the user” instead of a persona or segment. → Do this instead: one journey per key persona so it’s actionable.
- No next steps: the map sits on the wall. → Do this instead: tie pain points to backlog items or experiments; assign owners.
User journey vs. related concepts
- User journey vs user flow: a user flow is the path through the product (screens, steps); a journey includes emotion, context, and all touchpoints. Flow = product path; journey = full experience.
- User journey vs empathy map: an empathy map is a snapshot (says/thinks/feels/does); a journey is over time (stages and sequence).
- User journey vs storyboard: a storyboard is a visual story, often scene-by-scene; a journey map is usually a row or grid of stages. Different layouts, similar “story” idea.
Related terms
- User flow – the product path; journey adds context and emotion.
- Touchpoints – the “where” in each stage of the journey.
- Persona – whose journey you’re mapping.
- Empathy map – input for thoughts and feelings in the journey.
- User research – evidence for actions, thoughts, and pain points.
- Problem statement – pain points in the journey can become problem statements.
- Storyboard – another way to tell the user’s story.
- Service design – journeys are a core service design artefact.
Next step
Pick one persona and one journey (e.g. “first-time sign-up to first value”). Fill the template with what you know; mark assumptions. Use it to pick one pain point to turn into a problem statement or a design sprint.