A customer journey map follows one customer persona through every stage of getting something done, here switching home broadband, and shows what they want, where they meet the company, how they feel and where it hurts. It is not UML: UML covers software structure and behaviour; journey maps, BPMN and swimlanes are the other standard notations used alongside it, and this one is drawn from the customer's side.
1. The Diagram
Read the yellow stages left to right. They are named as the customer would describe them, not after internal departments.
The Goal row states what the customer wants at each stage; every other row is judged against it.
Touchpoints list every channel where the customer meets the company: ads, website, SMS, technician, app.
Actions describe what the customer actually does, often based on interviews or session recordings.
The emotion curve is the heart of the map. It dips at Compare (hidden fees) and hits bottom at Install (late technician).
Pain points explain each dip; opportunities turn them into concrete improvements the team can prioritise.
2. How to Read It
There is no formal standard for journey maps, so conventions vary by team. Keep the rows fixed, keep one persona per map, and base the emotion curve on research data (interviews, surveys, support tickets) rather than guesses.
3. Variant: Service Blueprint
A service blueprint zooms into one stage and adds what the customer does not see. The line of visibility separates frontstage staff from backstage work; support systems sit at the bottom. It connects the journey map to the internal processes you would then model in BPMN.
4. Pros, Cons, and When to Use
Pros
Builds empathy: the whole team sees the experience from the outside.
Puts pain points from many departments on one page.
Turns research into a prioritised list of opportunities.
Easy for non-technical stakeholders to read and discuss.
Links naturally to service blueprints and BPMN for the fix.
Cons
No standard notation; maps from different teams look different.
Emotion data is often invented if research is skipped.
One persona per map; many segments mean many maps.
Says nothing about internal systems or data on its own.
Goes stale quickly as products and channels change.
When to use
Designing or redesigning a customer-facing service.
Aligning marketing, sales, operations and support on one experience.
Choosing which problems to fix first.
When not to use
Documenting internal workflows (use BPMN or a swimlane flowchart).
Specifying system behaviour for developers.
5. As Diagrams-as-Code
Mermaid has a native journey diagram: each task gets a satisfaction score from 1 to 5 and the actors involved.
journey
title Switching home broadband
section Discover
Run speed test: 3: Customer
Read reviews: 4: Customer
section Compare
Check availability: 3: Customer
Find hidden fees: 1: Customer
section Sign up
Choose plan and slot: 4: Customer, Web shop
section Install
Wait for technician: 1: Customer, Technician
Set up Wi-Fi: 3: Customer
section Use and support
Pay first bill: 4: Customer
Report outage: 2: Customer, Support
6. Related
Diagramming — overview of diagram types on this site
BPMN — for the internal processes behind each stage