To create a customer journey map, choose one audience and goal, reconstruct the events around that goal, attach evidence to each stage, and identify the decisions your team needs to make. Start with the experience people have today. Keep a proposed future experience separate so an attractive diagram does not turn an assumption into a finding.
You can organize the stages, notes, and open questions on Mockitt Whiteboard for collaborative journey mapping. Its sticky notes and diagrams provide a shared working surface; the research behind the map still needs to come from your team. This guide uses a fictional shared-equipment booking service to show the method, from checking an item to returning it.
Set a boundary a team can act on
A useful map has a clear beginning, ending, and point of view. “Our customers” is too broad. “A studio member booking a camera for a weekend project” gives the team a person, a reason, and a task. Begin when the member realizes they need equipment; end when the returned camera is accepted. That captures questions the booking screen alone cannot answer.
Write a scope sentence above the map: “This current-state map follows an occasional studio member booking, collecting, using, and returning shared equipment.” Add the research period and the responsible team. Someone opening the board later should know whose experience it represents and whether it is still relevant.
Nielsen Norman Group's journey-mapping introduction describes a journey around a person pursuing a goal, including actions, thoughts, feelings, and opportunities. The practical point is to keep the person's experience visible across events. A list of screens or internal departments would answer a different question.
Choose the map's resolution deliberately. A monthly membership lifecycle may need several maps. A single booking may fit on one. If one group collects equipment in person and another receives delivery, check whether those paths remain understandable together. Split them when combining the paths hides important steps or constraints.
Prepare evidence before arranging the story
Collect the material that can explain the scoped experience: interview notes, observations, support records you are permitted to use, and relevant service artifacts. Do not treat a stakeholder's preferred process as proof of what members do. A documented policy, an observed action, and a person's recalled experience can all be useful, but they are different kinds of evidence.
Use one short event or observation per note. Include a source reference, channel, context, and date. For example, a note might say that a member opened an equipment description and then contacted the studio about a missing accessory. The conclusion “members need a better product page” belongs in a separate interpretation note until the cause is understood.
Keep personal details out of the shared view when they are not needed. Use participant or case codes and link to the approved research location. Keep the source reference stable when a note moves between stages. The research-synthesis workflow explains how to preserve that connection while developing a finding.
For a new service with no observed journey, create a clearly labeled assumption map. It is useful for deciding what to investigate, but it should not contain invented customer quotations or an emotion curve presented as research. Mark an unanswered question plainly instead of completing every row for visual symmetry.
Find stages in the events, not the organization chart
Lay the source events out in time order before naming stages. Look for a change in the member's goal, responsibility, or information need. In the equipment example, checking suitability is different from reserving an available date, even if both happen on the same website. Collection moves the experience into a physical location with a new set of questions.
Use labels that another person can explain without the workshop facilitator. “Evaluate equipment” is clearer than “Engage,” and “Return and confirm” is clearer than “Retention.” Marketing stages may be appropriate for an acquisition study, but they should not replace the actual events in a service-use task.
GOV.UK's experience-mapping guidance recommends comparing individual event sequences before consolidating them. That helps expose meaningful differences rather than smoothing every account into one ideal path. Preserve a detour when it changes what the service must explain or support.
A member may revise the dates, discover that an accessory is unavailable, or return an item outside staffed hours. These are useful branches if they occur in the evidence or belong to the scope you need to investigate. They do not all need full detail on the main map; connect a separate branch when the core sequence becomes difficult to read.
A customer journey map example: shared-equipment booking
The grid below is a teaching example, not a summary of actual customer research. It shows how to connect a stage to a question worth investigating. Replace the illustrative entries with your own evidence before using the map to justify a product decision.
| Stage | Member's task | Question to investigate | Possible design response |
|---|---|---|---|
| Check suitability | Choose a camera and required accessories. | Can the member tell what is included? | Show the included kit and optional accessories together. |
| Reserve dates | Request equipment for the project period. | Does “requested” look like a confirmed reservation? | Separate requested and confirmed states. |
| Collect | Arrive with the information needed for pickup. | Are collection instructions available at the right moment? | Show location, opening hours, and required identification in the confirmation. |
| Use | Find help if an accessory or function is unclear. | Does support information match the booked item? | Connect the booking to relevant instructions and support. |
| Return and confirm | Return the kit and know the booking is closed. | Can the member distinguish “returned” from “checked and accepted”? | Explain the remaining check and next status. |
Notice that a question is not yet a pain point, and a possible response is not yet a requirement. Add a separate evidence row in the working board. A blank cell can then mean “not researched,” while a supported finding has a traceable reference. That distinction is more useful than giving every stage a decorative red or green face.
Build a readable working map
On the shared canvas, arrange the five stages as columns. Use rows for actions and touchpoints, supporting evidence, questions, and opportunities. Keep each note to one idea. Place the map's scope and evidence legend beside the grid so teammates do not need a separate explanation to begin reviewing it.
For the equipment-booking example, the “Reserve dates” column separates a member action, “Submit date request,” from an unresolved question, “What tells the member the booking is confirmed?” Put “Compare requested and confirmed messages” in the opportunity row. The visual relationship makes the next design discussion clear without pretending the answer has already been established.
Use comments to ask about a note's meaning or source, rather than rewriting someone else's observation into a more convenient story. When the team agrees on a change, update the interpretation or action record explicitly. Keep the underlying evidence available so a later reviewer can understand why the wording changed.
Make the board readable at the scale people will actually use. Long transcripts belong in the research repository; the map needs concise statements and source references. If color distinguishes evidence from questions, repeat the distinction with labels. A reader should not need to perceive a specific hue to tell a finding from an assumption.
Use gaps and disagreements to choose the next question
Walk through the map with people who understand different parts of the service. Ask where the evidence is strong, where accounts differ, and which event is missing. A support colleague may recognize repeated questions at collection, while a designer may notice that the online confirmation never mentions the pickup location.
Do not settle a factual conflict by voting. If one source says a booking is immediate and another describes a staff review, investigate the conditions. There may be different equipment types, membership permissions, or outdated instructions. The map should expose that distinction, not average the two accounts into a vague “booking complete” stage.
Emotions need similar care. A pause can have several explanations; do not automatically label it frustration. Use an attributed account or a supported interpretation, and retain the context. When you do not know how the person experienced an event, record the question instead of drawing a smooth emotional curve.
Turn one opportunity into a testable change
Choose an opportunity by its consequence for the task and the strength of the evidence. For the example, an unclear reservation state could lead someone to plan a project around equipment that is not confirmed. That gives the team a concrete review question: can members explain whether they have a reservation and what happens next?
Create a small decision record with the relevant stage, source references, proposed change, owner, and next evidence. A useful proposal is “compare requested and confirmed booking messages,” rather than “redesign the whole journey.” Keep questions about staff review rules with the person who can answer them.
A prototype usability-testing plan can turn the proposal into a focused task. Show the proposed states, ask the participant what they believe has happened, and observe the next action. The map identifies the uncertainty; the later session supplies new evidence about the proposed response.
Keep the map connected to the service
Record the map's owner and the events that should trigger a review, such as a changed booking rule, a new collection channel, or evidence that contradicts a finding. Keep the current-state map and future proposals visually separate. An old map can still explain a past decision, but it should not quietly remain the current description after the service changes.
The finished artifact should help a colleague answer three practical questions: what is the member trying to do, what do we know about the difficult moments, and what will we investigate or change next? If the map cannot answer those questions, improve the scope and evidence before adding more decoration.