An experience map is a structured customer journey map that we use at Carbon Five to help identify challenges and opportunities within an existing (or imagined) experience. Since we use it so often – both when scoping projects and when kicking off major phases of work – we’d love to share a bit about what makes a great experience map. And because we create them collaboratively with stakeholders, we’ll share our facilitator tips for running an enjoyable experience mapping workshop.
Any diagram that has time on the x-axis can probably be called an experience map. The specific kind of experience map we do at Carbon Five is more accurately called a service blueprint and is traditionally associated with service design. We were first introduced to this style of map by a client, the amazing Tamara Khan. Experience maps look something like this:
Time is along the x-axis, and each box represents a step in a linear experience moving from left to right. The horizontal swimlanes each represent a different actor in the system. The lanes are organized so that the high-touch, physical-world interactions between actors are at the top, and the low-touch, back-office and supporting system interactions at are the bottom.
Often, these maps include other information mapped against the overall experience: things like customer pain points, key steps in a funnel, long delays, or expensive business operations.
Sometimes, two experience maps are used to describe an “as-is” state (the experience as it exists today) and a “to-be” state (an improved experience that you wish to see in the future).
Don’t care why? Skip down to when, who, or how.
Think of the customer journey of an average hotel guest. They get off of their airplane, wrestle their luggage into a car, drive or ride in an unfamiliar city, haul their luggage up to the front desk, wait in line, and finally, it’s their turn to check-in. In the world of customer experience design, this moment is called a brand touchpoint, and it’s crucial to get it right. And at this point in the customer journey, our customer is tired and cranky, a challenging situation for sure. It’s time for our brand to come to the rescue. What do we do?
If we’re DoubleTree, the answer is simple: we give them a cookie.
For those of you who have never stayed at a DoubleTree: when you approach the receptionist, the first thing they do is hand you a warm cookie. In fact, they have special ovens tucked away behind the counter for just this purpose. And if you’ve ever wondered how they came up with the idea, an experience map is a good guess.
Experience maps are effective tools, because:
One of the great things about experience maps is that they put the customer experience at the top. This helps the whole team see the product from the customer’s eyes, promoting empathy and helping shape a desirable product.
Getting the team on the same page about the product, and having a single document that captures the whole experience is valuable through a project. Not that drawing a box around a particular solution is an easy thing! It’s not, but it’s a worthwhile exercise, even to discover that you’re not ready to define the product without doing some more research or experimentation.
As consultants, we are often asked to size projects in terms of team strength and durations. But in-house team leads get asked this question all the time as well. We use an experience map as a way to collaboratively assess the number and complexity of desired features, as well as to identify major third-party integration points. Further, we use the resulting map as a conversation-starter around prioritization by turning it into a story map.
Once we have the map and a sense of overall milestones, along with an understanding of stakeholder flexibility regarding prioritization, we can typically give a ballpark estimation for the team size and duration. Plus we have the feature list and rough system architecture.
Once you have your estimate, more often than not you’ll want to make that estimate smaller. While some of the great product ideas in an experience come from streamlining or automating steps in an experience, sometimes you want to get the product to market faster by people-powering features. The experience map lets you play with what actor (be it person or machine) that supports each step in the customer journey.
New solutions to existing problems jump off the page of a good experience map. Take any existing real-world experience (hailing a cab, hiring a babysitter, waiting in line at the DMV, losing your luggage) and map it. Chances are you’ll find pain points that are opportunities for innovation. Then you can define a new experience map based on your product idea and keep on iterating.
Consider making experience map when:
Photo credit: Laci White
We like and encourage you to create experience maps as a collaborative activity involving a cross-functional product team. Since we are usually mapping software experiences, our workshops generally include:
There isn’t a perfect size for the team, and often individuals have overlapping roles, but if you are approaching 10 people in the room, some folks will get bored. Between three and six folks seems ideal, but we tend to err on including extra interested stakeholders, even if it is just for the sake of transparency and consensus-building.
Creating an experience map is relatively straightforward in theory, but complicated in practice. We’ll lay out the basics and then share some facilitation tips along the way.
The original experience map for Masterclass
In addition to the cross-functional team you’ve assembled, and the two hours you’ve carved out, you’ll want access to a private space and a large table. You’ll also need:
Don’t have a large enough space or your entire team in one location? No problem! You can use a virtual tool like Stickies.io to collaborate with remote teams and easily create a digital document to share.
If you can’t find a long table, you can also do the activity on a large wall with sticky notes. We slightly prefer the index-cards-on-table approach since it makes moving cards around easier and is slightly easier to collaborate around. If you do use a table, remove all the chairs from the room or push them against the wall: you’ll want everyone standing around the table.
Before the workshop, lay out your swimlanes the long way on the table or wall, one lane per human actor in the system (which you’ve identified these during customer interviews), plus two additional lanes — one at the top and one at the bottom. (We’ll talk about them in a second).
Organize your index cards or sticky notes so that each swimlane gets a different color and label each of the swim lanes with one of the actors. These will be the role names of the actors in the system plus the two extra lanes, the top one labeled “Artifacts” at bottom lane labeled “Software.” For example, if you were creating an experience map for a café, you would have the following cards laid out along the lefthand side, one per swimlane and each in a different color:
* For those that are well-versed in service blueprints, you’ll notice that we’ve renamed “Physical Evidence” to “Artifacts” and “Support Processes” to “System.” That’s because, at Carbon Five, we are making software. So we like to include virtual things like emails and SMS notifications in the top swimlane (in addition to any physical artifacts), and mostly only interested in software for the bottom swimlane.
Notice that the actors are laid out top-to-bottom so that the actor that interacts with the customer the most (the cashier, in this case) is right below the primary actor. This pattern carries down the chain. A very typical set of swimlanes for a software platform for two-sided marketplace (e.g. Etsy) looks like:
This is true even though the seller experience happens before the buyer one (to get the product into the marketplace). That’s because the buyer is the end customer, and the seller is more likely to interact with back-office actors.
Finally, lay out a piece of tape vertically just to the right of the roles and stack the rest of the cards/stickies and pens in a place that is convenient for multiple people to grab, since you’ll want everyone participating.
The only other thing you might want to prep is to think about where in the overall experience you think the map should begin and end. In our experience, teams can sometimes spiral debating on how far back in time to take the experience map, and it’s always good to have an end target in sight.
A good default is to begin the map right when the main customer is going to use the product for the first time and to end it when they refer the product to a friend. So, for mobile apps, or first card is often “opens app” and for web applications, it’s “visits site.” You can always do another map that dives into how the customer is made aware of the product, finds it, and the like.
Gather the group and introduce the activity. If you are facilitating this for the first time, have an especially large team, or if anybody seems confused, you can spend 15 minutes and do the beginning of the café example referenced in this post. This helps orient everyone without the extra mental load of thinking about the actual product under discussion.
Beginning with the end customer, create one card for each step in the experience, moving from left to right.
A couple of tips when creating a card:
If the action you just documented is roughly simultaneous, place it directly below the first actor’s card. Continue the map, moving from left to right, top to bottom (you can stay with one actor for a while, and backfill actions below, or go deep for each step in the flow).
When there is an external triggering action (often an email, an SMS, a physical device, or a printed piece of collateral) for an action, describe it on a card and place it in the “Artifacts” swimlane, above the actor that interacts with the artifact.
When you create an action card that interacts with a piece of software instead of another person, add a card that describes the software that is being interacted with in the “System” swimlane. This can be a known, named system (e.g. Salesforce) or an abstract placeholder (e.g. E-mail Service).
When in doubt, just jot something down for a future conversation — the goal of this part of the map is to identify big chunks of software, not to design the domain. It is especially interesting to note which components of the platform touch internal or external services, since these integrations tend to cause estimates to balloon.
Continue moving from left to right, top to bottom, taking breaks as needed, until you reach the end state defined up front, or you run out of ideas for cards, or are just plain exhausted. Before wrapping up the map, consider doing a couple of follow-on activities:
Note where different steps of a typical user funnel occur, and fill in missing steps. Look for where in the experience users are acquired, where they have achieved the core value, where monetization occurs, and where (if anywhere) a referral loop happens. These can be your first draft of KPIs, and will help designers identify key points in the experience to optimize.
Take a minute to identify where big gaps of time occur, and mark them with a sticky noting how long of a wait the step typically takes. Also mark where you think major pain points are (or will be) for each actor. These are often areas for ideating potential solutions. You can also annotate your map with pull-quotes from user interviews and usability tests.
If you are modeling an existing “as-is” experience and are looking to automate some of it with software, you have already identified some pain points to think about. But if you are creating a “to-be” map, take a moment to think of steps of the experience that you may assume will be automated (e.g. are in the “Software” swimlane) and see if you can people-power those features at launch. You can always write more software later, but you will never get back the time you spend on features nobody really needs.
Now that you have your map, you should at least document it and consider transcribing it to a more permanent medium. Better yet, transfer it to a wall near the team. And here are two other interesting things you can do with an experience map:
After dot-voting major pain points, turn them into a “How might we?” statement and do some six-up sketches (or its relative, crazy-eights). In this activity, everyone in the group comes up with six different ideas to fix the problem in six minutes. Using this technique, you can come up with a ton of new ideas for the product within the context of the the overall customer experience. These ideas can be prototyped for validation, or prioritized and added to an existing product as an A/B test.
Another great thing to do with the map is to turn it into a prioritized backlog, along with major milestones. It’s pretty easy: just take each vertical column and staple the cards together. You’ll have what is basically an epic that is told from the primary users perspective.
After you’ve stacked all the cards in each column, you can cluster them into a Jeff Patton-style story map by grouping them into major activity areas, typically categories like onboarding, shopping (or whatever the major experience your application supports), sharing, support, and so on.
Within each cluster, sort the cards in order of priority. Then create a milestone of, say, the top five cards that you think make a cohesive product or interesting user test. Continue prioritizing and grouping cards into a handful of major milestones that can be given ballpark estimates, allocated teams, and put into a roadmap.
Finally, a completed experience map is a great place to pause for a moment and focus on user experience design. While the map feels like a reasonable picture of a product, a designer will bring another perspective as they create flows & detailed wireframes, build & test prototypes, and design the interaction & visual language. It’s also an excellent time to let your technical lead think about the high-level system architecture, do some domain modeling, and do some technical spikes if needed.
At Carbon Five, we may do 50 experience maps a year, and each one comes out a little differently depending on the team and the product. And we’re constantly on the lookout for new tips and tricks, so please share your experience mapping…er…experiences with us!
David is the Director of Design at Carbon Five. He joined the company in 2004. Before that he was a freelance illustrator and a co-founder of the web development firm Fire Engine Red. David lives in Alameda with his wife Jenny, their dog Daisy, and a tiny dinosaur named Dorothy.