How to Create a User Journey Map (Step by Step)

TL;DR: What You Will Learn

• What a user journey map is and how it differs from a marketing customer journey
• The building blocks every map needs, from personas to touchpoints and emotions
• A step-by-step process to research, draft, and refine your map
• Common mistakes that make maps pretty but useless
• How to turn insights from the map into real product decisions

What a User Journey Map Really Is

Let me start with a definition you can actually use. A user journey map is a visual representation of the steps a person takes to reach a goal, capturing not just what they do but what they think and feel across time.

Nielsen Norman Group’s Sarah Gibbons, whose 2018 “Journey Mapping 101” is still the piece most UX teams cite as the field’s reference point, puts it just as simply: a journey map visualises the process someone goes through to reach a goal, built so a team can understand and act on that person’s needs and pain points along the way.

The key word there is time. A journey map lays out a real sequence, from the moment someone realises they have a task to the moment they either finish it or give up in frustration.

Picture a Singapore resident trying to book a specialist appointment through HealthHub. They log in with SingPass, hunt for the right clinic, get confused by an unfamiliar slot picker, and finally confirm while worrying they picked the wrong date. That whole arc, with the anxiety baked in, is what a journey map records.

The Core Anatomy of a Map

Every solid map I have built shares the same skeleton, and once you know it, you can read any map in seconds.

• Persona: The specific user, for example, a busy working parent booking on their phone.
• Scenario: The goal they are chasing, like securing a paediatric slot before the school week.
• Stages: The broad phases, from awareness to sign-in to selection to confirmation.
• Touchpoints: The screens, notifications, and SingPass redirects they pass through.
• Emotions: The highs and lows plotted as a curve across the stages.
• Opportunities: The fixes and ideas each pain point unlocks.

That emotion curve is what separates a journey map from a dry process chart. It tells you where people quietly hate your product.

When to use One Versus a Flow Diagram

A flow diagram answers “what are the possible paths through this system?” A journey map answers “what does one real person actually experience along one path, and how does it feel?”

If you are documenting logic for developers, draw a flow. If you are trying to convince a stakeholder why the HealthHub booking drop-off happens, map the journey.

How it Differs From Marketing and Service Blueprints

Do not confuse this with a marketing customer journey, which tracks funnel stages like awareness and purchase across ads and campaigns. A user journey map lives much closer to the product interaction itself.

It also differs from a service blueprint, which extends below the surface to show backstage staff, systems, and handoffs that the user never sees. A journey map stays with the user’s lived experience.

Nielsen Norman Group frames the family tree well: if an experience map is the parent of a journey map, a service blueprint is the grandchild in the same lineage, but where a journey map stays fixed on the user’s point of view, a service blueprint pivots to the business’s, mapping what your organisation does behind the scenes to produce that experience. The technique itself goes back further than most people assume: banking executive Lynn Shostack introduced it in a 1984 Harvard Business Review article, long before “service design” was a job title.

This work sits within UX rather than visual design, and if that line is fuzzy, our explainer on the difference between UI and UX is worth a read.

Above all, treat your map as a decision tool, not wall decoration. If it does not change what your team builds next, it has failed.

Choosing the Persona and Scenario to Map

Here is the mistake I see most often: teams try to map every possible user doing every possible thing on one giant board. The result is a mess that helps nobody.

A useful user journey map does the opposite. It follows one focused persona through one specific scenario, so you can actually see where things break down.

Building a Lightweight, Evidence-based Persona

You do not need a glossy persona document with a stock photo and a fictional backstory. Those look nice in slides and mislead everyone who reads them.

What you need is a persona grounded in real user data: support tickets, app store reviews, session recordings, or a handful of interviews you did last week.

This isn’t just a stylistic preference. Alan Cooper, who introduced personas in his 1999 book The Inmates Are Running the Asylum, built the method specifically to kill off what he later called the “elastic user,” a stand-in for the user that quietly changes shape to suit whichever stakeholder is arguing for a feature that day. A persona only does its job once it’s specific and evidenced enough that nobody can stretch it that way.

Imagine a local F&B SME in Singapore launching its own food delivery app to stop paying platform commissions. A grounded persona might be “a first-time user in her thirties, ordering dinner on the MRT home, who has never used this brand’s app before and has three other delivery apps installed already.”

Notice how specific that is. Every detail there could be checked against real usage, not guessed over coffee.

The moment you catch yourself inventing traits because they feel plausible, stop. A persona built on guesswork will lead you to design for a customer who does not exist.

Defining The Scenario and The User's Goal

Once you have your persona, pin down one scenario and the single goal that drives it. For our F&B app, the scenario is onboarding: signing up, browsing the menu, and completing a first order.

The user’s goal is not “engage with the brand.” It is blunt and human: get food, fast, without giving up more information than she wants to.

Pick a scenario that is worth the effort. I look for one of two things: high value (the flow that drives revenue or retention) or high friction (the flow where users clearly struggle and drop off).

A bank customer applying for a credit card through a mobile app is a strong example of both at once. It is high value for the bank and notoriously high friction, since identity checks and document uploads make people abandon it halfway.

Setting Scope so The Map Stays Useful

Scope is where good intentions go to die. Decide clearly where the journey starts and where it ends before you map a single step.

For the card application, you might scope it from “taps Apply Now” to “receives approval confirmation,” and deliberately exclude what happens after the card arrives.

Keep the scope tight enough to finish, but wide enough to include the moments just before and after the core task, because that is often where the real problems hide.

When the persona, scenario, and scope all fit on one line, you are ready to map. If they do not, you are trying to map too much.

Mapping the Stages and Touchpoints

Once you have your persona sorted, the next job is to give your user journey map a spine. That spine is a sequence of stages, and within each stage sit the touchpoints where your user actually interacts with you.

Identifying Stages From The User's Perspective

Start by naming the broad phases your user moves through. A common set is Awareness, Consideration, Onboarding, Usage, and Support, but do not force those labels onto every project.

Name the stages the way your user would describe them, not the way your teams are organised. Someone booking a ride is not thinking about your “acquisition funnel”; they are thinking “I need to get to Bugis before my meeting”.

Here is a quick test I use. If a stage name reads like an internal department, rewrite it. “Payment reconciliation” is your problem. “Paying and getting my receipt” is theirs.

Listing Touchpoints Across Channels

With stages in place, plot the concrete touchpoints inside each one. A touchpoint is any moment of contact: an app screen, a marketing email, a poster at an MRT station, a call centre queue, or a staff member at a pickup counter.

Take a local retailer selling across Shopee, its own website, and physical stores. A single “buy and collect” journey might touch all three channels in one afternoon.

• Awareness: A TikTok video or a Shopee flash sale banner
• Consideration: Product pages on the retailer’s own website
• Purchase: Checkout inside the Shopee app
• Onboarding: An order confirmation email with a collection QR code
• Usage: In-store pickup at Jurong, staff scanning the code
• Support: A WhatsApp or call centre follow-up on a wrong size

That variety is exactly why channels matter, and it is also why teams often want to grow reach across channels like TikTok without checking whether the rest of the journey can keep up.

The point is that touchpoints belong to the user’s reality, not your org chart. When you map them honestly, your internal silos become impossible to ignore.

Spotting Hand-off Gaps Between Channels

The most painful moments almost always live in the gaps between channels, where one team hands the user to another and something falls through.

Picture a Shopee shopper arriving in store, only for staff to have no visibility of the app order because the systems do not talk. The user has done everything right, yet the experience breaks at the hand-off.

I look for three common seams: online to offline (app order to physical pickup), self-service to human (chatbot to live agent), and marketing to product (the TikTok promise versus what the checkout actually delivers).

Mark each hand-off on your map with a clear flag. Every unmanaged transition between channels is a moment where trust can quietly leak away, and naming it is the first step to fixing it.

Capturing Emotions and Pain Points

This is where a user journey map stops being a tidy flowchart and starts telling the truth about your product.

Up to this point, you have documented what users do. Now you record how they feel while doing it, step by step, so the highs and lows become impossible to ignore.

Building the Emotion Curve

For each stage in your map, plot a single point on a scale from frustrated to delighted, then connect the points into a line. That line is your emotion curve.

The shape matters more than any individual dot. A curve that climbs steadily then plunges at checkout tells you exactly where to look first.

Ground every point in something you actually saw or heard, not what you assume the user should feel. If a shopper on a local retail site sighed and reread the price three times, that is your data, not your guess.

Pull real quotes straight from your research notes. “Wait, is this seven dollars or seven with GST added later?” is far more honest than writing “user feels confused” in your own words.

Categorising Pain Points

Every dip in the curve is a pain point, but not all pain points have the same cause. Labelling them helps you decide who fixes them and how.

I usually sort them into four buckets:

• Usability: The interface itself gets in the way, like a signup form that rejects a valid Singapore mobile number format.
• Trust: Something makes the user hesitate, such as a GST-inclusive price that only reveals the full amount at the final checkout screen.
• Effort: Too many steps, like a PDPA consent flow that forces users to tick five separate boxes before they can even browse.
• Timing: The right thing appears at the wrong moment, such as asking for marketing consent before the user understands the value.

Take that PDPA consent friction example. A dip at signup labelled trust and effort tells you the problem is not the copy; it is the demand for permission before you have earned it.

Turning Dips into Opportunities

A pain point sitting on a chart changes nothing. You need to reframe each dip as an opportunity statement your team can act on.

I write these as “How might we” prompts tied to a specific stage. For the GST pricing dip: “How might we show the final GST-inclusive price on the product page so trust holds at checkout?”

This is often the difference between a map that gets used and one that gets filed away. It is also a big reason why many UX applications get rejected for weak insight: candidates show the journey but never connect an observed emotion to a concrete design opportunity.

Keep every opportunity traceable back to a quote or an observed behaviour, and your map stays honest and defensible.

Gathering the Inputs and Research That Fuel Your Map

The fastest way to derail a user journey map is to build it on a room full of assumptions. I have sat in workshops where the loudest voice becomes the “user”, and the result is a map that flatters the team but describes nobody real.

A credible map rests on evidence. That means blending qualitative sources that tell you why people behave the way they do with quantitative sources that tell you how many and where.

Qualitative Sources: The Stories Behind The Behaviour

Qualitative research is where you hear the frustration in someone’s voice. I lean on three staples: user interviews, usability tests, and support tickets.

Support tickets are the most underused goldmine I know. If you run a Singapore e-service, the feedback form comments on your government portal are effectively free interviews, full of phrases like “I couldn’t find where to upload my NRIC scan”.

Usability tests do not need a lab. Watching five people attempt one task over a video call will surface more problems than a month of internal debate.

Whenever you record or store any of this, treat it under PDPA. Anonymise names, strip out identifiers you do not need, and be clear with participants about how you will use their input.

Quantitative Sources: The Scale and The Drop-offs

Numbers tell you which pain points actually matter. I start with web and app analytics, then map the conversion funnel to spot where people leak out.

• Analytics for pageviews, time on task, and device splits
• Funnel reports showing drop-off between steps, for example, checkout or form submission
• Surveys sent after key interactions to quantify satisfaction

If sifting through spreadsheets feels slow, there are some genuinely useful AI hacks to speed up data analysis that help you summarise open text responses and cluster feedback in minutes.

Picture a local startup using Enterprise Singapore grant support to fund a proper round of user research, covering interview incentives and a survey tool. If that funding is not available to you, you can still run guerrilla research: a short Google Form and a handful of coffee chats will get you most of the way.

The goal is triangulation: when your interviews and your funnel data point at the same problem, you can trust it.

Running a Workshop to Synthesise Findings

Once you have your inputs, get the team in one room, physical or virtual, to make sense of them together.

I print or paste every finding onto sticky notes, then cluster them into themes on a wall or a Miro board. Patterns emerge quickly when a marketer, a developer, and a support agent all recognise the same complaint.

Keep it lightweight. A ninety-minute session with clustered notes and a shortlist of agreed pain points is enough to feed the actual mapping stage that follows.

Building the Map Step by Step

Now for the fun part: turning your research into an actual user journey map you can share. I always tell clients to aim for a rough first draft, not a polished masterpiece, because the insights come from filling in the cells, not from making it pretty.

Let me walk you through it using a real scenario. Imagine a Singapore home-services SME, say an aircon servicing company, mapping the journey from a customer booking online to the technician finishing the job.

Choosing a Tool and Template

Pick a tool you can actually get moving in today. My default order is a simple Google Sheet if you want zero friction, Miro if you love sticky notes, or Figma if your team already designs there.

For that aircon business, I would go with Figma because the marketing person can drop in screenshots of the booking form right alongside the map. If Figma is new to you, follow along with a step-by-step Figma tutorial for beginners so the interface stops feeling intimidating.

You do not need to build from scratch either. Browse the best Figma templates to kickstart your work and grab a journey map layout, then strip out anything you do not need.

Laying Out The Swimlanes Row by Row

Think of the map as a grid. The columns are your stages, and the rows are horizontal swimlanes that you fill in one at a time.

Start at the top and work down. For the aircon example, your build might look like this:

1. Persona banner: A strip naming your customer, for example, “Mdm Tan, a busy HDB homeowner who wants same-week servicing”.
2. Stages: The columns across the top, such as Awareness, Booking, Confirmation, Service Visit, and Follow-up.
3. Actions: What she does at each stage, like searching “aircon servicing near me” or filling in the booking form.
4. Touchpoints: Where it happens, such as Google, the website, a WhatsApp confirmation, or the technician at her door.
5. Emotions: A simple high or low, so a wait with no confirmation message shows as a clear dip.
6. Opportunities: The fixes, like sending an automated WhatsApp reminder before the visit.

Fill one row across all stages before moving to the next. This keeps you consistent and reveals patterns, like emotions dropping every time communication goes quiet.

Reviewing The Draft With Stakeholders

Once the grid is populated, resist the urge to perfect it alone. Pull in the people who touch this journey daily.

For the aircon SME, that means the phone booking staff and a technician. In one review I ran, a technician pointed out that customers were often confused about the arrival window, an emotion the map had missed entirely.

Treat that first review as an editing session, not a presentation. Mark up the map live, capture disagreements as notes, and refine after. Your second draft will be far stronger than any version you could have polished in isolation.

Turning Insights Into Action

I have seen too many beautiful user journey maps end up as poster art in a meeting room. They get admired, then forgotten, and nothing about the customer experience actually changes.

A map only earns its keep when it drives decisions. So the moment you finish mapping, your real job begins: turning those sticky notes full of frustration into a backlog of fixes that someone is accountable for.

Prioritising by Impact and Effort

Not every pain point deserves the same urgency. I plot each one on a simple impact versus effort matrix, so the team can see which fixes give the biggest return for the least work.

Say you run a local e-commerce store and your map reveals two problems: a confusing delivery fee that appears only at the final checkout step, and a slightly dated product photo style. The delivery fee surprise is likely high impact and low effort, so it goes to the top.

Prioritise the pain points that quietly bleed revenue before the cosmetic ones.

Assigning Ownership and Next Steps

A prioritised list still goes nowhere without an owner. Every item on your backlog needs a name attached, a clear next step, and a target date.

Picture a Singapore clinic where the map shows patients struggle to cancel an appointment, so they simply do not show up. That single insight becomes a real task list:

1. Add a one-tap cancellation link to the SMS reminder (owner: clinic operations lead, two weeks).
2. Rewrite the confirmation message so the cancellation policy is clear (owner: front desk manager, one week).
3. Test an automated waitlist that fills cancelled slots (owner: IT vendor, one month).

Suddenly, the map is a working plan, not a wall decoration.

Measuring Whether Fixes Worked

Leadership stays bought in when you tie every improvement back to a number they care about. Before you ship a fix, agree on the metric it should move.

For the e-commerce store, that means tracking checkout drop-off rate before and after you clarify delivery fees. For the clinic, it means watching the no-show rate fall over the next few months.

When you can show that a UX change reduced abandoned carts and lifted completed orders, you help the whole team build sustainable digital marketing ROI rather than chasing vanity metrics.

Finally, treat the map as a living document. As your product evolves, new features add new steps and new friction, so revisit it every quarter or after any major release to keep your view of the customer honest.

Common Mistakes and How to Avoid Them

I have seen brilliant workshops produce a beautiful user journey map that nobody looks at again. The map is not the problem. The habits around it usually are.

Let me walk you through the traps I keep running into and the quick fixes that actually work.

Mapping What You Assume, Not What Happens

The most common mistake is building the map from inside the meeting room. The team imagines a clean, idealised flow and forgets that real people behave messily.

Nielsen Norman Group makes the case for why this happens structurally, not just carelessly: when success metrics live in separate departments, no one on the team is actually responsible for seeing the whole experience through the user’s eyes, so each person’s mental model of the journey quietly diverges from everyone else’s, which is exactly the “every version was different” moment I opened this guide with.

Picture a Singapore government service team mapping a SingPass login step. On the whiteboard it looks effortless: open app, scan face, done. In reality, an elderly user might struggle with the QR scan, mistype their NRIC, or give up and call their daughter for help.

If your map only shows the happy path, it hides the exact friction you were meant to fix. The fix is simple: ground every stage in evidence. Even three short interviews or a few support tickets will expose gaps your assumptions miss.

Maps Too Complex to Read, or Built in a Silo

The second trap is over-engineering. When a map crams in twelve columns, colour codes, and every micro-emotion, people glance at it once and never return.

Keep it scannable. A map should be readable in under a minute, with the key pain points obvious at a glance.

The third trap is building it alone. A journey map made by one person, or one department, misses reality and, worse, misses buy-in.

Here are the quick fixes I lean on most:

• Bring in a customer service or frontline colleague; they know the real complaints.
• Invite one sceptical stakeholder early so the map has an ally, not a critic, later.
• Cut any detail that does not change a decision.
• Validate at least the biggest pain points with actual user input.

If you are hiring or being interviewed for these skills, notice how UX designer interview questions that test real thinking often probe whether you rely on assumptions or evidence.

Letting The Map Gather Dust

The final mistake is treating the map as a one-off deliverable. You run the workshop, print the poster, and six months later it no longer matches your product.

A journey map is a living document. Revisit it whenever your product, users, or data change, and keep it somewhere the whole team can see and edit.

Do not aim for a perfect map. Aim for a shared, evidence-driven one that people actually use. That is far more valuable than something flawless nobody opens.

Conclusion

We started this guide with a blank page and a simple goal: to see your product through your customer’s eyes.

Along the way, we defined a specific persona and a realistic scenario, then mapped out the stages they move through, the emotions they feel, and the pain points that quietly cost you conversions.

The real value of a user journey map is not the artefact itself. It is what happens next when you turn those insights into prioritised, high-impact improvements.

That is the core rationale I keep coming back to. A journey map drags hidden friction into the open, so your team stops arguing from assumptions and starts fixing the moments that actually matter to real people.

You do not need a big workshop or fancy software to begin. Pick one scenario this week, sketch it on a whiteboard or a Miro board, and share it with one colleague who owns part of that experience.

If you want to go deeper and build this skill properly, formal training helps you practise with structure and feedback rather than guesswork.

For hands-on, guided practice building real journey maps and translating them into working interfaces, I would point you to the WSQ User Experience & User Interface (UX/UI) Design Essentials course, which is SkillsFuture-supported for eligible Singaporeans.

It is the logical next step because you learn by doing, mapping and designing alongside a trainer instead of figuring it all out alone.