Welcome! This is part of my series of posts on Customer 360. If you haven’t already, you can read my overview of Customer 360 before you begin reading about user journey mapping.
The Journey of a Thousand Database Records…
…begins with a single touchpoint. Or something like that. If he were still alive, I’m not sure Lao Tzu would appreciate me making a lame joke out of one of his most famous quotes, but here we are. There was a point in me making this joke though – before we can understand our data, we have to understand where it comes from. And when it comes to customer/user data, most of it originates from various touchpoints. When I say “touchpoint”, I am simply referring to a way in which a user can interact with your company. This could be a visit to your website, opening your mobile app, reading an e-mail, making a call to a call center, paying a visit to a physical location, or dropping by your booth at a trade show, to name a few.
So, then… what exactly is user journey mapping? Put simply, it’s the process of creating a set of documents that describe in detail all of the ways your customers can interact with your company – and all of the ways in which data is a part of those interactions.
Quick note: In this blog post, I will be focusing on the aspects of user journey mapping that are most important when building a Customer 360 ecosystem. There are typically many more steps involved to do a full user journey mapping exercise; if you want to read more about that, Appcues has a great beginner’s guide to user journey mapping.
The Key to User Journey Mapping: Tell a Story
Maybe it’s the eternal product manager in me, but I like to approach user journey mapping the same way I would approach describing new features for my product: I tell a story about the user whose journey we are interested in. An agile-style user story typically follows this format:
“As a [type of user], I would like to [some action] so that I can [some goal or desired outcome].”
Framing our user journeys using this type of storytelling enables us to achieve the same goal as agile user stories, which is to generate conversations about the story. These conversations are where the insights about the journey will truly come from.
For example, if your story is…
“As a frequent site visitor, I would like to have my favorite pages remembered so that I can quickly get to exactly what I need to see.”
…then it might start to generate questions which will help you build the most complete possible definition of the user journey. In this case, you might have questions such as:
- What constitutes a “frequent” site visitor?
- What does the user experience look like?
- Does the site remember all favorites or only up to a maximum of 5 or 10?
- Does the list show just links or are there preview images of the page as well?
Read the Story; Look for the Data
Once you have a complete picture of the journey, now it’s time to start finding all of the places where data is involved in the journey. By involved, I mean anywhere that falls into one of 3 categories:
- Retrieved: Somewhere data is accessible and is retrieved for use
- Stored: Somewhere data is captured, and is stored (or should be stored, if it isn’t already)
- Needed: Somewhere data is needed but is not currently available (usually only applies when you are trying to define future state journeys vs current state)
If we use the above story about the frequent site visitor as an example, then we might note the following data components as we think through the story and its implications:
- Visitor ID (Retrieved from a cookie, usually Stored in one or more digital analytics platforms via Javascript tags)
- Frequency of Visit (for real-time understanding of visitor frequency, this would probably be Retrieved from – and updates Stored in – an internal data system vs a cloud-based digital analytics platform, though the latter could be used for analysis/reporting on the frequency)
- Pages Viewed (generally would be Stored in real-time in a digital analytics platform, so that we can then determine the most frequently viewed ones at any time)
- Favorite Pages (could be Retrieved from a digital analytics platform via an API or similar method and sent directly to the page, or could be subsequently Stored in an internal data system such as a CRM or other system that manages customer profiles and then Retrieved from there to display on the page)
It’s critical during the user journey mapping process to involve multiple stakeholders – marketing, IT, product, etc. – in the conversations about the stories. You will often find that there are data components present in your story that you hadn’t thought of, but your colleagues will help you remember as they will each be thinking about the story from a different perspective.
Parting Thoughts
Hopefully, the above examples gave you some good ideas on how to begin thinking about the user journey mapping process. Remember to be patient as you embark on this step; I have worked with clients where it has taken weeks (sometimes months) to map all of their user journeys. It all depends on how complex your business and your IT and data systems are. Once you’re done with this exercise, then it becomes time to take inventory of all of the different data and IT components that make up each of your user touchpoints. I’ll discuss that in the next installment of this series, along with how to create a current state architecture document. Thanks for reading, and please let me know what you think by leaving a comment below or dropping me a note. Till next time!
