Customer Journey Maps

I wanted to just spend a little bit of time on the *user journey*. So, we can see how important user research is to creating really compelling value propositions and creating value for organizations that are trying to use service design to innovate, improve, streamline and smooth out. Well, there's nothing better to tackle that with than the user journey.

I wanted to just spend a little bit of time on this technique in case you didn't have that much experience with it or maybe you were doing journeys in a way that was different to the way I'm going to present to you. At least, I just wanted to share a template with you that can give you better access to what you're looking for. For me, now, a journey is something that you *build on*. So, first off it's your *customer journey*.

And on that is your service blueprint. And remember that the journey is going to reveal those cross-channel like, say, *breakpoints*, *pain points*, *disconnects* that you can map in the different *swim lane diagrams* – is the official term for a journey map. So, it comes from that – these swim lanes. And so, you'll have like maybe your channels here – you know – you'll have your user tasks here, pains and gains, or you can just have positive (+) or negative (-).

And I tend to change my user journeys, try and improve them, try and improve them. One of the problems that I find with journey maps – and they became very popular, I think around 2010, maybe, was the heyday of user journeys – 2010 / 2012, maybe. It was all about this beautiful big visualization. Let's be clear: A customer journey map is *not* about impressing your team

with really cool, big swim diagram visualizations with tons of little icons. It's a document like all deliverables in a human-centered design perspective. It should work for the internal teams that are using it as a decision-making document *as well*. The thing about the journey map that's particularly of value to the service designer is that it's happening across time

or across stages or across goals. So, the stages of, say, the life cycle – you know – you might have Research, Compare, Purchase, then the Return shopping. In other words, it's not just the purchase. A lot of conversion optimization and approaches to selling online just focus on this part here: the compare and purchase, or the funnel – if you will – the purchase funnel. And I think it's important to have the acquisition as much as the retention.

This is the conversion here. So, these two steps are the conversion steps. It's important to have *all* those steps represented. *Happy / sad moments* – you can have a little smiley face; *disconnects and breaks* – you know – so that you're like: "Ah! This is a break right here. They're on their phone, and they're researching, but the site's not responsive or it's *partially* responsive. And then, compare – when they go to compare, it only allows three items. So, it's like "Ohh!" – and then we have a quote from the user going:

"Why does this only allow (imitated mumbling)?!" – you know – something communicating the pain point. The other thing it's going to have is your reflections from your ethnography, from your personas. It's going to have those real-world contexts, basically. Instead of basically making it up and doing it internally, you're going to base it on user data. You'll also want to have *recommendations*. So, down here at the bottom you can have a list of recommendations

as well. This is an example of a journey map we created. And you can see the touch points we've added along the way. So, we have these different stages. We've got this – as the user walks through. So, we have Pre-apply, Apply, Post-apply. This is an online application journey. And we have the various channels that are occurring there. We've got the pain points represented. And the steps are:

Discover, Research, Apply, Manage and Dream. Discover was important because a lot of people didn't know that the offers were there. This is for getting an account. And basically the value proposition is you're going to have these offers – targeted offers – sent to you. So, the key is to find out how people are currently applying and at what stage makes sense to offer them these upsells, basically. And that's the value add that's being offered here.

This is a map of Brown County State Park  in Indiana, in the USA. You're looking at a visual of 16,000 acres of hills,  ridges, roads and trails. It puts those all right in your pocket. It helps you to know where you are and where to go next. So, everyone with a map has a similar  understanding of how to get around. This is a map of the New York Subway system: 5,000 square miles of rail lines and schedules.

But it's simplified, visual. That's really useful. And this is a customer journey map for an IxDF design bootcamp – a visual simplification of six weeks of experiences, lessons and projects. Now, each one of these shows the power of maps. They simplify a complex space, create shared understanding. They show us patterns. They help us to arrive at a destination together.

So, if a screen mock-up is a house plan, then think of a journey map like something that shows the *path* that a  person takes *through* that house and *beyond*.

In this presentation, we look at how user research fits into your design process and when to do different types of user studies. If you decide to invest time in doing user research, it's important that you time it so that you get as much out of your efforts as possible. Here, we look at when you should do different types of user research and how research fits into the different work processes.

Before you can decide when to do user research, you have to clarify *why* you're doing user research. You need different kinds of insights at different times in your design process. Let's have a look at the overall reasons for doing user research. You can do user research to ensure that you have a good understanding of your users; what their everyday life looks like; what motivates them, and so on. If you understand the people who use your product, you can make designs that are relevant for them. This type of research is typically *qualitative interviews and observations*.

You can also do tests of the user experience to ensure that your design has a high level of usability. Finally, you can evaluate on the impact of your design – for instance, on the number of customers or efficiency of work processes. As you can probably see, the different types of research fit into the design process in different ways. Let's start by looking at how each type of research fits into a simplified timeline for product development. Afterwards, we'll look into how user research fits into different types of development processes.

Research to ensure that your design is relevant to your users will typically be interviews and observations at the user's home or another relevant context. Since research to ensure that you create relevant products is meant to influence what type of product you will develop, most of this research takes place at the *start* of the development process, either *concurrently* with ideation work or *before* any concept work is done. You can also do research to validate your design direction, once you've developed some concept ideas

that you can show prospective users or during early product development. After release, you can do the same type of research to understand how customers are using your product, to explore if they need other features or offer opportunity scoping for your next project. And that, of course, leads you back to the beginning of your next product development process. Research to ensure that your designs are easy to use is mostly done as usability tests. It's important to start usability testing as early in the design or development process as possible

so that you have time to make changes to your design if the tests show that changing the design will benefit the product. If you use paper prototypes or similar materials, you can do early user testing before you have an interactive interface. User testing works well in an iterative process where you continually do user tests to ensure that your design is easy and pleasurable to use. Finally, research to measure the impact of your design mostly takes place *after* your product is released. The studies can then lead to new development and design changes.

If you're working on web-based products such as apps and web pages, it makes sense to keep evaluating on the user experience after your first release. One thing is a simplified timeline, but when you can do user research and how much research you can do really depends on what type of development process you work in. You can fit user research into most work processes depending on how ambitious you are. But it's easier in some work processes than in others. Let's take a look at what a work process that's optimized for user research looks like.

*User-centered design* is an overall term for work processes that place the needs and abilities of the user at the center of the development process. It's been described in different terms, but overall it's an iterative process where the first step is *user research* to ensure the relevance of the product. The second step is to *define* concepts based on user insights. The third step is *design and development*. And the fourth step is *user-testing the solution*. Ideally, this iterative process continues until evaluations show that the product is ready to be released.

After release, evaluations of the customer experience might lead to further development. By the way, design thinking is one of the most well-known user-centered work processes. As you can see, the steps involved in design thinking are almost identical to the overall steps of the user-centered design process. When you work in a user-centered process, user research is an integrated part of that process. But, in reality, many work processes are either not like that or deviate from the basic process in different ways.

So, how do you approach user research if you don't work in a clear-cut user-centered process? If research is not an integrated part of your work process and it's not up to you to change the way of working, you can still do user research, but it's up to you to decide when and how. So, let's look at some rules of thumb for deciding if, when and how to do user research. The sooner in your process you can do research, the bigger the impact of your research will be.

If you can do research before development starts, you can help ensure that you work on products that are relevant to your users. If you can do research early in development, you have more time to make changes to ensure great user experience before your product is released, and so on. Sometimes, you work in projects where you're not involved in all phases of the development. But you can still do smaller research projects that influence the part of the project you *are* working on. If you're a UX designer who's not involved in early concept development, it still makes a lot of sense to do *iterative user testing* of your designs.

If you don't have a process for how to handle research results, you should stick to research where you also have influence on any design changes that your research brings about. If you *are* involved in planning your development process, make sure that you schedule in some time to do user research. That way, you can be *proactive* with your research rather than reactive, so you don't have to scramble for resources when you suddenly need research to support your design decisions.

Sometimes, you don't have the resources to do all the user research you'd like to do. In that case, think about which type of research will have the *biggest impact* on your particular project and prioritize doing those studies. If you have influence over how you plan your development, iterative processes are almost always preferable when it comes to getting the most out of your user research. Iterative processes make you open to changing the end goal of your design based on the results of your user research.

In many projects, your time and resources to do user research are scarce. Luckily, you can do a lot with a little. You can, for instance, do user tests with paper prototypes rather than with fully interactive prototypes that require software programming. Just remember that the *validity* of your research is always the most important thing. So, if your time and resources for doing research are so limited that your results won't be sensible, it's better *not* to do any research. Best case = you'll waste your time and nothing comes from it.

Worst case = insights that don't really represent the user will impact important design decisions. Similarly, if you're working on a project that could benefit from user insights but you don't have the time or resources to make any design changes based on your research, you should save your research efforts for another time when they make more sense. So, what's the take-away? User research fits into the development process on all stages, depending on why you want to do user research. When you should do research, and what type of research you can do, depends on what your work process looks like.

If you work in a user-centered design process, user research is an integrated part of the process. If you *don't* work in a user-centered design process, it's up to you to make smart decisions about when and how to do research.

We have tendencies to see things in one way or another. And that's about all sorts of things. That can be about serious personal issues; it can be about trivial things. Often the way in which *something is framed to us can actually create a bias* as well. A classic example, and there are various ways you can do this, is what's called *anchoring*. So, if we're asked something and given something that *suggests a value*,

even if it's told that it's just there for guesswork purposes or something, it tends to hold us and move where we see our estimate. So, you ask somebody, "How high is the Eiffel Tower?" You might have a vague idea that it's big, but you probably don't know exactly how high. You might ask one set of people and give them a scale and say, "Put it on this scale; just draw a cross where you think on this scale from 250 meters high to 2,500 meters high.

How high on that scale?" And people put crosses on the scale – you can see where they were, or put a number. But alternatively, you might give people – instead of having a scale of 250 meters to 2,500 meters, you might give them a scale between 50 meters and 500 meters. Now, actually, the Eiffel Tower falls on *both* of those scales; the actual height is around 300 meters. But what you find is people don't know the answer; given the larger, higher scale, they will tend to put something that is larger and higher,

even though they're told it's just a scale. And actually, on the larger scale, it should be right at the bottom. Here, it should be about two-thirds of the way up the scale. But what happens is you, by framing it with big numbers, people tend to guess a bigger number. If you frame it with smaller numbers,  people guess a smaller number. They're anchored by the nature of the way the question is posed. So, how might you get away from some of this fixation? We'll talk about some other things later,

other ways later. But one of the ways to actually *break* some of this bias and this fixation is to *deliberately mix things up*. So, what you might do is, say, you're given the problem of *building* the Eiffel Tower. And the Eiffel Tower I said is about 300 meters tall, so about 1,000 feet tall. So, you might think, "Oh crumbs, how are we going to build this?" So, one thing you might do is say, "Imagine instead of being

300 meters tall, it was just 3 meters tall. How would I go about building it, then?" And you might think, "Well, I'd build a big, perhaps a scaffolding, or 30 meters tall – I might build a scaffolding and just hoist things up to the top." So, then you say, "Well, OK, can I build a scaffolding at 300 meters; does that make sense?" Alternatively, you might say, "Perhaps it's 300,000 *miles* tall, basically reaching as high as the Moon. How might I build it, then?" Well, there's no way you're going to hoist things up a scaffold.

All the workers at the top would have no oxygen because they'd be up above the atmosphere. So, you might then think about hoisting it up from the bottom, building the top first, hoisting the whole thing up; building the  next layer; hoisting the whole thing up; building the next layer – you know – like jacking a car and then sticking bits underneath. So, by just thinking of a *completely different* scale, you start to think of different kinds of solutions. It forces you out of that fixation. You might just swap things around. I mean, this works quite well if you're worried

that you're using some sort of racial or gender bias; you just swap the genders of the people involved in the story or swap their ethnic background, and often the way you look at the story differently might tell you something about some of the biases you bring to it. In politics, if you hear a statement from a  politician and you either react positively or negatively to it, it might be worth just thinking what you'd imagine if that statement

came from the mouth of another politician, that was of a different persuasion; how would you read it then? And it's not that you change your views  drastically by doing this, but it helps you to perhaps expose why you view these things differently. And some of that might be valid reasons; sometimes, you might think, "Actually, I need to rethink some of the ways I'm working."

When you design a user interface, skills like visual design, user testing and prototyping are critical. But when you design a complex experience like a buying process, an onboarding sequence, really anything that includes multiple steps over time. Journey mapping is an essential tool. This course will teach you how to use journey mapping in your own work to design holistically and also to identify gaps and opportunities in complex products. It will also help you streamline your team's design efforts.

You'll begin by learning about the power of journey, mapping and design and the different variations that you can use. We'll also cover how to gather data in your journey mapping process and how to make sense of it using a perspective grid. There'll be practical tips on how to create different types of journey maps and how to set up and run a journey mapping workshop by the end of this course. You'll have the knowledge, methods and hands on practice. You'll need to use journey mapping in your own work. The course also includes several downloadable templates

that'll give you a jumpstart in your own journey mapping projects at the end of each lesson. There are multiple choice and open ended questions that are graded personal by industry experts. You'll also have the option to create a practical design project. This will give you invaluable hands on experience that you can add to your portfolio at the end of the course. You'll gain an industry recognized course certificate which is trusted by leading companies around the world, and that will make a great addition to your LinkedIn profile or your design portfolio.

So are you ready?