User Journey Mapping: Visualize User Research, Brainstorm Opportunities, and Solve Problems

Copyright © 2022 SitePoint Pty. Ltd.

Ebook ISBN: 978-1-925836-49-3

- Author: Stéphanie Walter

- Series Editor: Oliver Lindberg

- Product Manager: Simon Mackie

- Technical Editor: Jim Kalbach

- English Editor: Ralph Mason

- Cover Designer: Alex Walker

Notice of Rights

All rights reserved. No part of this book may be reproduced, stored in a retrieval system or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Notice of Liability

The author and publisher have made every effort to ensure the accuracy of the information herein. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors and SitePoint Pty. Ltd., nor its dealers or distributors will be held liable for any damages to be caused either directly or indirectly by the instructions contained in this book, or by the software or hardware products described herein.

Trademark Notice

Rather than indicating every occurrence of a trademarked name as such, this book uses the names only in an editorial fashion and to the benefit of the trademark owner with no intention of infringement of the trademark.

Published by SitePoint Pty. Ltd.

10-12 Gwynne St, Richmond, VIC, 3121

Australia

Web: www.sitepoint.com

Email: books@sitepoint.com

About SitePoint

SitePoint specializes in publishing fun, practical, and easy-to-understand content for web professionals. Visit http://www.sitepoint.com/ to access our blogs, books, newsletters, articles, and community forums. You’ll find a stack of information on JavaScript, PHP, design, and more.

About the Author

Stéphanie is a User Researcher and Designer who focuses on building user-centered, inclusive and accessible products and services. She spent the last 11+ years helping her clients in different industries (banking, financial, automotive, healthcare, press, travel, etc.) deliver successful projects to their audience, all the way from strategy to the final product.

Preface

Who Should Read This Book?

This book is for anyone who wants to get insight into the use of user journey maps: what they are, how to create them, and how to use them. No prior experience is required.

Conventions Used

Code Samples

Code in this book is displayed using a fixed-width font, like so:

<h1>A Perfect Summer's Day</h1>

<p>It was a lovely day for a walk in the park.

The birds were singing and the kids were all back at school.</p>

You’ll notice that we’ve used certain layout styles throughout this book to signify different types of information. Look out for the following items.

Tips, Notes, and Warnings

Hey, You!

Tips provide helpful little pointers.

Ahem, Excuse Me ...

Notes are useful asides that are related—but not critical—to the topic at hand. Think of them as extra tidbits of information.

Make Sure You Always ...

... pay attention to these important points.

Watch Out!

Warnings highlight any gotchas that are likely to trip you up along the way.

Supplementary Materials

- https://www.sitepoint.com/community/ are SitePoint’s forums, for help on any tricky problems.

- books@sitepoint.com is our email address, should you need to contact us to report a problem, or for any other reason.

Chapter 1: An Introduction to User Journey Maps: What They Are, and What They’re Useful For

Imagine you want to buy a gift for your friend online. You might start by looking for some inspiration. What does this person like? You might use search engines, but maybe also inspiration boards. Or maybe some of those “top ten gifts for X” articles that are popular, especially around Xmas. You finally arrive on a website that offers the kind of things that inspire you. You go through categories, maybe use the search. You find the right gift, you go through the checkout process. The experience was good and quite simple. You buy it. Then you wait. And it never arrives. After a couple of days you try to contact the shop. It takes them more than a few days to answer. Eventually, after a lot of back and forth with them by email and over the phone, they find out what was going wrong. They agree to send you another one. But sadly, it doesn’t arrive on time for the birthday. You might have had a decent—maybe even good—experience on the website. But how about the overall experience?

When building websites and services, designers need to understand that whole experience. And to do that, we have one very powerful tool: user journey maps. A user journey map is a visual document that will show the whole experience of a user in a chronological way. It documents user goals, phases in the journey, tasks, pain points, sometimes feelings. It helps teams build products by showing a global view. This brings stakeholders and teams together on the same page. It helps brainstorm opportunities to improve the product and solve those pain points. And it lists touch points and channels, which helps break down different gaps you might have in your organization. In my example here, maybe there were organizational issues between the team building the site and the support team, which led to the support being late.

Let’s start our journey of discovering user journey maps with a big overview. In this first chapter, we’ll focus on what user journeys are and what to include in them. We’ll see an example of how a user journey map was used on one of my previous projects. Finally, we’ll see some of the benefits of such a tool, but also things you need to be careful about.

What Is a User Journey Map?

A user journey map helps document and visualize the step-by-step experience someone has with a product or service, from the beginning to the end. It lists the different actions users take to accomplish their goal.

Alternative Names

Be aware that you may also come across user journey maps described by other names, such as “experience maps” or “user experience maps”.

Those actions are arranged in chronological order, often presented as a timeline. The beginning of the journey is on the left, and the end on the right, with all the steps in between. It helps designers (and stakeholders) get a global overview of the whole journey.

The following image shows an example of the Miro customer journey map template.

To build a user journey map, you need data. So you’ll start by conducting user research: interviews, observation, task analysis, and so on. You want to identify and understand those actions in a chronological way. The map is then built as a document that will synthesize this research.

The image below shows an example of the Wikipedia Experience Translator journey.

This tool comes from the field of marketing, where you might hear it called a “customer journey map” or sometimes “customer map”. The concept is close: map the user customer experience in a chronological way.

What to Include in a User Journey Map

You might have noticed that the maps above are different. There’s no “one size fits all” rule for building a journey map. It depends on your product or service, the experience, and what you discover during research. Here a few things that are usually part of the map:

- Scope: what is the map about, and how big? Do we list the whole experience, or a small part of it?

- User goal: what is the user trying to accomplish?

- Journey phases: what are the big steps a user is going through to pursue this goal? Even if your core experience is an app or website, interactions before and after this can be interesting to capture.

- User actions or tasks: for each step or phase, what do the users need to do?

- Pain points: what annoys the user here? Are there any frictions?

- Opportunities: how might we improve this?

An example of what you can use in a user journey map

We’ll go into more details for each of those points in Chapter 3 of this book.

Depending on what you discover during your research, you might find any of the following:

- Emotions: how does the user feel during this phase?

- Triggers: what pushes users to take that decision at that specific step?

- Obstacles or barriers: what prevents the user from going to the next step?

- Knowledge gap: what kind of information is required to complete this step? What does the person need to know?

- Touchpoints and channels: is the user interacting with the product on their phone? With customer support? What channel in the company is responsible for this part?

- Effort: how hard (or easy) is it to do business with you?

If you want to go further, the Nielsen Norman Group has a “Journey Mapping 101” article with more information on the components.

The Utility of a User Journey Map: a Real-world Example

A few years ago, I was working on a product in the automobile industry. The product was a mobile app and a desktop dashboard to help car dealerships save time on extra repairs.

Let’s say you bring your car to the dealership, because there’s an issue with the lights. You leave it with the mechanics. They take a look. And they discover that you also have a problem with the breaks. They need to change them too. Extra repairs!

Most of the time, the mechanics report this to the service desk. Then, the service desk tries to reach out to you to ask you if you agree to repair those breaks too. (I hope so! Security first!) This takes time. Maybe you’re at work and they can’t reach you. During all this time, the car is waiting on the deck and the mechanics are waiting for a decision.

The tool I worked on helps streamline this process. The mechanics have an iPhone app. They take pictures of the car when it arrives (mostly for insurance to show that this scratch was there before). When they discover the breaks are damaged, they take a picture, or a small video to show this to you. That information is then sent from the iPhone, via the web app, to the service desk. The service desk turns this into an invoice and sends it to the customer.

The customer (that’s you) then gets a link in an SMS. When you open the link, you see the pictures, the video, the invoice for the extra brake repairs. You can digitally sign it, accept the extra work, and then they can start the extra repair.

The reason I’m able to describe this whole process precisely is because we did user research on this. We went to the dealerships and talked to mechanics and service desks. Then we built a map of this whole experience.

User Journey Map (in French) for the mechanics before, while using the app, and after

Most of the experience was quite nice. People were happy with the app; it worked nicely. But we discovered two interesting pain points along the way:

- At the end of the “sending pictures to the front desk” step, people were unhappy because it sometimes took time. They were stuck in the last step, waiting for pictures to be sent, and couldn’t start a new process with a new car. They had to keep the phone unlocked and the app in the foreground, as otherwise it wouldn’t synchronize.

- There was also some frustration after the use of the app. Sometimes the client replied quickly, but the front desk was super busy. So it took them some time to go to the mechanics to tell them they could start the extra repairs.

For the second pain point, some smart mechanics found a workaround. They went to the history in the app and refreshed the page until they saw that the status was “accepted” (or rejected). Smart, but not efficient.

A simplified version of the journey map that shows the two pain points and opportunities

Once we mapped the whole process and understood those major pain points, we were able to find some opportunities.

- The first issue was solved with background synchronization. This way, users weren’t stuck on the last step until all the pictures were synchronized.

- For the second issue, we proposed push notifications to the mechanics’ phones when the client accepted or rejected the extra repairs.

Better understanding the whole journey step by step helped us identify those pain points. And more importantly, it helped us bring interesting features to our users.

The benefits of User Journey Maps

There are many benefits of conducting user research on the whole experience and building user journey maps. In the example above, I already showed you how it helped to:

- identify major user pain points during the whole journey

- find feature opportunities to improve apps and services around those pain points

There are many other benefits and reasons why you should build such maps:

- They give a visual overview of the user experience over time, and of user steps. So they help you see the global picture, and get everyone on the team—from designers to stakeholders—on the same page. Visual tools are often powerful tools, especially during meetings with stakeholders.

- They are a communication tool that will help make better product decisions based on actual user needs.

By visualizing the customer journey, you can plan better. Aim to create a consistent customer experience that is relevant across all channels. — pragm.co

- They help map and break down different gaps you might have in your organization or product: gaps between siloed departments; gaps between different channels in the company; gaps between what the user knows and what they need to know (knowledge gap); gaps between stakeholder perceived experience and actual user experience. Once those gaps are identified, it’s easier to solve them.

- They help other people get a better understanding of the actual journey of real users, building a more user focused culture in the process.

- They help build better omni channel experiences. Because again, they map the whole story, not just a small part.

Potential User Journey Map Pitfalls

User journey maps are as good as the user data used to build them. They’re a visual way to present the key findings of some user research. This means that, if you start with poor research and inaccurate data, you’ll end up with inaccurate maps.

Avoid building them into the echo chamber of your conference rooms. With zero research and only stakeholder (or marketing) input, all you’ll manage to do is to build a “map of all the biases and assumptions we have about our journeys”. In Part 2 of this series, I’ll explain how this “map of assumptions” could still be a good starting point for kickstarting some research. You need to involve your users and customers to build and verify the map in order for this to be useful.

There’s also a good chance you won’t have a one-size-fits-all journey. You’ll end up with different user journey maps for different personas. And that’s perfectly fine. Don’t try to fit everything in one clumsy big map. Prefer building a network of multiple little ones, around specific user goals and personas. This also means that you need some data on who your users are. A generic, one-size-fits-all persona won’t do the trick.

Another common mistake is to focus the map too much on the company touchpoints and processes. Again, this is about the experience of the user. Starting with listing your touchpoints and channels is tempting. It sounds easy, and you know them well. But again, be careful with echo chambers. The map should be built around user experience, and the phases to accomplish their goals—not your internal company process, because it might not reflect how users actually use the product or service.

Last but not least, user journey map building isn’t a situation of “build once and you’re done”. Your product changes over time, so user experience will change and evolve. User journey maps are documents that need to be often revisited and be kept up to date. More on that in Part 5.

Conclusion

A user journey map is a powerful tool in a designer’s toolbox. It’s a versatile tool with many benefits.

But be careful when using user journey maps. Build them based on real user data. And avoid echo chambers and a focus on your internal company process. It’s as much about channels and touchpoints as it is about the whole experience a user has with the product and service. And this is what you need to map, in order to build useful accurate journey maps.

We’ve only scratched the surface so far, and we’ve only looked at one type of map. In Part 2, I’ll present alternative types of maps and what you can do with them.

Chapter 2: The Different Types of Maps and How to Use Them

In Chapter 1 of this book, I explained what user journey maps are, why they’re useful, and what to include in them. I also explained the things to watch out for when creating user journey maps.

You now have an idea of the type of things we’ll be building. Chapter 1 mostly focused on one type of map: the current journey map. But user journey maps come in many different flavors. This second tutorial will focus on what makes the user journey map such a versatile tool. You can map plenty of journey types, in many different ways.

We’ll cover some of the most common “types” of user journey maps. Apart from current journey maps, there can be hypothetical discovery maps, future maps, and even disaster user journey maps—which map what might go wrong with our product. You can also mix journey maps with other processes such as task analysis. For each type, we’ll see when or how you can use them, their pitfalls, and gotchas to watch out for.

The Current or As-is Journey Map

The most common role of user journey maps is mapping the actual current journey. I described this in detail in Chapter 1. It’s a map that shows how one specific persona currently interacts with a product or service—or how that persona tries to accomplish one specific goal. So you might have several journeys for different personas.

Example of a current journey map on an ecommerce website that sells sport shoes

You may have encountered another type of map called a “day in the life” map. It’s quite close to the current journey map, except that it focuses on one specific day. It also goes into more detail about what happens around the product on that day.

There are also “experience maps”. Those don’t focus on a specific journey in one single product, but rather on a generic experience a person might have with multiple products. (Nielsen Norman Group has a nice article comparing empathy maps, customer journey maps, experience maps and service blueprints.)

These are the times to consider using a current journey map:

- Once you have enough research data to build a map based on real user goals, pain points and journeys (with no guesswork!).

- You want to bridge the gap between how stakeholders think people use the product and the real usage.

- You’re looking for places to improve upon, feature opportunities, and so on.

- You want to link different steps of the process to different channels and get everyone on the same page.

For the pitfalls and what to be careful about with this type of journey map, refer back to Chapter 1.

Hypothetical Discovery Map

A hypothetical discovery map is based on your assumptions and hypotheses. Now, I did say in Chapter 1 that we should avoid building user journey maps into the echo chamber of our conference rooms, and avoid building maps without real user data. That’s the case in a perfect world, where the company is user focused. But sometimes, you might not have access to users yet.

If you’re in such a situation, you can start with a hypothesis, then use this to get the budget and buy-ins to conduct the research to verify your hypothesis and go further.

If you build such maps, you’ll usually start by looking at the “happy path” in your product and services. That is, the path your teams imagine the user will experience. You might also have access to analytics or marketing data. Even if it’s not always the best qualitative data, it could help. For example, look at the major paths users go through in Google Analytics.

The image below shows an incomplete example of a hypothetical journey map we built as part of the discovery phase. We based this on what we knew about our users from analytics and marketing—as well as the current path on the website.

When to use a hypothetical journey map:

- When you don’t have access to user data yet but want to map what the journey might be like based on how you built it.

- As a baseline for the team and stakeholder assumptions. Then you can compare assumptions versus reality.

- To help you guide user research into what hypotheses you should be verifying, and what areas you should we verifying with users.

- To start with a hypothesis to get buy-ins and a budget for research.

These are some pitfalls of hypothetical journey maps and what to be careful about:

- These maps aren’t based on actual user data, so you might miss a lot of the steps and actions outside of your product and your own channels.

- You won’t have access to user emotions. Pain points are also harder to capture for hypothetical maps.

- Always make it clear, when you present such maps, that they involve hypotheses, and that you need to verify those at some point.

- Your team might be tempted to stop at assumptions and think the work is done. So it can become a double-edged sword. Be aware of this. Always present hypothetical maps as incomplete and partial overviews that need user verification.

(Desired) Future Journey Map

What could the future user experience look like? What will the experience look like once we’ve tackled all the pain points we’ve identified? What will the user experience look like in two years? Five years? A perfect future map shows the product vision.

This kind of map is more of a brainstorming tool. It helps the team ideate on what the perfect experience should look like. It also helps the team to project solutions.

The image below shows an example of what a future map can look like, with extra content for the difference between current and future state and how we might achieve it (budget, time, and so on).

Here are some pointers on when to use a future journey map:

- On a current project, once you’ve built the current journey map, it can be used as a brainstorming exercise for imagining the future.

- As an exercise on how might we improve this. For example, you might do this when you haven’t found improvements for user pain points in the current map.

- As an exercise on “who would be responsible for that part”.

- On a new product, as a kind of vision board of what you want to build, or of what the perfect future experience would look like. Then you can start thinking about how to achieve this.

Here are some pitfalls of hypothetical journey maps and what to be careful about:

- Some people will think big when building such maps, while some will think small. It’s up to you to decide if you already want to add constraints (budget, time, and so on) while building the map, or if you want people to be free to dream big, without any constraints. I find it’s always better to manage expectations at least a little bit, and to map a realistic future. But I’m a pragmatic designer.

- If you build such a map on an existing product, I recommend you build on real user data first. The “opportunities” part of the user journey map will help you.

- Again, when presenting, make it clear that this is a future map—a goal that you’re trying to achieve.

Once you’ve built this, you can then decide how to bridge the gaps between current and future maps, considering such things as:

- Timeline: when should we achieve this part of the goal?

- Budget: what type of budget will we allocate to this part?

- Accountability: whose team or service will take care of what? Who’s responsible for what improvement?

Disaster User Journey Maps

I discovered disaster journey maps on Debbie Levitt’s podcast. We tend to easily think about the happy path. But what about “what might go wrong if the customer runs into a feature that might cause a potential disaster?” Meet the disaster user journey map. The goal is to map out what could go wrong with a user experience or a feature, in order to avoid or prevent it.

This is another map based on brainstorming. But you’ll also use your user pain points and the data you collected to build those. In the words of Debbie Levitt in Delta CX: The Truth About How Valuing Customer Experience Can Transform Your Business:

What kind of artefact can you create when you are trying to convince teammates to not move forward with a bad idea? Try Delta CX’s “Customer Disaster Journey Maps”. This document looks at the possible future state of a path our customers might take … and what a disaster it would be for them. This storytelling style might work, and you will be an action hero who keeps the customer from disastrous UX decisions!

The image below shows an example of the beauty box disaster unhappy customer journey map, courtesy of Debbie Levitt from Delta CX.

When to use disaster user journey maps:

- When you think some features might lead to a bad experience or customer dissatisfaction, and you want to brainstorm how to prevent it.

- When you need to convince your teams that something they want to build could be a potential disaster.

These are some pitfalls to watch out for and tips for dealing with them:

- People might not like what you’re showing, call you out for being too dramatic, or not listen to you. If this happens, document it as a potential risk for the project.

- Get help to build this from people whose job is is to prevent or react to user disasters—people like the legal department, security, customer support, and of course designers.

Other Useful Types of Maps

All the maps above are built around the user or customer as the main entry point. There are other kinds of maps for understanding the global picture of an experience or process. Let’s look at some examples.

Task Analysis Maps

With user journey maps, you list the user actions and tasks. But you don’t always capture the granularity of each step. On a recent project, I conducted a deeper task analysis. It was a structured method to identify “the actions and cognitive processes required to accomplish a specific goal” (to quote the Usability Body of Knowledge website).

This is for a B2B document validation tool. The tool exists in a desktop browser. We worked on building an iOS app for it as well. I conducted user research to map the current journey using the browser version. I then built a deliverable that mixed a little bit of task analysis and journey mapping. This map included:

- The main phases of the journey (five for this project: one before using the app, three while using the app, and one after).

- The main steps in the user process (the journey map).

- A detailed task analysis with arrows when there was branching (task analysis), for each step.

- Some Post-it notes showing the pain points for each step.

The image below shows an example of a task analysis map with the steps of the journey at the top and the list of tasks and subtasks highly detailed.

This hybrid map helped me plan the user flow of the new mobile app. We were also able to bring in some interesting features to solve some of the desktop pain points.

Process Maps

I worked on a project to help people in a car rental company find the cars in a big parking space. For this project, I did some observation analysis. We went to the company, interviewed people working in the whole process, and watched them work—an exercise known as shadowing. (There will be more details on gathering the research data for such methods in Chapter 3.)

There were several people involved with different roles. So for this project, it made more sense to use the journey of the car as an entry point in the map. Yes, you read that right. Car journey map anyone? Well, actually, it was more like a “user journey based on the rental car process”.

The following image shows what it looked like, with the process map following the process of the car (at the top). The gain points are in green at the bottom, and the pain points in red under the gain points.

We mapped the user pain points with the current process, and mapped the potential gains of a new process with our future mobile app and beacons to help find the cars. Mapping the potential gains helped us sell the mobile solution to that client.

Service Blueprints

Finally, you may have heard of service blueprints. Here’s how Nielsen Norman Group defines them:

A service blueprint is a diagram that visualizes the relationships between different service components—people, props (physical or digital evidence), and processes—that are directly tied to touchpoints in a specific customer journey.

The image below shows an example of a service blueprint template from UXpressia.

Conclusion

I attended a talk on card sorting and the author concluded like this:

You can use card sorting to sort almost anything.

I think it’s the same for journey maps. As long as there’s a chronological experience, you can map it as a journey map. It can have different forms and different purposes. And that’s the beauty of it. It doesn’t have to be perfect. But you need to build it on real data (unless, of course, you’re building a hypothetical discovery map). And it has to fit your specific project needs. The goal is to improve the journey for our users. Feel free to include anything that will help you head in that direction.

You may also be interested in checking out employee experience maps—if, for example, you need to map the experience of onboarding new employees.

In Chapter 3, we’ll dig a little bit deeper and see how to conduct user research in order to gather the real data you need to build these maps.

Chapter 3: Conducting User Research

In Chapter 1 of this book, we covered what user journey maps are and why they’re beneficial. In Chapter 2, we looked at the different kinds of maps you could build—from current journey maps to disaster maps, future state maps, and everything in between.

To build these maps, you need to collect data on your users. This is what’s called user research. It’s the discipline that focuses on understanding user behaviors, needs, and motivations. If you skip user research, you’ll only be able to build hypothetical discovery maps. These can be a handy place to start for brainstorming purposes, but you can’t build better products if you don’t understand real needs, tasks and pain points. I can’t emphasize this enough: every project should start with user research—whether it’s your own research or research previously conducted by others.

User research is a broad discipline, and there are many ways to go about it. This might sound overwhelming, especially for beginners in the field. But don’t be afraid! I’m here to help you.

In this third tutorial, I’ll guide you through how you prepare your research and what to focus on. I’ll show you specific user research methods you can use to collect different types of data. We’ll look at both quantitative and qualitative methods. This way, you’ll have a wide range of tools at your disposal for different situations.

What to Focus User Research On

I’ll detail different research methods later in this tutorial. But firstly, we need to consider what exactly we’re searching for. Whatever our methods or tools for gathering data, this is the kind of data we need to be looking for in order to build user journey maps:

- User segmentation/personas: who is my user? If you already have personas, or market segmentation, this is a good starting point. Focus on one or two personas per map, not all of them at once. (You can build multiple maps.)

- User goals: what are users trying to do? Why are they using my product or services? What are their goals?

- User contexts: Where do the users come from? How do they arrive in my product? Where do they go next? What happens once they reach their goal?

- User motivations: what makes users decide to do something? What drives them or stops them from interacting?

- User tasks and actions: what tasks and activities do users undertake to pursue their goals? How long does it take them? What are the different steps?

- User pain points: how easy or difficult is it for users to achieve their goals? What information do they need to accomplish those goals? What prevents them from accomplishing their goals? What makes them give up or abandon their attempts? What challenges do they face?

- User touchpoints: who or what do users interact with (that is, what are the touchpoints)? What devices are they using?

This list isn’t exhaustive, and what you choose to cover will depend on what you want to put into your maps. Specific industries might need specific data. But it’s a starting point.

Preparing for Research

Once we know what kind of user data we want to gather, it’s time to prepare the research. Here are some steps to follow.

Conduct Stakeholder Interviews to Define Objectives

Talking to the stakeholders before starting the user research will help you understand what you’re going to focus on. This can also give you some pieces of information to start answering some of the questions above.

Different types of stakeholders that can help include product owners, sales and marketing staff, and support and customer service people. They can help you answer questions related to your objectives, such as these:

- What does our current process for this task look like?

- What parts of our user experience don’t we understand yet?

- Where are the current points of friction?

- What parts of the experience do we want to improve in the future?

- What parts that generate leads or revenues should we focus on?

- What are our current touchpoints with users?

Those discussions will help define objectives for the map and will help your team move forward.

Is There Any Data Already Available?

Before I jump into conducting new research, I always try to establish if there’s data already available. I usually see this as a puzzle, with different people having different pieces. Talking to all of them helps me understand the global picture and solve the puzzle. Some of the stakeholders mentioned above might have access to previously collected data about users.

So, start by asking if anyone has already built some user or customer journey maps. Marketing teams often have some kind of data on the topic already. Reaching out to them can be a first step. Marketing people might also be able to help you map a very first draft of touchpoints and user steps, as well as acquisition channels—or where users come from before arriving at your product.

Customer support people are in direct contact with users. They usually have tons of interesting data. Reaching out to them can help you gather data on:

- user pain points and frustrations (no one contacts the support team just to say hello, but to get help when they have issues)

- different channels and touchpoints (phone, email support, some FAQ, and so on)

- information about tasks and activities

If you work on a SaaS or B2B product, you might also have some people who do training—either for end users, or for some kind of in-between coordination people who’ll then train end users. In both cases, like support, they usually have plenty of data as well. You can look at FAQs again, support material, and so on. This also helps to identify pain points and knowledge gaps.

Prepare a Research Plan with Scope and Target Audience

Usually, existing data is a good starting point. But it’s rarely enough on its own for building accurate user journey maps. So it’s now time to build your research plan. A UX research plan explains why and how you’ll conduct the research. It includes the background, the goal of the research, the hypotheses behind the research, the target audience, and things like the methods, timeline, budget, resources, and expected outcomes involved.

The image below shows an example of a UX research plan template you can download on Taylor Nguyen’s website.

First, you’ll decide on the scope of the map, which will also be reflected in the scope of your research. For example, you might ask whether you’ll build a map for the entire travel experience (a bird’s-eye view), or focus on some specific parts of that journey. You might, for example, decide that the map will focus on booking a flight online. The answer depends on what your objectives are (along with with the stakeholders), and what areas you want to improve.

The plan also identifies the target audience of the research—the users you’re focusing on—because you need to recruit those people. Again, if you already have some personas, you can use them here. Marketing segments can also help you in this regard.

The plan can also include your research hypotheses. One way to help you with these is to build a hypothetical discovery map (discussed in Chapter 2). This will help you gather the research questions and the hypotheses you need to verify.

Timeline, Budget and Resources

Unfortunately, we don’t have the space in this tutorial to cover aspects relating to the timeline, budget and resources part of the planning process.

The last thing you’ll list are the methods. For user journey maps, you usually want to combine qualitative and quantitative research. There are lots of user research methods and activities. Let’s cover that topic in the next section.

Indirect Quantitative Data Gathering Methods

In this and the next section, I’ll detail some research methods that are particularly useful for gathering data to build your user journey maps. Firstly, I’ll focus on quantitative methods.

Website Analytics Data

You can gather quantitative data on an existing site that has analytics tools (such as Google Analytics, Matomo, and so on). These kinds of tools give you a lot of metrics that you translate into quantitative data. You can identify which pages people are visiting and what they’re doing on them. This gives you some clues about their tasks and activities. You can also identify where they’re leaving the site, which gives you a first clue about painpoints.

The image below shows behavior flows in Google Analytics.

Be careful, though. These tools show you the “what” and the “how often”, but not the “why”. So they can be open to misinterpretation.

SEO expert Myriam Jessier says the following in her article “Google Analytics Metrics to Measure UX Success”:

Mixed methods will often involve knowing how to keep users happy, even when it comes to technical elements like load time. You can gain actionable insights from Google Analytics as a UX expert.

In a recent project I worked on, we didn’t have analytics, but we did have server logs. We knew which pages were the most visited. It was tempting to conclude that people were interested in the content of those pages. One page in particular had a lot of visits. A “real” analytics solution might have shown us that users were leaving the page after five seconds. But we only had server logs. So we also conducted interviews, and discovered that users were entering the page only because there was a particular link that was drawing their interest.

Another limit of analytics is the scope. You only get information on what’s happening on your site. This makes it harder to build a journey that goes beyond your site.

To get different angles, researchers will combine analytics data with other methods.

Session Replays

Session replay tools (such as FullStory and Hotjar) record what people are doing on your site. You can then replay their sessions.

This can help build the steps, tasks and activities of your journey map. It can also give you some clues about user emotions. For example, rage clicks can show user frustration. But here again, we’re in the domain of interpretation. So we need to be careful about that.

The following image depicts a session replay using FullStory, showing step by step what users are doing on a site.

Like analytics tools, session replays show you the what, how, and how often. But you still don’t know why people do what they do. These tools are also prone to your own interpretation biases. Once again, you need to combine this research method with other methods to account for this.

On Using Surveys for Research

Some resources list surveys as a research method for gathering data to build journey maps. I would be careful with that.

Surveys are one of those methods that look super simple. Erika Hall, author of Just Enough Research and Conversational Design, has written the following:

Surveys are the most dangerous research tool—misunderstood and misused. They frequently straddle the qualitative and quantitative, and at their worst represent the worst of both.

And I agree with her. I’ve seen many biased and bad surveys over the years. They’re a hard tool to master.

If you still want to use surveys to gather data, check Nielsen Norman Group’s “28 Tips for Creating Great Qualitative Surveys”.

Qualitative and Direct Research Methods

As in the last section, I’ll detail some research methods for gathering data to build your user journey maps—in this case, qualitative and direct research methods.

User Interviews

Analytics give you the what and the how often. If you’re interested in the why, the best tool is user interviews. The interview is a one-to-one session with users. Researchers conduct them face to face. They can be live or asynchronous (that is, answered in writing). The interviewer asks questions to explore different research topics.

You start by crafting an interview guide, which details what questions you want to ask your users. Your list of points to focus the research on gives you a starting point for formulating these questions. You can also check my user interview cheat sheet for some examples of questions.

The questions you ask should help you validate (or rather invalidate) your hypotheses and fill out the different parts of your map. Interviews are a good tool for asking users about emotions and pain points.

I tend to prefer semi-directed interviews. This means that that I have my set of questions, but that I don’t mind going off script. I recommend you plan some time for the off-script part. After all, it’s supposed to be a discussion with users, not an interrogation!

The image below shows some examples of interview questions and follow-up questions.

Just like surveys, interviews are a method that looks “easy enough”. After all, anyone can ask questions, right? Yet, interviews are a complicated exercise. While writing the script, researchers need to be aware of and avoid biases—which is a surprisingly complex task. Interviewers need to be actively listening and put users at ease. They also need to know how to ask follow-up questions, and how to encourage people to go deeper into another topic. But they also need to be able identify when they’ve gone too far off script, and how to bring the user back around to the research questions. It’s a craft that requires a lot of practice, trust me.

Finally, you need two people for the interview. One will conduct it and ask questions. The other one will take notes. This makes it feel more natural for both the interviewer and the interviewee. Check out my cheatsheet for user interview and follow-up questions to learn more about how to write interview questions and generally conduct interviews.

Observational Studies

Interview data is declarative. Users tell you what they do, how they react, and so on. This is nice for emotions. But human beings sometimes aren’t very good at recalling what they do or expressing their experience accurately. And people don’t always know what they need.

This is why I combine user interviews with user observation. Observation gives you another part of the puzzle. It provides a lot of information on activities and how people actually do tasks. It helps you fill in the steps in the map.

Observation takes different forms:

- Contextual inquiry: you go into the user’s environment and they show you how they do things. The participant explains to you what they’re doing, how they’re doing it, and so on. I used this approach before building the journey maps for the car dealership environments described in Chapters 1 and 2. This is particularly useful when the whole journey goes beyond a digital tool (an app or website).

- Usability testing: this method is often used to test a prototype of a future solution. You can also learn a lot of things by observing people using your current website, observing the tasks they perform and the steps they take. You can combine this with data from interviews conducted afterwards to get further insights into pain points, frustrations, goals, and motivations.

- Lab observation: you observe users in a lab, often from behind an observation room. Although it has its uses, you do lose a lot of important data about people’s natural environment in this kind of research.

The following image shows an observational study of a car dealership as part of research to better understand a user’s daily journeys.

While these methods help us gather a lot of data, they’re also quite time consuming. It can be complicated to organize specific environments where you need clearance or specific access. Contextual inquiry—where you must go to the user—can also be complicated in remote environments.

Diary Studies

Diary Studies let you gather data about user activities, tasks, and behavior over a period of time. They’re a useful tool for tracking user emotions and thoughts, and for getting details about user habits.

Participants are asked to track and log specific things over a certain period of time. At the end of the period, the researcher gets the logs back and analyzes them. The logs can include text, videos, photos, audio recordings, and so on. It all depends on what you’re researching.

The form of the diary depends on what your users are comfortable with. In my current job, we give beta testers an Excel spreadsheet. We ask them to log every time they can’t do something with the new interface that they used to be able do with the old one. This is the trigger for when they need to enter something in the diary (which we explain to the participants at the beginning of the study).

We go back to them after a month to get the spreadsheet, but in some diary studies, researchers review the information in real time. Timeframe and triggers depend on your research.

The image below shows some entries in a diary study of one user over the period of a month.

With this method, we again need to be careful about biases. This is declarative, self-reported data. Users might not report everything accurately. This method asks for a lot of user involvement. So the ratio between how many people start the study and how many complete it can be quite low sometimes. You’re more interested in quality than quantity here.

Conclusion

You now know how to prepare for your research, and how to gather data to build user journey maps. Researchers often mix different methods to get a broader picture. This means using a mix of quantitative and of qualitative research methods, which helps to compensate for the limits of each method.

If you want to dig further into user research, I recommend the following resources:

- Just Enough Research, a book on user research by Erika Hall.

- Interviewing for research: a pocket guide to design research, a book by Andrew Travers.

- UX Research Cheat Sheet from Nielsen Norman Group.

- Researching UX: User Research, a SitePoint book by James Lang and Emma Howell on user research.

- User Research Methods, by usability.gov, which still has some of the best resources around interviews and testing.

After following the guidance offered in the first three parts of this guide to creating user journey maps, you should have a lot of data to work with. What should you do with it now? The next chapter in this book will focus on analyzing all that data and building the actual map.

Chapter 4: How to Run Workshops

In Chapter 1 of this book, we looked at what user journey maps are and why they’re useful. In Chapter 2, we covered the different kinds of maps you could build. In Chapter 3, the focus was on user research: why it’s important to gather data to build your user journey maps, and what methods you can use for gathering that data.

Mixing both quantitative and qualitative methods provides a broader picture of user needs, goals and pain points. At this point, you’ve collected all the data you need—either by doing the research yourself, or by gathering previous research done by the company.

This fourth chapter in the book will focus on how to turn all that data into a first draft of your user journey map. For that, we’ll need some help from other people. We’ll see how to prepare, organize and run a user journey map workshop. At the end of the tutorial, I’ll also give you some alternative versions of that workshop—in case you want to build maps based on hypotheses, or future or disaster maps, or you want to take a more iterative approach, with people working on a first draft version of the map you’ve already prepared. As often with such tools, there’s no perfect “by the book” method. So don’t forget to adapt what you’re reading here to the specific structure of the company or team you’re working with.

A Collaborative Exercise Based on Data

As mentioned in previous tutorials, you don’t build a map on your own. You involve different departments and stakeholders in the research phase—people who have information about the journey and the user experience. You can also involve them in a workshop to build a first iteration of the map.

This exercise is as important as the map itself. The participation part helps everyone understand the global experience. This is especially important if you work in siloed companies, where departments don’t communicate with each other. This happens when employees don’t have the means (or desire) to communicate information and knowledge with other departments. People in such organizations work in isolation—and thus the silo metaphor. This often leads to inconsistencies in the whole journey.

Preparing for the Workshop

Like preparing for any workshop, you usually start by establishing some clear goals. In the case of user journey maps, this includes the scope of the map. It’s also good to establish from the start that it’s okay to not have the full map after one workshop. You might have an incomplete map, even with a lot of data about the users. This is going to be an iterative process that will get refined.

Prepare a few sentences to explain the expected outcomes of the workshop—what you’re trying to accomplish, and what the company can hope to gain from it. You can then attach those outcomes to the invitations sent out to participants.

Who to Invite?

Next, you need to work out who you want to invite. The basic rule of thumb is to invite people who have the knowledge you’ll need. Also, don’t invite the whole company: the more people who attend, the more complex it is to facilitate the event. It’s better to have multiple sessions with different people and iterate.

These are the people you should invite:

- Anyone who has knowledge of the experience at one point in the user journey—such as those involved in support, customer service, and marketing. Ask them to bring any research data they may have.

- Key stakeholders who take decisions that will impact user journeys and experience, as well as people who might influence decision making.

- Designers and people from product design teams, along with product owners, who can help them understand the global picture.

You can also invite users and customers to build the map. But if you do so, be aware of power dynamics with stakeholders. Never have more stakeholders than users in the room. You can read “Journey Mapping Workshops: Do You Have the Right Participants?” for more details on who to invite.

Preparing the Map Template

For the workshop, you need a map template. In my own workshops, I prepare this map template upfront before the workshop. For in-person workshops, you can use a whiteboard and trace it. You can also use a big roll of paper and put it on the wall, or print it on big paper sheets.

For remote digital workshops, you can use my Miro user journey map template, pictured below.

At the top of the map, I remind participants of who our user is (our persona) and the scope of the map.

I put on the left part of the map the elements I want to include. The elements on the left were discussed in previous tutorials. Here’s a summary of the things you can use:

- phases or key stages

- actions

- emotions

- pain points

- opportunities

- touch points and channels

The stages at the top of this list might be discussed during the workshop, so I don’t always prepare for them. I prepare some columns but leave the title empty.

Planning the Workshop, Supplies and Room

The next step is to plan the workshop.

Photo by Jason Goodman (Unplash)

Let’s start with in-person workshops. You need a room, the map template, sticky notes, sharpies, tape, and so on. Plan also to get snacks and drinks (water, coffee, tea). The goal is not to turn this into a party, but people tend to work better when they’re properly hydrated.

I like to have two sets of sticky notes: big ones for the stages at the top, and smaller ones to fill the rest of the map.

For remote workshops, you mostly need a video conference tool and a digital whiteboard. I prefer Miro, but you can go with Mural, Figma, or any tool your organization is used to. As long as it has digital sticky notes and people can collaborate in real time, it will do the job. For more tips on how to facilitate any remote workshops, check out my remote workshop facilitation tips.

Invite People to Participate

You then need to invite participants. I recommend scheduling around two hours (certainly no more than three) for a first workshop.

When inviting the participants, don’t forget to:

- tell them the agenda and the goal of the workshop

- explain why you invited them, and what type or data they need to bring (which might require sending custom invitations, depending on the people you’re inviting)

Launching the Workshop

At the beginning of the workshop, welcome all the participants and remind everyone of the goal of the workshop and agenda.

Presenting the User Research

If you’re conducting a workshop with people who aren’t part of the research team, present the key research findings. Try to not get lost in too many details, but just get straight to the point. You can also send them some of the findings before the workshop. But don’t expect everyone to have checked what you sent them. This helps people go beyond their own assumptions. You can bring artifacts like personas and empathy maps to help.

If you’re curious about user research for journey maps, refer back to Chapter 3 of this book and the SitePoint book Researching UX: User Research.

The picture below shows an example of an empathy map.

Another way to present the existing research is to turn the research presentation into an icebreaker. The format is up to you. But you could give participants some of the research key findings in a mini museum. Like in a real museum, you can display the main research findings on the walls of the workshop room, in the form of visual artifacts—such as infographics, videos, testimonials, handouts, and so on. Then people can go through it, just as in a museum, to get a better understanding of the findings from previous research. You can also do this remotely and have the artifacts displayed in a virtual whiteboard. Ask people to take a look, discuss and interact with the material in a small group to kickstart the workshop.

Presenting the User and Journey Scope

While presenting the research, you’ll have introduced the user. The next step is to fill out the scope of the journey you’re mapping for that user, so that everyone’s clear what the map will include. Will you map the whole travel journey? Will this focus on just a part of the journey? The bigger the scope, the more steps and phases, and the longer the workshop will take. Ideally, you’ll have planned your timing based on this. So, this is a reminder for participants.

Using Existing Research to Fill Out the Map

The next stage in the workshop is to start filling out the map with the research data you currently have.

Starting with the Journey Phases

Once you’ve established the user and the scope of the journey, it’s time to fill out the phases. I explained above that I leave those empty in the template. Ask participants to define the phases of the journey based on the research you’ve brought together and/or the data they have from their own user research.

Here are some tips for doing this:

- It’s easier to go left to right, phase by phase, step by step.

- For the phases, I usually use a big sticky note for a phase name, then a small one for a short description (in case we forget what that phase was about).

- It’s sometimes easier to start with the goal (the end of the map), and then work your way backwards.

- It’s okay if you need to move phases around if you need to add a phase between two other ones. This is why we use sticky notes.

Narrowing It Down: Filling in the Columns

Once you’ve established the main user journey phases, it’s time to fill in the columns. Firstly, though, you need to explain what you expect in each row. Go through the template (physical or digital) and explain each row—the action, pain points, emotions, touch points, channels, and so on. People usually understand things better when you give them an example. So, while going through each row, you can already fill in the first column with sticky notes to show participants what you expect.

The map is often filled left to right, column by column. Tell people to use sticky notes for more flexibility. This way, they can move them around if needed. Reference the research and data to help inform the decisions and what you’ll put on the map. The goal is to put people in the user’s shoes, thanks to the research data.

For now, I would leave the opportunity/solution/improvement part blank. I think it’s better to have a full view of the map to brainstorm those. But it’s up to you.

If you have a small group, you can fill in all the columns together. With bigger groups, you can do two things:

- Give each group a column to fill. If possible, have a designer or research person with each group as referral. Then bring everyone together and let them present their columns. Have the other people give feedback and fill in the blanks.

- If you don’t have too many phases, you can also ask people to fill the whole map in smaller groups. Note that bringing it all together for a synthesis then might take a lot of time. In this case, I would collect the maps and do the synthesis with the research team—outside of workshop time.

And here’s an extra pro tip: have a “garage” place for ideas and things that don’t fit in the map but that are worth capturing nevertheless. Those might be helpful for another map or for another process, for example.

Discussing Opportunities and Improvements

Once you have an overview of the whole journey, you can start to discuss opportunities for improvements. If your map is big, this could be a workshop on its own. So the goal at this stage—in this workshop—isn’t to take any decisions yet, but to brainstorm some first ideas for solutions and improvements. Write them down on the sticky notes. (We’ll come back to what to do with them in Chapter 5.)

The image below shows a map with the opportunities and touchpoints filled in.

Thanking Participants

At the end of the workshop, thank everyone for their time and contributions. Explain that you’ll now use the results as a base to build a visual map (covered in the next tutorial) and follow up with them later. Don’t lose the momentum, though. You can send an email after the workshop with a small summary of the main findings—perhaps along with a copy of the draft attached. Just make it clear that it’s a work in progress.

It’s an Iterative Exercise

As mentioned before, the first draft of the map isn’t going to be perfect. It’s an iterative exercise. If there are things that aren’t clear, or that you haven’t covered yet, they need more research. Add hypotheses for these items that will be followed up later.

Don’t jump into visualization just yet, but do double check that the results of the map match the research data you gathered.

Alternative Versions of the Workshop

I described here how the workshop can go when you have data. Let’s see a few variants that you could facilitate as well.

Workshops Based on Hypotheses, or for Future or Disaster Maps

I highly recommend that you do your research first. But if you’re going to build a hypothetical discovery map (covered in Chapter 2), the workshop process can be the same. The difference is that everything you put on those sticky notes is a hypothesis to verify.

If you’re building a disaster map, your workshop will brainstorm what might happen, in order to avoid future disasters. If you’re building a future map, you’ll brainstorm what the future experience might look like.

For both these two types of map, you can make up a part of the map based on actual data as well as on hypotheses.

Iterative “Filling the Blanks” Workshops

In the workshop model covered in this tutorial, participants start from scratch. An alternative version would be to have them work on a first draft of the map and fill in the blanks.

In this version, the research and design team build a first version of the map on their own. That version is based on all the user data collected so far.

Then, you invite different stakeholders to do the following:

- check the map and see if this aligns with their data or experiences with the users

- help fill in some missing parts of the map, such as touchpoints, channels, and so on

Ask these stakeholders to add sticky notes where they think the research and design team have missed something. It’s even better if the design team has already identified areas where they think there are gaps.

With this approach, you can have shorter workshops (around an hour) with smaller groups. You then iterate until you have all the information needed from all departments. You can also have a session with actual users or customers and present them the map, then gather feedback on the gaps between the map and their experience.

The drawback with this approach is that you might not be able to build up sufficient momentum, especially when people aren’t starting from scratch.

Analysis and Opportunities Workshops

Yet another approach to workshopping is to prepare the map with the design team, then bring that map to a workshop with stakeholders so they can analyze it. The goal then is to help stakeholders understand the global picture, but also to find opportunities for improvements together and then map them.

Conclusion

After one or more of the workshops described above, you have a draft of a user journey map. It’s full of sticky notes and not pretty at this stage. But it’s a starting point to build on. The most important part is the map, but the whole process is important too. As the saying goes, “the journey is as important as the destination”. In this case, bringing data to the exercise usually helps stakeholders go beyond their assumptions—which is often a step in the right direction when you want to build more user-centered products and services.

Ultimately, what I’ve presented here are just some of the ways to go about workshopping user journey maps. There are as many workshops as designers. Use these suggestions as a base for building on, and don’t forget to adapt them to your own design environment. The important thing is not to overlook the workshopping phase entirely. It’s a very important step.

You now have a draft of a map. Congratulations! In the final part, we’ll see how to clean up that map and turn it into a visual artifact that will truly advocate for users. We’ll also consider how to put it to good use and not let it end up as just another deliverable lost in a dusty folder.

Chapter 5: Using Your Map Effectively

In the previous chapters in this book, we looked at what user journey maps are, what types of maps you can build, how to conduct user research to get data to build your own user journey map, and how to build a draft version of the map during a collaborative workshop. Our journey (pun intended) is nearing its end.

Let’s be realistic: you can’t go to stakeholders with a draft of a map built on a wall with sticky notes. To have an impact in a company, and for your map to be used, you need something visually appealing. In this last part, I’ll give you some advice on how to clean up your map and turn it into a visual artifact that people will want to use and share. I’ll give you some examples and ideas on how to use that map to drive more user-centered product decisions—whether they involve quality assurance, building and sharing a vision for the product, or working out which features to prioritize next.

Cleaning Up the Map and Turning It into a Visual Artifact

Once you finish the workshops, you end up with a draft version of the map. It can be a paper version with sticky notes, or a digital version on online whiteboards. This isn’t a document you can share as is. The next step is to turn all those sticky notes and insights into some sort of visual infographic. The ultimate goal is to share it—maybe even to display it somewhere in the office.

You’ll need the help of a visual designer here if you don’t have the skills required. There’s no perfect way to draw the final version. But here are some tips:

- Keep it simple and focused. The goal is to avoid yet another big, overwhelming, 150-page PDF no one will read.

- Avoid jargon if you want everyone in the company to understand it.

- Be careful with color contrast and font size, making sure it’s readable.

- Make sure the steps and stages are recognizable.

- If your map becomes super big, you could split it into smaller ones to make it more digestible.

- Try to make the map match the company’s brand guidelines. This way, it will look more official when people see and share it.

If you don’t have visual designers to help, you could use some templates like the ones on UXPressia. They also have great content on how to make journey maps visual.

The image below shows an example of a cleaned-up map built with the UXPressia ecommerce journey template.

Share It with Your Teams

Now that you have a final version of that map, it’s time to share it with your teams. The first people you should send it to are the people who participated in the workshop. This can be an email follow-up, of course. Do people really read emails and check attachments? It depends on the people and companies.

If you want to keep the momentum, you can prepare a small presentation of the map and of the things you discovered during the research. It can be a face-to-face, small presentation meeting or a meeting held remotely. You can also prepare a short, five-minute video (with subtitles) to present the map. Later, present the findings that people can share. Keep it short and simple. Then share the link to that small video as much as possible, across as many channels as possible in the company. Don’t forget to attach a digital version of the map to any of those communications.

If you are co-located in the same office, you can also display the map on the wall. This will foster curiosity from people who aren’t aware of the research. It also helps to keep the momentum. Try to make it as visible as possible. In a previous company I worked for, we had a version of the map as a big rollup. It was a vertical version, but seeing it in the office helped encourage people to refer to it more often.

The tactic of displaying the map on the wall is more tricky if you work remotely. In that case, again, the small video can help. I also like to attach the map in Jira in our epics. Jira epics are often used to group together stories on the same topic. Often, those topics are features, or smaller journeys in your products.

The best way to share the map depends on your specific company setup. Don’t be afraid to be creative and use all the communication tools you can think of.

Using Maps to Drive More User-centered Products and Decisions

You’ve shared the map. Congratulations! Let’s see a few examples of how to use it to build more user-centered products.

Quality Assurance and Product Evaluation

When you build user journey maps using real user data, you’ll uncover hidden truths about your users. Then you can build better products by addressing those hidden truths—instead of relying on all the guesswork we often see in some meetings.

User journey maps can then help with quality assurance, to check if teams are building the right thing, and if the product is going in the right direction. How is this feature going to fit into this global picture? In what phase of the journey? What user problem does this actually solve? Bring the journey map to strategic and decision meetings and use it as a support for quality assurance, and to evaluate if what you’re planning to build (or have already built) provides what users actually need.

A fellow designer once said this to me:

If there’s no journey map for that particular project, I know there’s a good chance no user research was done.

User journey maps are a visual way to present research results. If a company has no map, it’s possible no research has been done on that topic. Without research, a company is flying blind, without real quality control. User research is important for evaluating products and their features, and what parts of the product don’t match what users expect or need.

Bringing User Data to an Opinion Fight

I interviewed Geoffrey Crofte, lead designer at Foyer Group (an insurance company). In his job, he uses user journey maps when he needs to bring data to an opinion fight:

We have our journey maps in digital tools (Mural, Miro). We display them when there are debates based on people’s personal assumptions. This practice has helped advocate for the user during those debates. And it’s a good way to showcase the user research we built at some points—because bringing solutions on the table is sometimes not the best solution.

The image below shows an example of a map built by Geoffrey for one of his projects.

When there’s a debate occurring based on opinions, a user journey map helps to bring real data into the discussion. Showing all your user research takes time, but a user journey map is a visual tool that summarizes all of that research. Bringing a journey map to a meeting—or to other situations where you need to build awareness around what users need—helps the stakeholders and team understand how users use the product and services in reality, and thus stops the arguments based on opinions.

Identifying Pain Points and Processing Issues to Solve

Another benefit of user journey maps is to help teams identify pain points and to share a more common global vision. Companies are often siloed for various reasons. Building such maps forces people to go beyond those silos, and it helps them understand the entire process, with all the touchpoints and channels.

As Geoffrey puts it:

Journey maps help expose the existing mess in a current process, so we can then tackle down the main pain points. It brings a better visibility to stakeholders when we work on complex processes. We have many user journey maps for internal processes.

This is why you want to share those maps with as many people as possible, across as many channels as possible. Maps become a great support for cross-channel meetings and problem solving. You can also use user journey maps as a base for brainstorming workshops on how you might solve some of those user pain points. It’s way easier to solve those when you see exactly where they are in the global process so you know whose channel should be responsible, and what you need to change or update to solve the problem.

Example: a Notification Delay

In one of my projects, we discovered during the research (and showed in the map) that there was a delay issue. Users had to create a “validation task”. The server sent email notifications for those twice a day. If you created a task just after the server sent that notification, there was a four-hour delay before the next one. This was a bit annoying when you needed people to validate something quickly. We identified this by talking to users. We put that in the current journey map as a big pain point.

The image below clearly shows a large pain point in the user journey.

Thanks to the research, we were able to avoid making the same mistake in the mobile app we built for the task manager. On mobile, the notifications were sent instantly. You might think, “Well, this was obvious. Why would you even think to send notifications only twice a day?” I guess it was due to technical constraints when this was built ten years ago, and no one had changed it since—and because no one took the time to talk to users and understand their global journey.

Sharing a Vision and Planning a Roadmap Priority

Another way to use user maps is as a base for vision and roadmap alignment. Honestly, any user research data helps with that. But stakeholders don’t have the time to go through the research. Bringing a visual map to priority and strategic meetings can help to do the following:

- Bring everyone on the same page on the current experience.

- Build and share a vision of what we want to build and where we want to go (future maps).

- Take decisions regarding roadmap priorities. It helps answer questions like, “Is this a feature that’s going to solve a big user pain point? Where in the whole experience?” … and so on.

It also shows areas where there’s a need for further research—if you’re going to develop that part of the product.

Design and Research Knowledge Sharing Tool

When I first got involved in a recent project, people gave me 300 pages of PDFs to read to “help” me get up to speed. What actually helped me? While scanning them, I discovered a first attempt at a journey map in one of those PDFs. This map alone helped me understand so much more about the business and its customers than any long and complex written text.

User journey maps are a great tool for sharing the research knowledge—both with other teams, but also with future members of that team. It helps onboard new designers, researchers, or others joining the team, enabling them to understand the whole journey and get an overview of the experience the rest of the team already has, quickly getting them up to speed.

Deciding on the Next Points to Improve and Actions to Take

Once you’ve used the user journey map to align people involved in a project, identified pain points and brainstormed solutions, it’s time to prioritize. Unless you have an unlimited budget and resources, you can’t fix and improve everything at once. You and your team must decide what actions to take first.

Prioritizing the next actions often involves asking questions like these:

- How much is it going to cost?

- How much time is it going to take?

- Who’s responsible for this?

- Do we have the resources and tools or do we need to invest?

There are many techniques and tools that can help you prioritize. You could check “7 Techniques for Prioritizing Customer Requirements” for more information on that topic. Again, bring the map to discussions around priorities to help participants focus on user data and user needs.

You might also need to rework some services, touchpoints and infrastructure. This is where the touchpoints and channels of the map will help. Now you know exactly what department is impacted, so you can plan accordingly.

Example: a Priority Matrix

One way to decide on next steps is to build a priority matrix. The criteria depend on your project. In one of my recent projects, we had four criteria:

- user benefits (how many people this is going to benefit)

- business value (how much this is going to benefit the business)

- design and/or research costs

- development costs

We had a four-column Excel sheet. We set up a meeting with different project stakeholders. We went through the next improvements we wanted to carry out. People responsible for each area gave points for the four columns. This resulted in a four-quadrant matrix. What we then worked on as a priority was what we called the quick wins: high user and business value, and low cost. It was the top-left part of the quadrant.

The image below shows an example of our priority matrix on the left and an abstract version of such a map.

Keeping the Map Up to Date

A user journey map isn’t a static document that you build once and then leave untouched. There’s actually no end to that journey. Once you’ve improved your services and fixed some pain points, you’ve changed the experience. So you then need to update the map. If you’ve built new features, and/or reorganized some touchpoints or services, again, you need to update the map.

This is a good thing. It means your product is evolving in the right direction. So don’t forget to schedule some time at some point to re-evaluate and update your maps. Consider them living documents that will continue to grow and develop.

Conclusion

The user journey map is a powerful tool for helping to build more user-centric products and services. It helps you make decisions and grow products in the right direction. It’s a visual way to show user research data to the whole company.

The visual part of the final artifact is important. That’s a fact. But so is the whole process involved in building it. From user research to getting teams to collaborate and learn together about user needs—all this contributes to bridging across silos and building a more user-centered culture in the company.

At the end of the day, user journey maps don’t have to be perfect, as long as they serve their purpose. After all, it’s about the journey!

Table of Contents

User Journey Mapping: Visualize User Research, Brainstorm Opportunities, and Solve Problems

Notice of Rights

Notice of Liability

Trademark Notice

About SitePoint

About the Author

Preface

Who Should Read This Book?

Conventions Used

Code Samples

Tips, Notes, and Warnings

Supplementary Materials

Chapter 1: An Introduction to User Journey Maps: What They Are, and What They’re Useful For

What Is a User Journey Map?

Alternative Names

What to Include in a User Journey Map

The Utility of a User Journey Map: a Real-world Example

The benefits of User Journey Maps

Potential User Journey Map Pitfalls

Conclusion

Chapter 2: The Different Types of Maps and How to Use Them

The Current or As-is Journey Map

Hypothetical Discovery Map

(Desired) Future Journey Map

Disaster User Journey Maps

Other Useful Types of Maps

Task Analysis Maps

Process Maps

Service Blueprints

Conclusion

Chapter 3: Conducting User Research

What to Focus User Research On

Preparing for Research

Conduct Stakeholder Interviews to Define Objectives

Is There Any Data Already Available?

Prepare a Research Plan with Scope and Target Audience

Timeline, Budget and Resources

Indirect Quantitative Data Gathering Methods

Website Analytics Data

Session Replays

On Using Surveys for Research

Qualitative and Direct Research Methods

User Interviews

Observational Studies

Diary Studies

Conclusion

Chapter 4: How to Run Workshops

A Collaborative Exercise Based on Data

Preparing for the Workshop

Who to Invite?

Preparing the Map Template

Planning the Workshop, Supplies and Room

Invite People to Participate

Launching the Workshop

Presenting the User Research

Presenting the User and Journey Scope

Using Existing Research to Fill Out the Map

Starting with the Journey Phases

Narrowing It Down: Filling in the Columns

Discussing Opportunities and Improvements

Thanking Participants

It’s an Iterative Exercise

Alternative Versions of the Workshop

Workshops Based on Hypotheses, or for Future or Disaster Maps

Iterative “Filling the Blanks” Workshops

Analysis and Opportunities Workshops

Conclusion

Chapter 5: Using Your Map Effectively

Cleaning Up the Map and Turning It into a Visual Artifact

Share It with Your Teams

Using Maps to Drive More User-centered Products and Decisions

Quality Assurance and Product Evaluation

Bringing User Data to an Opinion Fight

Identifying Pain Points and Processing Issues to Solve

Example: a Notification Delay

Sharing a Vision and Planning a Roadmap Priority

Design and Research Knowledge Sharing Tool

Deciding on the Next Points to Improve and Actions to Take

Example: a Priority Matrix

Keeping the Map Up to Date

Conclusion