How to create a user journey map from existing data

A user journey map turns scattered evidence into a clear picture of how people experience a service over time. It shows stages, actions, questions, emotions, obstacles and opportunities, helping a team see the whole experience rather than isolated interactions.

You do not need to begin with fresh interviews or an empty canvas. Existing usability test notes, support tickets, analytics, personas, use cases, survey responses and accessibility reviews can provide a strong foundation. The important work is separating observed behaviour from assumptions and making the source of each insight visible.

For Australian teams, context matters. A customer moving between a government website, a call centre and a Medicare office may have a very different journey from someone using a single mobile app. Regional internet access, public transport systems such as Opal and Myki, and expectations around plain English all shape the experience that your map needs to represent.

Define the journey scope

Start by choosing one user type, one goal and one situation. “A customer using our website” is too broad; “a first-time renter in Brisbane applying for an online service after work” gives the mapping exercise useful boundaries. Specify where the journey starts and ends, including offline actions or contact with staff.

Decide whether the map describes the current state or a proposed future state. A current-state map should rely on evidence and expose friction. A future-state map can include design ideas, but label them clearly so predictions are not mistaken for research findings.

A collaborative tool such as UCDmanager can help keep related personas, use cases, evaluation notes and testing records connected to the journey. This makes it easier to trace a statement on the map back to the project material that supports it.

Gather and sort existing evidence

Create an evidence inventory before interpreting anything. Useful sources include web analytics, search terms, customer service transcripts, complaints, email records, survey comments, session recordings, usability findings, accessibility audits and product requirements. Include data from face-to-face channels where the service is used in places such as libraries, council offices or retail branches.

Give every item a source, date, audience and confidence level. A comment from one frustrated participant is valuable, but it should not be presented as a general pattern without support. Likewise, a high exit rate in analytics indicates a problem area, not the reason users leave.

Keep an eye on data access and confidentiality. If evidence is stored in restricted files, check that contributors can open and review it through approved channels; guidance on secure document access may be relevant when teams are working with locked PDFs on shared drives. Remove names, account numbers and other personal information before adding excerpts to a shared workspace.

Turn raw material into journey stages

Read across the evidence and identify the broad phases of the experience. Typical stages might include recognising a need, searching for information, comparing options, signing up, completing a task, waiting for an outcome and seeking help. Use language that reflects the customer’s goal rather than internal department names.

For each stage, capture what the person is trying to do, the touchpoints they use and the information they need. A journey involving a state transport service may include checking a fare, topping up a card, finding a station, boarding a train and resolving a failed payment. The map should show handovers between channels, not just the screens controlled by one team.

Avoid creating a stage for every click. The map is most useful when it reveals a meaningful shift in intent or effort. Several related interface actions may belong under one stage such as “prepare an application”, while a long wait for approval may deserve its own stage because it affects trust and future behaviour.

Add emotions, needs and pain points

Use direct evidence to describe the user’s mindset at each point. A short quote, observed hesitation or repeated support request can communicate more than a generic label such as “frustrated”. Record the need behind the emotion: reassurance, clear eligibility rules, progress feedback, a way to save work or confidence that information was submitted successfully.

Separate pain points from their possible causes. For example, “users abandon the form” is an observed pattern, while “the form is too long” is a hypothesis. Mark hypotheses for validation instead of presenting them as facts. This distinction keeps the journey map credible when it is reviewed by product, content, service and engineering teams.

Accessibility should appear throughout the map. Consider keyboard access, screen-reader labels, colour contrast, captions, mobile zoom, cognitive load and the availability of assistance by phone or in person. This is particularly important for services used by people with limited digital confidence or unreliable broadband in rural and remote areas.

Find opportunities and prioritise them

Look for moments where effort, uncertainty or repeated failure is concentrated. Compare the user’s goal with the organisation’s process, then identify where a simpler form, clearer content, better error handling or a smoother handover could reduce friction. Opportunities should describe a direction for improvement rather than a fully prescribed feature.

Prioritise opportunities using evidence strength, user impact, reach and delivery effort. A small wording change affecting thousands of people may be more valuable than a major redesign used by a narrow audience. Include operational changes too, such as better staff scripts, consistent status updates or a clearer escalation route.

Share an early map with people who understand different parts of the service. A contact link to the UCDmanager team can be useful when a project needs clarification about organising collaborative UCD records. Internal review should challenge gaps and contradictions, not turn the map into a collection of departmental opinions.

Validate and maintain the map

Treat the first version as a working model. Test important assumptions with targeted interviews, usability sessions, diary studies, call-centre analysis or a short survey. Compare what people say with what they do, and update confidence levels when new evidence supports or weakens a finding.

Make ownership and review dates visible. Journey maps become stale when a new form, policy, app release or service channel changes the experience. Store the map with its source material, research notes and decision history; a suitable collaborative project hosting option can support access for distributed teams when privacy and organisational requirements have been checked.

A reliable map is therefore less about attractive graphics than traceable evidence. It gives Australian teams a shared view of real behaviour across digital and physical channels, exposes service gaps, and creates a practical basis for research, design decisions and measurable improvements.