A customer journey map shows every stage of the customer experience — what they do, feel, and think at each touchpoint. Snap it with BoardSnap and the insight becomes an action plan.
Run a customer journey map when redesigning an existing experience, diagnosing a retention or conversion problem, onboarding new team members to the product, or aligning cross-functional teams on what customers actually go through.
The map is most powerful when it captures the real journey — not the ideal one. That means it should be built from customer research (interviews, support tickets, session recordings), not from the internal assumption of what customers do.
The phases the customer moves through: Awareness, Consideration, Decision, Onboarding, Adoption, Retention, Advocacy. These are the column headers that run across the top of the map. Adjust them to fit your specific product — a B2B journey has different stages than a consumer journey.
What the customer actually does at each stage. Concrete behaviors: 'Googles comparison terms,' 'signs up for a free trial,' 'invites a teammate,' 'exports a report.' These should come from observation or research — not assumptions.
Where and how the customer interacts with your product or brand at each stage: your website, App Store listing, onboarding email, in-app tutorial, support chat. Each touchpoint is an opportunity to improve the experience.
Draw a line across the bottom of the map showing the customer's emotional state at each stage — high means positive, low means frustrated or confused. This curve makes the worst moments visible at a glance. The dips are where you focus design energy.
The specific frustrations, confusions, and failures the customer encounters at each stage. These should be grounded in real evidence — quotes from interviews, spikes in support tickets, drop-offs in analytics. Each pain point is a design problem waiting to be solved.
Ideas for improving the experience at each stage. Write these after filling the pain points — they should be specific responses to real problems, not generic feature ideas. One opportunity per sticky; link it to the pain point it addresses.
Name the persona (e.g., 'Sarah, a product manager at a 50-person SaaS company') and the specific scenario you're mapping ('her first sprint retro using a new whiteboard tool'). Without a specific persona and scenario, the map becomes too generic to act on.
Write the journey stages across the top as column headers. Leave generous space under each — you'll fill multiple rows.
Row by row, write what the customer does and where they interact with the product at each stage. Pull from real data: interview transcripts, analytics, support tickets.
After filling the actions row, draw a curve across the bottom showing how the customer feels at each stage. This is often the most revealing step — the emotion curve makes the experience visible as a system, not as individual moments.
Below each stage, post pain point stickies in red and opportunity stickies in green. This is where the map becomes a product brief.
Snap the map with BoardSnap. The AI reads the full structure — stages, emotions, pain points, opportunities — and outputs a prioritized list of the most impactful improvement areas.
A customer journey map built in a digital tool stays in the tool — usually owned by one UX designer, opened by nobody else. A journey map on a physical whiteboard becomes a shared team artifact. Engineers walk past it. Sales asks questions about the onboarding dip. The physical surface makes the customer's experience part of everyone's daily context.
BoardSnap preserves the map. Journey maps take hours to build and contain dozens of research insights. Snap the board when the session ends and BoardSnap reads the full structure — stages, actions, emotions, pain points, opportunities — outputting a summary that travels to every team member who needs to act on it.
A customer journey map focuses on the customer's experience — what they do, feel, and think. A service blueprint also shows the behind-the-scenes processes that support that experience: front-stage staff actions, back-stage processes, and supporting systems. A journey map is customer-facing; a blueprint shows the full operational picture. Build the journey map first, then add the blueprint layer to understand how to operationally support each touchpoint.
Ideally yes — interviews, support tickets, session recordings, and analytics should inform the map. A hypothesis map built from assumptions is still useful for alignment, but label it clearly as a hypothesis and commit to validating it with real customers within two weeks. A map built on assumptions alone will optimize for your internal mental model, not the customer's actual experience.
Five to seven is the practical range. Too few and you lose resolution on where the problems are. Too many and the map becomes unwieldy to facilitate. If your journey genuinely has twelve distinct phases, split it into two maps: pre-purchase and post-purchase.
Yes, if the journeys are meaningfully different. A B2B product might have separate maps for the economic buyer, the end user, and the IT admin — they have completely different experiences. Overlaying them on one map produces confusion rather than clarity.
No exporting, no transcription. Snap the board, get the action plan.