The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #186 Chris Risdon - Mapping the User Experience

October 19, 2012  ·  34 minutes

Listen Now

Download the MP3

In the current multi-device, interconnected landscape, a user can interact with your product or service from a variety of touchpoints. At each, you must address the user’s needs at a particular place and time. Those needs will be determined by where they are in the experience.

Show Notes

Chris Risdon, of Adaptive Path, stresses the importance of mapping the user experience, not only for the physical artifact, but for the level of collaboration it brings to the organization. In his virtual seminar, Mapping the User Experience, Chris explains how the experience map can reach all areas of a company, from digital to physical properties.

Chris ran short of time to answer all of the great questions from our audience during the live seminar. He joins Adam Churchill for this podcast, revisiting the questions from our audience.

  • How do you distinguish touchpoints from tasks?
  • How do you put the map into use?
  • How do you make the most of stakeholders’ time during the design process?
  • Where do personas intersect with experience mapping?
  • Are scenarios different from actions on the experience map?
  • Is experience mapping just for existing products and services?
  • Does it makes sense to have different maps for different types of users?
  • Do the maps evolve over time?
  • Is there value to segmenting the experience map?
  • How do you capture touchpoints for a product with an array of features?

Full Transcript

Adam Churchill: Hello, everyone. Welcome to another edition of the SpoolCast. Recently, Chris Risdon joined us for his virtual seminar, "Mapping the User Experience." Now, in this seminar, Chris showed us that experience maps offer a framework to gain insight about customers' interactions with your product or service.

The seminar was great, and it happened to be our 100th. Now, like all the rest, it's been added to UIE's User Experience Training Library. That library's loaded with recorded seminars from wonderful topic experts just like Chris, giving you the tips and techniques you need to create great design.

Hey, Chris. Welcome back.
Chris Risdon: Thank you very much. I appreciate it.
Adam: Now, for those that weren't with us for the presentation, can you give us an overview?
Chris: Yeah, absolutely. I tried to mix a little bit of theory and practice in this presentation. I tried to cover five areas around mapping the user experience. The first one was try to define what mapping the experience is, and that's basically defining what this method is in contrast to other methods that we have been talking a lot about, such as service blueprints, touch-point matrices.

We're finding that there's a whole slew of new methods as we, as user experience designers, go from thinking about digital products to thinking about things that are more like services.

What is experience mapping in the world of other tools and methods we have? And then, what are the principles of experience mapping? That's really the principles of engaging with people over time and space and telling their stories.

Then the second area I covered was, I called it "science before adventure," and that's mostly understanding what sets up a good experience-mapping activity. What are the key inputs and insights you need to gather? That's the rigor you need to do with regards to both qualitative and quantitative research.

We talked about both the things that probably are fairly similar to any other user experience project where you're getting qualitative research -- ethnography, contextual inquiry. And as well as the value, that real quantitative data, whether it's just simple web traffic analysis or survey results, all the types of things that will actually feed into the experience map, the ingredients, so to speak.

And then, third, I called it Cartography 101, which is really understanding what the activity of mapping the experience looks like. Not just creating the artifact, but the collaborative activity within the organization of starting to what I called orchestrate touch points, orchestrate and understand what all the different interaction points between a company and the customer, the user, are happening.

It's a framework for mapping the experiences across these situations and these interactions in a collaborative way, in a way that you can move things around. Whether that's using something editable like an Excel spreadsheet or using Post-it notes on the wall, which a lot of us designers love to do, it's what the actual activity looks like.

Fourth, I tried to go into storytelling and narrative, which is really what we're going to try to articulate in the actual artifact, and that's the techniques for visualizing the experience maps to actually communicate the insight that we gained in the first couple steps.

It's a little bit putting our data visualization hats on. It's like, what are the ways that we can use layered data, layered information, such as when something occurred, where it occurred, who was involved, and actually tell an engaging story with this through the way we visualize that story?

And then, fifth, I called it have map, will travel. That's basically, once we have the map, what do we do with it? And so, I covered a range of ways that you would want to use a map. What I really emphasized was you should understand how you want to use an experience map, how you want to use this story of a customer's journey, before you even start the activity.

It can be a catalyst for something that you already know you want to do. But that usually falls within three areas. One is organizationally. You can use an experience map. You can use understanding this full customer journey, to understand how you should organize your resources or what type of skill sets you're going to need.

The second way is to do it for strategic initiatives. You can plan out what types of projects or programs you should be doing based on understanding and prioritize what's happening over the journey.

And, the third way, you can use the map is more tactically. You can actually, based on understanding the contexts of different touch points of the different areas that your customer comes in contact with you, pull out design principles and actual things that will feed into the design of features or supporting user stories in an Agile environment.

These five things created an overall framework for how we go about creating an experience map, but with the real goal of knowing that it isn't about the artifact itself. I call it...It's about the verb, not the noun. I try to set it up so that we can see all the things that are involved. We don't just create an artifact in our own room as designers by ourselves, but we're getting all the right people involved, it's informed and credible with all the right information, and then, once it's done, we know how to use it in the end.

That was basically what I went over in the seminar.
Adam: Now, in the first section, Chris, there was a lot of discussion on touch points. Chris had a question. She wanted to know if you could distinguish between tasks and touch points.
Chris: Yeah, absolutely. There's a little mix of a number of things. There's tasks, there's touch points, there's user stories, and there's features, and it's hard to distinguish when to use what. The tasks and touch points are almost the same thing.

The reason I tend to like touch points is because it's not quite as linked to being digital products. I think it represents the service a lot better. A task will be when somebody wants to get something done, but I don't think it illustrates, necessarily, the fact that it's an interaction between the company or the product system and the customer in the end. But they're very similar in the fact that somebody's trying to achieve a goal at some point.

For example, if I go and I'm shopping and I'm on, and I want to do product reviews or learn about a product -- I want to find a little bit more information about a product, read the reviews about a particular product -- I would consider that a particular touch point. I think that could also be called a task. They're very similar in that nature.

Later, if I order a product, I get it, and it's not the right product, and I have to return it, that would be a whole new touch point, because what it is, is it's the idea of meeting somebody's need at a particular place and time. The touch point tends to add a little more sense of that place in time aspect to it.

The fact that it's a week later, maybe I'm not on my computer I'm on a mobile device and maybe I'm in a different setting and now I want to do a product return. That's a new touch point even though it's still maybe in the digital space.

It's a new touch point where I'm having a different need, a need to return my product and maybe print out a return label, at a new place in time. They're very similar so I don't necessarily have a clean distinction but we've liked touch points because they really articulate the contextual nature of the interaction between the company and the customer.
Adam: The team at Paychex want to know how the map's used.
Chris: I highlighted this a little bit before. The maps typically can be used in three main ways that we've found that we've helped organizations with. The first one is the organizational overview. We're crossing silos with this map. When we do this activity, it really should be collaborative.

I would never trust if somebody said I'm going to do a customer journey map or an experience map so give me some information and then I'll go away and then I'll come up with this great illustrative blueprint of what the customer's journey looks like. I'd be very suspicious of that. This is designed to be something very collaborative and, ideally, cross disciplines within the organization.

We usually like to think of it as something that can also then inform how the organization functions like how different groups will now collaborate with each other once they can see how a customer's journey is interdependent on both groups or multiple groups and how they might want to martial their resources or organize it.

Then, of course, it can be used to help set priorities. If you have an experience map and you're looking at these different touch points, these different points of interaction over time, you might not be able to address all of them all at the same time. Overnight, you can't just start to make the experience more seamless or have somebody have a better point.

When you're able to identify points of opportunity and pain points you're able to then prioritize what do we tackle first, what do we tackle second, what do we tackle third, you can create a road map. A road map is a very good follow-up outcome to have after you've done an experience map.

The third way is, again, tactically where you can often understand a little bit more about the nature of what's happening at a particular point in time when a customer is interacting with your product or your company so you can understand what that touch point should look like. Is it about repairing the experience? For example, a product return or a password recovery.

These are where somebody's experience in the continuum of interacting with your company have stalled. It's in a negative place because I'm not happy with this product, I need to return or I've had a bad experience if I'm in your lobby at the store. Again, password recovery. I can't continue and log into the site that I want to do.

You start to see tactically how you should design that touch point because you're able to characterize a little bit of the context of that touch point and you can do that in some other ways. Is this something that's required or is it an enhancement? Is it repairing? You can actually get some tactical design recommendations or design principles that will inform what features you're supporting or what type of things you need to include in it and then how important it's going to be through this.

The organizational strategic planning and then even some tactical design recommendations are the ways that the experience maps usually are used and the things that they can feed in.
Adam: Andy's got a situation where the stakeholders for their products just have limited time to be involved with their design process. He wants to know how you make the most of the time that they do have when thinking about their experience maps or actually working through the process?
Chris: It's a good question because it is going to be one of the more common challenges. There's no silver bullet to it. First things first is I try to set the table as best as possible, try to socialize within the organization the value of doing this activity collaboratively so that maybe you can sell them on the idea that these four or five or six people should be in a room together in typically facilitation techniques where we want to get people in the room nodding their heads in unison so there's a certain amount of agreement.

Setting it up ahead of time really well so it's not just like I'm going to do this thing, it's an experience map or it's a customer journey map and I need some of your time. That's just one more thing that they know that they need to give an interview for or something like that.

The best you can find case studies or somehow show the value in doing it will be really good. If the time is limited then a lot of the things that you can do, of course, are the typical things when you do stakeholder interviews or you do the meetings and you use that room and time effectively.

The most important thing is to set the expectation of what has fed into a good customer journey map or experience map. That is basically like citing your resources. You want to show that your experience map is created using real information. That could be surveys, web analytics, customer interviews, field research or some type of contextual inquiry, and then of course stakeholder interviews.

And so, you want to show what has fed into it, like a footnote on the map, so that it adds authority and credibility to the map itself. If you have stakeholder interviews, you want to highlight that. And then people's expectations of how valid or fleshed-out the experience map will be can be set, because, similar to personas, you do them at different levels.

You might do ad hoc personas, where you don't have a lot of real data to start with. And as long as you qualify that, and you qualify what stage this document or this artifact is in, then people can take it with the appropriate level of authority or appropriate level of grain of salt.

It's the same thing. If you're not able to get everyone's time, as long as you preface the artifact in knowing that this is with a certain level of involvement, a certain level of research done, and you know what incubation stage this map is in, I think that'll help. Even if you can't get a lot of time, in a way that your map may not be as authoritative, but as long as they know it's the in-process map with limited amount of information but this is where we're starting, that should also help.
Adam: You mentioned personas, Chris. Jim wants to know where experience map and personas actually intersect.
Chris: That's a good question. I used to frame it and I still think it's valuable that experience maps are personas put to action. Sometimes they're not necessarily directly driven by personas, but you usually have some type of insight into who your customers are or who your users are, and you're trying to highlight some important contextual things.

What are they thinking at any given point in the journey? What are they feeling emotionally at any given point in a journey? And then, what are they doing? Are they sitting at a desk? Are they walking? What does their environment look like? We want to add that context.

And so, if you do that research and you don't necessarily craft personas out of them, you can still understand what a typical user is doing at a given point in time. But it's often, and we've done this as well, is we have personas that we use in a number of different ways. We do that research where we understand who that user is or who that customer is, and then those personas will help drive the experience map.

I think the customer experience maps are the personas put to action, over time and space. It's the personas going on this journey. I think the personas, as a first step to help drive the experience map, will be a really great activity.

I talk about, when creating an experience map, the prologue to the experience map, the thing that helps frame it, I call it the lens. The lens is what sets up what you want to look through the journey through. That could be a persona. What are the persona's goals? What are some key quotes? What are some of the characteristics? You set up the experience map with the persona so that when you're looking at a given point in time in the journey, you align that with what the persona's expectations are.

There's other things you can do to frame it. It could be your value proposition. It could be your company's mission. It could be some guiding principles. It's this thing that when you're looking at a point in a journey, you align that with the value proposition or the persona's goals or the problem or guiding principles you want to align to.

You can then identify, well, here's a real point where we're really excelling at that, and here's a point where we're coming up short--it might be a pain point--or here's an opportunity that we're not addressing, but that if we did, it would align with the persona's goals or it would be aligned with supporting our value proposition.

That lens, that qualifier that sets up the story and you can mash the story against, can be a number of different things, but a persona is definitely one of the more valuable ways that you can set up your journey.
Adam: So, related, Jess wants to know how scenarios come into play. Do you differentiate those from actions on the experience map?
Chris: I don't know about differentiate. The experience-map story is typically something that is going to be comprised of multiple scenarios. Scenarios are typically going to be around a task, and we already talked a little bit about tasks and how we have features and tasks and scenarios and touch points.

I think you could create a scenario in where you're telling a person's story around a particular touch point. If you have the overall journey, it's a little bit too big to be called a scenario. It's crafted out of multiple scenarios.

And so, then, if you take a touch point out of that journey -- for example, I want to return something, so I want to print out a return label -- I could then craft a scenario out of that. I think a scenario is one way to articulate what's happening at a touch point.

I could say that a touch point is somebody having a need to print out a return label in order to return their merchandise, and then I might craft a scenario to make it more empathetic, something that's more human, by actually telling the story of my persona doing that, enacting that touch point or engaging in that touch point.

A lot of this stuff is a bit of nuance on how we frame things. Do we need something that's going to be a user story, for example, an agile environment? We might articulate a touch point of a very simple way that implies what needs to be supported to allow that touch point to be a good experience.

In returning a label, I might just say, "I'm a user that needs to print a return label from the website." Well, that's an agile user story, basically or the depth of it. But, if it's a little more involved of a touch point and you need something that keeps it human, so to speak, then you might actually break that on to a more robust scenario where you tell the story of when they got their merchandise, they tried it on and it didn't work for them.

They decided they need to return it and you flesh that out. A lot of these things are, basically, relative to zooming in and out to the level that we need them. If we need the full journey, we might look at something like an experience map. And then, if we break out a touch point from the experience map, we may say it has a simple articulation like a user story or it needs to be more fleshed out, more empathetic and human.

We might make it into a scenario.
Adam: Chris, there were some questions that were asked during the seminar that we did talk about a bit, but I thought they were great and wanted to revisit them. David wanted to know if experience maps are exclusively for existing products and services or are they a great tool for new products and services.
Chris: Yeah. I think they can be used for both, and I admittedly have used them mostly for existing products and services. What happens is you see these a lot because more and more organizations are realizing that whether it's just going from desktop web to mobile or it's actually involving other channels like the customer call center or retail environment, they're usually understanding that they need a way to reframe looking at their whole holistic system, the whole experience of using an existing product or service.

But when we do that, not only have we done different maps for different personas, so we come up with different versions if we found that the experience is divergent enough, based on the different customer type or user type, but we've also done future state mapping and current state mapping. We've understood here's a benchmark of where we're at and what the experience is looking like.

And then, also, let's look at where we want it to be so that in six months or 12 months or 18 months we can measure our progress against what we've understood a good experience will be like. In that sense, you could use it for a new experience as well, and you can use experience mapping to map what the current state of somebody's experience is like in absence of your product or service.

That's where you can really illustrate the way that your product or service would really fill a need or find an opportunity. You can do a mapping experience going through a particular journey that doesn't include your product or service, and then when you can map what it would look like if you're a product or service. That would kind of be the future state.

And then, again, so you might just do the future state of what you hope it to look like so that as you're building your product or service, you can measure it against what you planned, what you want that journey to look like. Hopefully, that's based on some research. Hopefully, it's based on understanding both what need your product and service fills and then within a customer's overall experience or overall journey where you're fitting that need.

It can be used for new products and services to understand the current state of the experience about your product as well as what you're hoping it can look like in the future.
Adam: David wanted to know if made sense to create a different experience map for different kinds of users. And the example he offers is a first time user versus a repeat customer, but there's probably certainly lots of different examples you could put in play there. What do you think?
Chris: Yes, it absolutely works. I think I already talked about how you could have different personas, and you can understand a part of an experience map that is really about, say, the onboarding experience. You can segment the journey. You can understand the whole journey which is often I call it from inception, from the moment that they even think that they need to do something that involves your product or service to completion.

But, if your product or service is really something that is dynamic and occurs over a long length of time, for example financial services, you don't necessarily map the experience of when I first open a checking account to when I'm 80-years-old and I pass away and I don't need financial experiences. There's other tools to maybe measure what the lifespan of a product or service looks like in customers' lives.

But here, if it's that complex way, you might segment different parts of the journey. Again, you can zoom in and out, going from your task to your scenario to your journey map. In this case, you might look at just the onboarding experience. What is the experience like when someone realizes that they might need this product or service to when they first research it, interact with it, sign up for it, get on board with it.

Once they've used it, there might be different things that they can do with it and you might map that particular journey. What is it like for a customer who's using our stuff after a year to go through this experience within a week or within a month, whatever might be a good starting point and endpoint, but as the current customer who's familiar with the product.
Adam: Susan wants to know how these maps evolve over time.
Chris: Well, that's interesting because it's a little up to the organization. I think this is something that is an issue that's not limited to experience mapping. It can be for personas. It can be for mental models. In an ideal world a lot of these artifacts are things that have some type of governance in place where there might be an ongoing stream of learning, of acquiring information, data or customer insight, so that you can evolve the map.

It's really good to set a goal, and sometimes it could be as simple as creating that future state map that you can compare against to know that you're going to revisit it in six months or in 12 months or every quarter, whatever that may be. It also goes to the fact that you might not always be able to do all the upfront research that you would love to do to inform a very authoritative or credible map in the beginning.

As long as you frame those expectations and understand, and again I'll use the metaphor "persona" is where you can do ad hoc personas where you have very little data. You have this, what do we know right now. You might mature that persona as you are able to do more activities to ongoing user testing, to ongoing field research or contextual inquiry.

Every increment or interval, whether that's every month, every quarter or twice a year, you're able to add to it. I think experience maps are the exact same way. Sometimes, you're able to do two weeks of research where you're talking to customers, you're looking at quantitative data, you're talking to stakeholders and you're able to make a fairly robust authoritative experience map.

But, in other cases, if you're dealing with something really complex or part of a large organization that might include a physical retail environment, phone center, mobile applications, all these different channels, it might be something you want to evolve over time because you know you won't get something that will make it authoritative within two weeks or within three weeks.

You know it's going to take six months and different iterations of people getting feedback. And so, a lot of this is a matter of scale. It's a matter of whether you're working for a small company that has a service that isn't just digital and mobile. It only goes a certain number of things versus I'm working for a large, financial service company or a large retailer that has multiple product lines and many different channels.

The importance is to make sure that you have assigned that governance, that you have created who's going to own the activities around informing an ongoing developmental map and what are those intervals. We know we're purposely trying to revisit it. We're purposely trying to get in a room and orchestrate these touch points.

The governance is the important part and whether you need to constantly revisit it and at what interval will depend on the scale of your business.
Adam: Sean asks a question about if your customer's journey is segmented and the example is the process of evaluating and purchasing the product and then this separate stage of actually using the product, do you recommend that all being on the same experience map or do you want to map those separate segments individually?
Chris: The typical answer is going to be it depends. We always like to say it depends and it's true. Again, I would point to the scale. I think it cannot hurt to segment them if the sense is that each of these journeys really represent milestones that will conclude, so to speak. Like the onboarding process or the initial signup process, if that's about just arriving at your site and seeing the value proposition measures in signing up, that might not need some experience map.

But, we've dealt with other complex products and services like getting auto insurance or life insurance or going through a healthcare system in which the fact of even just learning about it and understanding the product and the signing up for it is a really, fairly involved journey that might take a month or more. And so, that journey is worth segmenting by itself.

A couple of factors I'd look at in deciding whether or not the journey needs to be segmented is how long some of these segments occur. If you're talking about a year, then you're probably going to want to break that up. If you're talking about the fact that there's a real big difference between once I sign up and then after I've been using it six months, what it looks like to use as a repeat user, you might want to break it up.

I think it's completely logical to break up the segments if it feels like the scale of those particular segments are a lot to get around and tend to have their own story around them. Starting from researching something to signing up for it, if that takes a week or two months or three weeks, then all of a sudden you realize that there's a whole process there of what activities are doing that don't involve your company.

What are the things that they're trying to get a handle on and understand in order to make decisions? That's a journey in itself. Using the product as an existing customer in a certain way could be a whole other type of journey. I've signed up for something and now I want to go to their store and I want to use it and what is the journey of a day at the store look like, for example?

I think there's very logical ways to segment it, and I don't think it's bad that you could have two or three maps to segment the key journeys of a new customer or a repeat customer signing up.
Adam: Allison wants to know if you're working with a product that offers 20 or so features, maybe lots more for use at any given time, how do you capture those touch points? How do you account for the variations in their use and the example she offers might be like a smartphone or collaboration tools?
Chris: Yeah so one of the things is that a company or a product or a service can "touch" people in a huge number of ways. Also, you want to capture other events which are like the things that happen that don't involve your company. If I'm traveling and I'm going to look on research review blogs about travel sites or things like that, so that might influence their experience with you even though you're not directly involved.

What we typically do is do a touch point inventory. We will look at all the ways that a person comes in contact with our company. An experience map usually can't encapsulate that. If you're dealing with something that's fairly simple, you're looking at a digital and a mobile channels and typically using your service, it just takes a really small window like just a few hours and we want to map what that few hours looks like, then you might be able to capture everything.

But, we've looked at a lot of different service industries, it's hard to map and tell a story and capture every single interaction point. But what you realize is they're not all created equal. Some are more important to the customers and some are more important to the business. When you're dealing with that big of a scope, that large of a scope of touch points, you'll basically do a touch point inventory.

This is similar to if you're an information architect and you do content audits or content inventories, you want to catalog all the touch points, understand what stage these occur in and maybe what channels these involve. Another thing besides a touch point inventory is you can do an ecosystem map, and it's a service designed tool where, again, you're identifying who the actors are, what the artifacts are, what else is involved.

You're basically...It's a discovery exercise where you're getting the full landscape of everything that's involved. When you align that with your research of what you understand is important relative to some quantitative information or what's important from a qualitative standpoint of what is happening with your customers and what are the opportunities and the pain points, the themes that have come out, then you can pull out from that inventory what the critical ones are that are important to tell the story of a typical experience for a customer or typical experience for that specific persona.

When you're dealing with a large scope of touch points of possibilities, then you really want to get a grasp on what that whole universe looks like and then you align that with your research so you know what the important parts are and what are the parts that need to be included in the story.

If you're looking at features, after you get your experience map, you understood what these touch points are, these critical interactions between your customer and your company and you know where they take place in the journey, hopefully you know a little bit of context about them, what's involved at that particular time, what is the person doing, what are they thinking, what are they feeling, any other insight you can.

When you pull that touch point out, you can understand what are the features that are needed to support that interaction? If I use the example I said that I want to return something and I want to print out a return label, that task or that touch point will have a set of features. And so, then, I can look at that touch point. I can understand what's involved in supporting that, if it's going to require this feature, that feature, the other feature.

But, hopefully, when I pull out that touch point, it'll have the DNA of the longer journey or the whole journey with it. That's what we do once we pull out a touch point from an experience map. We'll literally put it on some type of artifact in itself like a worksheet or a card that will then articulate that touch point in the form of like a user story or even a scenario, characterize it in some way.

I talked about whether this touch point I frequent or whether it's about repairing or whether it's a required touch point, it's something you have to do like signing up or accepting or validating your computer for financial services. And then, you can start to understand what are the actual features, the tactical features that you need to support a good experience in that touch point, again with hopefully the DNA of the larger journey attached to it.
Adam: Wow, what a fascinating tool experience maps are. Chris, thanks for joining us for the podcast and for sharing more of your expertise.
Chris: I appreciate it and being the 100th speaker, I'm still waiting for the confetti to drop and my fake big prop check but it's on its way.
Adam: Thanks everyone for listening in and for your support of the UIE Virtual Seminar Program. Remember, you can get all the details on our virtual seminars at