Experience maps have become more prominent over the past few years, largely because companies are realizing the interconnectedness of the cross-channel experience. It's becoming increasingly useful to gain insight in order to orchestrate service touchpoints over time and space.
But I still see a dearth of quality references. When someone asks me for examples, the only good one I can reference is nForm's published nearly two years ago. However, I believe their importance exceeds their prevalence.
I'm often asked what defines a good experience map. You could call an experience map a deliverable, although, as the current 4-letter word of UX, that may make some people gag a little bit. But really, it's a model. A model on steroids. It's an artifact that serves to illuminate the complete experience a person may have with a product or service.
But it's not just about the illustration of the journey (that would simply be a journey map). And it's not a service blueprint which shows how a system works in enough detail to verify, implement and maintain it.
The experience map highlighted above was part of an overall initiative for Rail Europe, Inc., a US distributor that offers North American travelers a single place to book rail tickets and passes throughout Europe, instead of going to numerous websites. They already had a good website and an award-winning contact center, but they wanted to get a better handle on their customers’ journeys across all touchpoints, which would allow them to more fully understand where they should focus their budget, design and technology resources. Derived from this overall “diagnostic” evaluation, of which the map was just one part, were a number of recommendations for focused initiatives. The experience map helped create a shared empathic understanding of the customers' interactions with the Rail Europe touchpoints over time and space.
I almost always apply five critical components that make an experience map useful. And when I say useful, I'm thinking of two key criteria: First, it can stand on its own, meaning it can be circulated across an organization and doesn't need to be explained, framed or qualified. Like others, we make our experience maps large, often greater than five feet long. They're meant to engender a shared reference of the experience, consensus of the good and the bad.
Second, it's clearly a means to something actionable—ideally something to design around—and not an end in and of itself. A good experience map feels like a catalyst, not a conclusion.
Before we dive in to those five dimensions, though, there's one other part I want to point out—the activities that should lead up to the creation of the map. A map should have some qualitative and quantitative information in order for it to take shape in a meaningful way. In the case of Rail Europe, we created a survey that garnered over 2,500 responses, while also conducting field research with Rail Europe customers.
If the experience journey has a good number of touchpoints, then it becomes hard to highlight every touchpoint in the experience map. The map would start to lose focus and meaning. Instead, we start with a touchpoint inventory, cataloging all touchpoints a customer has with the product or service, great and small. But, beyond some logical groupings I don't worry how they relate to each other, save for identifying the nature of each touchpoint or the phase in which it lives.
Once you start to synthesize your research you can start matching those insights with the critical, complementary and superfluous touchpoints from the inventory. With that groundwork laid, five dimensions to a map are the lens, the journey model, qualitative insights, quantitative information, and the takeaways.
The lens is an overriding filter through which you view the journey. If you have clearly different personas, or user types with fairly different paths, then the lens will likely be a summary of the persona—in which case you'll make multiple maps for each persona. But often the core of the experience (and the opportunities and pain points the map highlights) will be the same because you may be focusing on core touchpoints that apply to each persona, in which case the lens could be some overarching principles, such as design principles or a value proposition. So you look at the journey, and specifically the touchpoints within the journey, and ask yourself, “Does this match up to the principles?” “Does this meet the needs for this persona?” The key is that you want to look at the journey against some type of criteria—and personas, value propositions, or principles are that criteria.
The Journey Model
I call the illustrated journey the journey model because it doesn't always have to look the same, it all depends on the nature of the journey. Which means it could be rendered, or modeled, in a number of different ways.
It should also illuminate the most important dimensions—which could be the transition from phase to phase, or the switching between different channels. This is where you may want to get your Tufte on and make sure that you aren't simply illustrating the journey step-by-step, but ideally revealing something about it based on how you model the data, e.g. how many people use one channel over the other, which part of the experience is blatantly broken, or which part of the experience hasn't been considered much? The map below (scrubbed for confidentiality), has the same five components as the Rail Europe example, but the journey is modeled differently because the switching amongst channels was an important dimension to illustrate.
In this experience map, the journey model highlights the switching between channels, with the size or density of the arrows indicating qualitative information about the volume of switching. View and download larger version
When applying qualitative insight, we often use a framework of “doing, thinking, feeling” with the “doing” being the journey model, the thinking framed as Can I use this? Will this work? I like how this feels, and the feeling utilizing responses such as frustration, satisfaction, sadness, and confusion. It's an important component in order to understand the importance and value of a particular touchpoint for your customers.
Quantitative information is also pretty important but can be easy to overlook. Perhaps your research included a survey, or maybe it's just gleaned from web traffic reports. But ideally you can illuminate the journey through quantitative information. In one case, it can be used to emphasize certain parts of the journey (only 10% encounter this touchpoint, while 70% encounter that touchpoint). In other cases, particularly from a survey, it might be about the touchpoints themselves. For Rail Europe, we conducted a survey and were able to get three really telling data points—the enjoyability of this particular phase of the journey, the relevance of Rail Europe to that phase (for example, Rail Europe was very important in the booking, but not as important after the trip), and the perceived helpfulness of Rail Europe in that phase. This highlighted gaps as well as showed where there was a good alignment between relevance and helpfulness.
Quantitative information from the Rail Europe experience map
This example integrates quantitative information through the density of arrows, showing the volume of channel switching at a particular touchpoint
But the data could be almost anything—a sparkline illustrating the enjoyment level of each phase or step, or the usage level, or traffic. Like everything on this map, as long as you have all the important dimensions, how they are rendered can depend on the context (Say it with me: It depends!) In the second example above, the quantitative information is shown through arrow density, used to communicate how much channel switching was occurring at a particular touchpoint.
Since the map is meant to be a catalyst, not a conclusion, the takeaways drive the next phase of the design or strategy by illuminating the journey, and helping to identify the opportunities, pain points, and calls to action. This will depend on what your next steps are, driving strategy or tactical design.
Experience maps aren't limited to multi- or cross-channel experiences. It's about orchestrating multiple touchpoints that occur over time. And there's no right way to do an experience map. As with everything, context is important, and your needs may necessitate something similar, yet different. At Adaptive Path we rarely apply the same set and sequence of methodologies and processes on projects, because they all present a unique challenge. But this set of guidelines has helped me identify when to use an experience map, what I should get out of it, and how it fits into the overall research and design process.