Getting a Clue: Journey Mapping and the Rashomon Effect
We often talk in terms of silos in organizations, where information isn’t readily shared and communication leaves something to be desired. Another way to think of a team who is heads-down working on the overall journey is to imagine swim lanes. Each department is so focused on their own part of the experience that they might not be fully aware of each step a user has to go through to complete the journey.
In this episode, Conor Ward, Head of UX and Design at British Gas, tells a story of how mapping out the journey to acquiring a quote for boiler insurance revealed some unexpected insights. Jim Kalbach, author of Mapping Experiences, also joins the podcast to share his expertise on the subject of journey mapping.
Full Transcript
Jared Spool:This is the UIE Podcast. I’m Jared Spool.
It started as the perfect evening. An elegant dinner party at a beautiful mansion, rivers of wine lubricating conversation. But then, an unexpected turn. The power goes out, and when it returns a crime most heinous has been committed.
The remaining dinner guests, a collection of punny, color-based, mostly alliterative names, gathers to answer the age old question: Whodunit? The event itself wasn’t in question, though each person was coming to their own conclusions of how it all happened. Their siloed perspectives created a disjointed understanding amongst them.
In many companies, we see the same thing. No one is in dispute over what the product or service is, but many times departments are so focused on their own part that they can’t see the entire customer journey. If the party guests had come together and compared notes they would’ve quickly determined it was the nefarious professor with a candlestick in the parlor. Similarly, teams need to get out of their silos and come to a shared understanding to get an accurate picture of the journey through their product.
Conor Ward:It was interesting because part of my process for quite a long time had been making sure that I mapped out a journey. In my head, I had to see it in some sort of a single view format. Understanding all the steps of my journey was something that I always needed to do before I realized how important it was for everybody else to be involved in.
I’m Conor Ward. I’m head of UX and Design at British Gas.
Jared:Journeys can be hard to see. In Conor’s case, the journey was the steps a user had to take to obtain a quote for boiler insurance. This isn’t an uncommon need for homeowners. It seemed like a simple process and well understood.
Organizations are often made up of teams with differing perspectives and levels of understanding. These teams may act independent of each other, focused on their own interests and objectives. If everyone is stuck in their own silos, the user might not be getting a desirable experience.
Jim Kalbach:To some degree, it’s also a knowledge management problem. Nobody knows that. Everybody’s doing their right steps in their own silos or at that right point but then when you take a step back and look at it from the outside-in, suddenly there are massive problems that become blatantly apparent.
I’m Jim Kalbach. I’m the author of ‘Mapping Experiences.’
Jared:Jim has spent much of his career studying techniques on how teams can identify those massive problems.
If you hear a loud noise in the next room over and you discover your child standing next to a broken vase, you may have some idea about what just occurred. But if they innocently blurt out “I know what this looks like”, they wouldn’t be wrong, but that alone isn’t enough evidence to defend themself. The question then becomes, do you take this situation at face value or do you investigate? What are you really looking to understand?
In the case of digital experiences, what it looks like doesn’t necessarily correlate to how it works. What appears to be only a few steps in a user journey may be hiding something else entirely.
Jim:The reality is, very often, we don’t know, companies don’t know what their customers actually go through. I see that time and time again and that’s part of the activity of mapping, is to shine a spotlight on that, to say, “Well, here is the real experience, slowed down, frozen in time, so we can diagnose that and actually step through it step-by-step.”
Jared:For Conor and his team at British Gas, their understanding of what a customer actually needed to do just to simply get an insurance quote was shrouded in their design.
Conor:My question was well, what’s that like? How do we know what that’s like? I can see the screens but let’s find out what it’s actually like.
The first thing I did was get a piece of paper and a pencil and sketch out every step. The interesting thing about that was, on the UI, the UI sections out this quote journey into four steps. It tells you quite neatly in a little visual progress indicator, you’re on step one, now you’re on step two, then you’ve only two more steps to go, isn’t that lovely? Turns out that wasn’t really the case. It actually didn’t take into account all the little sub-steps that are involved.
Jared:Nobody knew the full experience. Everyone thought there were four steps, but it turned out there were many more.
For example, at one point, the insurance quote system asked the user for the make and model of their boiler. Nobody walks around having memorized their boiler’s particulars, so this one question became a stumbling block for completing the quote.
There were many of these substeps. They were not in Conor’s original sketch. Because no-one took them into account. They were not part of the evidence he had available.
When designing an ideal experience, it’s all in how you interpret the evidence. These extra steps, substeps, or interactions could be important parts of the user’s journey. Lumping multiples of these into a single step treats them as circumstantial. You could be missing out on the smoking gun that unlocks your entire experience.
Conor:If there’s an interaction, it’s still a step, just because it’s not listed in the progress bar doesn’t mean it’s not a stage someone has to go through to proceed on to the next stage. The strange thing about that was, once that was visualized, we realized that the initial ask from the business, had analytics showing us the performance of each step and they had analytics showing the performance of four steps. We weren’t really aware of what the performance was of all twelve of these steps because we weren’t tracking it in that way. Mapping out all of the actual user experience steps going through it ourselves, we realized that the analytics that were brought to us from the business as the starting point to do this work were only tracking the four steps that was perceived to exist. We didn’t have good enough analytics to tell us how it actually, these twelve, thirteen steps, were performing. That was an interesting finding.
Jared:When you can take a step back and really see the full scope, you get a better idea of how accurate your understanding is. In organizations where departments are siloed, you don’t have anything to compare to. The understanding you’ve gained about the journey from your limited view is all you have to work with.
Jim:I think that’s the power of visualization because you can compare, from an outside-in perspective, from a reality-checked perspective against the product and the service touchpoints. You can then better diagnose whether that is closer to the intention than it should be. I say closer to the intention because it’s always a moving target.
Jared:Information is your greatest design asset. Every hypothesis is true until it’s proven that it isn’t. The quickest way to validate or invalidate assumptions about a user journey is to look at it, and then talk about it.
Jim:Our friend Chris Risdon, who’s done a lot of great work on experience mapping as well, calls them, “Catalysts for conversations.” The diagram then becomes a centerpiece for a conversation that level-sets those different perspectives. It doesn’t matter if you’re in marketing, or sales, or engineering, or customer support, or even the CEO. You’re all looking at this external representation of the customer experience and that’s level-setting.
Conor:We had interesting conversations. We brought people into rooms and we sort of said, “We don’t seem to be dealing with optimizing step three here, we seem to be dealing with a journey that has twelve steps that possibly should have all of these twelve steps. Can we change the conversation from trying to tweak and improve the existing steps that we have to challenge why we have any of these steps? Can we start again from day zero with this whole journey?” Now that we’ve done a very, very basic, as is journey map, could we somehow craft a much simpler “to be” journey map and then, find out how impossible is that to create? Or how far away from that do we have to move? That was the next most interesting conversation. It moved it away from suggests of UI changes to rethinking the experience and the behind the scenes calls that the system makes, and trying to understand why anything was there in the first place. The conversation became immediately incredibly more rich.
Jared:Once you have a solid grounding in what the journey is at the current moment, you can begin to look at how that squares with your expectations. You get to put yourself in your users’ shoes and see the journey from their perspective.
This is your eyewitness account. You can see the journey as it actually happens.
There are two perspectives, the actual journey users make, and the aspirational expectations of the organization. Seeing these side by side, you can begin to make necessary changes.
Jim:Typically, what I’ve done, or what I’ve seen is you have the as-is diagnosis and then, “Okay, so what are we going to do about it?” That can be included in an extension of the same diagram. Two diagrams, also possible, you could see the problem and the solution as well, too. Then, it becomes a no-brainer. “Should we go ahead and do this, reduce things from 13 steps to four steps?” I don’t know anybody who could argue against that.
Jared:The most important part of distilling all of the evidence into understanding, is that it doesn’t need to be pretty. The map itself, as an artifact, is less important in the long run than the conversations around it. The simple act of getting everyone aligned around the same information allows for the journey to be understood correctly. It’s not about how you lay out the information, it’s simply that you’re doing it in the first place.
Jim:There’s this alignment and in the diagram, it’s actually a physical, literal alignment. Usually you have these long, horizontal-type diagrams that are in tabular form and the top part is the snapshot of the customer experience. To that, you align what the service or the product does to support it at each of the touchpoints. There’s this alignment of what we do, what you do as a business to the customer experience.
In order to have then, the actions, the actionable intelligence that comes out of that work or be implementable, there needs to be team alignment too. You need to first get a common vision of what the experience is, then you need to align those teams to agree on how they’re going to solve that problem, right?
Really, the best example of a map of any kind, journey map, whatever you want to call it, that I know of, is the one that solves the problem. It’s not necessarily about artistic ability or artistic talent. It’s the one that solves the problem and that might be the one that’s done on sticky notes on a board or a sketch by hand, even.
If you’re working in a small team, in a small company and you can sketch it out by hand and it brings the point across that you have a complicated experience, or that the end-to-end experience is disjointed, or there’s a lot of friction, if you can make those points and bring that empathy to the team, it’s a decision-making empathy because they have to see the light. If you can do that in a hand-drawn sketch, then that’s a good example of a map in my opinion.
Conor:We kept it quite … What’s the word? Sketchy, I guess, in a digital sense. We sort of stuck a lot of red pens through it, a lot of notes on it saying, “Kill this step, merge this step with the next step, merge step four with step five, we can reduce this information,” blah, blah. It was kind of the changing as is to be on the same map, so that we could understand what was proposed to be changing
Nobody felt that this was a very technical diagram. One of the things we try to stay away from here is making schematic feel like the word schematic, which is a difficult thing to say even of itself.
Anything that has complexity in it, we try to keep for the right audience, for the developers, for the use experience people, for the product owners to discuss fields and steps and backend calls. We call those task flow diagram and we want to show every single step, we want to show every time it calls a backend systems and what happens next. That’s the detail document, which is fine, you can kind of have a magnifying glass to see the area that you’re interested in.
Jared:Pulling out that magnifying glass, you can start to really determine what needs to be included in the journey. You begin to look at everything in finer detail and with a critical eye.
Conor:What we actually looked at was a shopping cart existed. So, shopping cart existed on step one … In fact, step zero. Before you even decided to get a quote that showed you an empty shopping cart. It took up a large portion of the real estate of the screen.
The question was posed, why do we have a shopping cart in a quote journey?
When you finish your quote process, you land at your cart. The final step was, here you are in your cart, which seems strange to me. I know we’re not supposed to use a lot of best practices and heuristic thoughts so much these days but it did seem like a starting point of some further investigation needed to say, “I’ve only got a quote, how come there’s something in my cart?” Would I expect a cart in an insurance product basis? Like, would I add two of these, for example? Could I add two of these insurance products? Probably not. So, what is the purpose of this cart in this circumstances?
Jared:When the organization is all on the same page and working with the same theories, you can begin to allocate resources properly to smooth the journey out for users. You can’t design for your users if you don’t have a good understanding of them.
Conor:Do I need to see a picture of the screen to understand where I am? Let’s put that in it. Do I need to have some analytics telling me what the drop out, the conversion rate, at each step is, so I can understand the bit I understand as a sales person? Yes, okay, let’s put that on it. Understanding your audience and catering the map for that audience makes that conversation for me incredibly more important and easier to have.
We always try and put our maps up on large paper up on every wall that we can here, so that you can stand around and point at stages. What you don’t get, is people standing around a screen over a designer’s shoulder, saying this, that and the other. Let’s move that, let’s change that. It becomes, let’s point at the journey and remember at a 20,000, 30,000 foot level … Whatever you want to call it but we’re trying to have a good journey, not a good page. That kind of thing really allowed that conversation to be at that level, which is much more important.
One of our design principles is that we don’t believe in best practices for anything got to do with UI solutions. We believe in best practices for how you find out the right answer, not what you should create.
If we hadn’t’ve started with a journey map, we would’ve had a differently designed version of the same journey. We would’ve started from the UI out, rather than the journey in. All of our discussions were about how can we change the journey? The starting point of that piece of work wasn’t how can we change the journey; it was, what can we tweak to improve the conversion rate of the journey. The journey map let us have a bird’s eye view, zoom out a bit and realize that bigger changes had to be made.
Jim:Products are always changing. Customer demands and requirements are changing and those kinds of things. It’s not a one and done thing. It needs to be a habit. It needs to be something that you’re doing all the time and that is comparing the reality of the customer experience to what you’re actually delivering and constantly course-correcting, constantly course-correcting that and visualizing that it’s one tool.
I talk a lot about the difference between a map, a thing, a noun, a document, versus mapping, which is a verb. It’s an activity and it’s conversations first and foremost. It’s through those conversations that you come to a common aligned agreement or understanding.
Jared:It all comes down to evidence. If you find the dented candlestick, hidden behind the couch, that’s a pretty easy way to start getting everyone on the same page. You start your journey down the trail of evidence to arrive at the correct conclusion.
Conor got everyone on the same page, first by drawing how his co-workers thought the design worked, then by drawing how it really worked. The difference revealed where the true crime scene was, and illuminated the path to success.
Journey maps are a trail of evidence. When you gather everyone to see the steps your users have to go through, you gain new understanding about your own designs.
This UIE podcast is brought to you by UIE’s All You Can Learn library of fantastic UX presentations and seminars.
We just recorded Jim Kalbach’s wonderful UX Immersion: Interactions talk, Building Consensus by Mapping Experiences. In this talk, Jim discusses how Design Thinking, Lean UX, and Mapping Experiences are just a few methods that designers can use to lead strategic conversations toward customer-centric solutions.
You can watch his presentation, and over 300 more, at UIE’s All You Can Learn library for one low monthly fee. Just visit AllYouCanLearn.co for more information.
Also, if you’re in an organization that is looking to hire more UX designers anytime soon, I want to point you to our new school in Chattanooga, TN called Center Centre. Our students are learning what it takes to become an industry-ready UX designers and they need your help.
To help them learn the craft, they need great projects to work on. Companies supply the projects and, while they’re at it, they get to see what our students are capable of. It’s a great way to help grow our field while you’re doing preliminary recruiting. If you have a project that you think might work, please get in touch. You can learn more at Center Centre’s website. That’s C E N T E R C E N T R E dot com.
This UIE podcast was written and produced by Sean Carmichael. We’d like to give special thanks to Jim Kalbach and Conor Ward for appearing on this episode.
You can find more information about the UIE podcast on our newly launched UIE Podcast Network website: U I E dot F M. Go there now and look at all the great shows we’ve put together over the years.
This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.
