Last year I wrote about my career transition from web designer to product designer, including my observations on the differences in mindset. One thing I didn’t mention was the mental block I encountered during the transition. Being trained to work fast in the marketing world for almost a decade meant I wasn’t able to think and design like a product designer right away.
I tended to jump to solutions quickly without thinking much about the problem, which of course led me to hit rock bottom every time my manager told me I wasn’t solving the right problem, or one that users would find most useful. So I started to ask myself if there was anything I could do better. It wasn’t until my teammate said ‘what if you start with a user journey map?’ that everything changed.
I began to embrace user journey maps in my design process and quickly found myself easing into the role. It was as if someone waved a magic wand and shifted my mindset to adopt a user-centric approach to design, a concept that I didn’t truly understand before this. Since that point, I began using them in my design process, no matter how big or small the problem may be.
User journey maps are not only a flexible tool that can be used for many purposes, they also help me stay relevant to users and the problems I’m trying to solve. Ultimately, they have continuously trained and empowered me to become a better product designer. Here’s why I think every product designer should embrace user journey maps.
1. Understand the broader context
Building empathy with our users is the key to developing products that people need. While this cannot be done without any research, having a clear visualisation of all user stories in a journey map can help you develop a deeper level of empathy. This is because a journey map gives you visibility of the problem in a broader context, as well as the cause and effect relationship of every interaction in that journey. This reduces the risk of developing solutions that are too narrow in their focus.
For instance, you may want to increase the security level of an online banking tool due to increasing cyber attacks. You then focus on increasing the layers of protection in the log in process, as that was defined as the most vulnerable touchpoint. But sooner or later, you discover that making users spend 5–10 minutes logging in with multiple layers of authentication isn’t a desirable outcome, as it can stop them achieving their goals (despite the good intention to protect their account).
This is because logging in is the immediate goal, not the end goal. Users want to log in for multiple reasons. For example, they may want to pay their overdue bills to avoid penalties. Therefore, making a payment is the end goal. If we can design with the end goal in mind (even if it’s multiple steps ahead in the journey) then we can reduce user frustration in the login process. In other words, the solutions that we end up developing will have less focus on just the task of logging in itself. A journey map can give you this visibility of the broader context, so you can understand what matters most to users and design with their goals in mind. This makes it more likely that you’ll create solutions people actually need.
2. Reveal untold opportunities
‘How might we add value above and beyond the existing product?’ is a common question in the product world, and one that journey maps can help us answer. Every touchpoint in a journey timeline represents a layer of insights. The more touch points we uncover, the more insights we can gain and the deeper they become. As layers of insights continue to build, we don’t just learn about users’ end goals, but also discover their unmet needs in the product. Usually needs that they haven’t even realised they need or want.
Let’s look at that previous example. We could continue working on satisfying users’ needs by minimising the time and effort to log in, which is great. But if we examine beyond what they tell us about their end goal, we can uncover other pain points they have outside the product to inform us about value-added opportunities. For example, if they are constantly forgetting to pay their bills on time, there may be an opportunity for the product to help solve that problem.
Perhaps being able to set up recurring payments so that all bills can be paid on time, or reminding them about payments they often make at a specific time, could be useful for users. Users may not know they need this, but they will be delighted if it’s available and can make things easier for them. This is how untold opportunities can be identified once we have a good grasp on the stories of our users.
3. Make prioritisation easy
Sometimes when dealing with a tight deadline and several problem statements that have equal weights of severity, prioritisation can be challenging. Other than measuring its market viability, technical feasibility and user needs, I often circle back to the user journey to investigate its impact. This is because I can identify different touchpoints where similar pain points occur and their interrelationships, which builds up another layer of consideration when evaluating the impact of solving a problem.
Say we are dealing with problems A and B in the above journey map, which both have an equal weight of severity and require a comparable amount of technical effort. Looking at the journey map, we can easily identify that solving problem A would significantly deliver more value to both users and the product, as compared to B. This is because problem A is the butterfly effect to other pain points along the journey. It simply means using the same amount of effort to address more problems.
Sometimes the frequency of similar problems can also be measured in a journey map. This is a simple example to illustrate the concept — in real life, it is important to build up the coherence between one problem and another in order to get the full story. This is also the reason why I like to map all relevant research insights including their actions, thoughts and emotions onto my journey map, as it gives me a holistic view on all problems and the connecting reasons behind those problems.
4. Enhance storytelling in teams
During my early days as a product designer, I used to find it challenging to reach a consensus with stakeholders and developers on matters relating to solution outcomes or design trade-offs. Despite involving them early in the design process, design would still get the backseat when product decisions were made. While I championed for the users, developers championed for the codes, and stakeholders for the costs.
Then one day while I was analysing a journey map, I had an epiphany. If user journeys helped me understand product design thinking, wouldn’t it also be beneficial to use them when communicating my thinking with the product team? I decided to give it a go.
The first time communicating with the team using a journey map didn’t make a difference straight away, but at least people were starting to ask questions about the users and their motivations. As I continued to run design meetings using the journey map, my team became more confident about contributing ideas to the design, as the visual aspect of the journey had simplified my design rationale. Everyone understood the story we needed to tell.
This made me realise that while I had previously involved them early in the design process, they didn’t necessarily understand the user’s pain points. The journey map gradually became the centre of our conversations and we started to see healthy collaboration among the different disciplines in the team. Making the design process transparent also helped crystallise the value of design in the product, which was a big win for me.
Improve the journey, not the map
Like any tech product, a journey map is a living artefact that will continuously evolve over time. It will never be perfect or finished, because the insights we gain will tell us more stories about our users over time. Even when I have no insights to start with, I still tend to scribble out a journey map based on whatever information I can find, then identify the gaps that I need to investigate during the research process. This is to ensure that I will have all the information needed to fully understand the users.
As the journey map evolves, I uncover more detail around the behaviour of our users and how it is triggered by their short and long-term needs (the ones they’re aware of, and the ones they aren’t). Most importantly, I can see the bigger picture and develop a deeper empathy for users. I can find answers that lie at the core of every product problem: what is the real problem? Who is affected? Where does it happen? Why does it matter? I can think like a product designer.
Want to start using journey maps in your design process? Check out this great article on Journey Mapping 101 from NNgroup, or use their journey map template as a starting point to create one. Remember, a journey map should be fleshed out through the lens of your users and based on empirical evidence.