In our last installment, we discussed the value that empathy maps and personas can bring to your project. Your users are now at the forefront of everyone’s minds, and the team is ready to learn about the problems that need solving. But what next? How do you begin to determine what changes need to be […]
In our last installment, we discussed the value that empathy maps and personas can bring to your project. Your users are now at the forefront of everyone’s minds, and the team is ready to learn about the problems that need solving. But what next? How do you begin to determine what changes need to be made, what should stay the same, and where there are opportunities for improvement that not even your users have thought to request? The answer is a journey map.
Journey maps can be created a few different ways and can look very different, depending on what makes sense for your project. Today, we’ll discuss a basic journey map. As you get more comfortable, you can experiment with different models. When determining how you should begin your journey map, it’s best to start with a simple question – are you mapping out the current state of an application, or are you mapping out a future state of an application? Mapping out the current state of an application is closer to workflows that most analysts use as part of their daily work, so let’s start there.
When redesigning an application, figuring out how the system works currently is the first step in understanding your project. A journey map can start the same way – start with what you know. A good way to begin this process is by talking to a subject matter expert, and of course, exploring the application yourself. At this stage, the journey map should just be how the application works, devoid of any ideas for improvement or new functionality. I recommend using a whiteboard or sticky notes to map out the current state. Throughout the creation of the journey map, you’ll be adding more and more information, and it’s easier to add something via a sticky note than change an entire Visio diagram.
Once you have mapped out the current workflow, start a new row beneath the current state to add thoughts and feelings your consumer is experiencing as they move through your site. This is where your research and personas/empathy maps come in handy. You already have a good idea of what pain points and desires your users have, and now you can attribute them to specific points in the workflow. This will help you zero in on areas of your application that need more attention. This could mean changing the workflow, softening the language, or something as simple as more graceful transitions from page to page. This can even uncover areas where the user is experiencing pain because your application is missing a feature – so not all pain points will align with a step in the current workflow.
Finally, add a third row that lists opportunities for improvement based on what you’ve learned from the current workflow row and user feedback row. Let’s pretend you are redesigning a retail website. On the website, there are 15 different ways to filter women’s shirts. After conducting user research, you find many users feel overwhelmed by the granularity of the search and have trouble navigating the page to find the right category of shirts. One opportunity could be a new taxonomy that creates broader categories for women’s shirts. Another option is the introduction of new tools like sorting and filtering to help users scan through the search results. Maybe the number of categories are fine, but the language doesn’t make sense, and that needs to be re-worded to something more intuitive to your users. There can be many opportunities listed for the same pain point. Remember, we’re not trying to define a solution at this point, but rather brainstorm ideas for ways the pain point can be alleviated.
Don’t forget to add notes of what users like – this isn’t just to uncover areas that need work! It’s important to note where users are finding delight in your application too. These experiences that create delight can be used to study what your users respond to and should be noted as things you may want to avoid changing in your redesign.
You’ll use much of the same process to map out a future state journey map, but it’s a bit trickier without having a current workflow to help get you started. In these situations, you’ll need to rely even more heavily on your subject matter experts and user research. Future state journey maps will likely only have rows for the future state workflow and thoughts/emotions you hope your user will have at that point in their journey. However, if you are working on an agile team (and hopefully you are!), you could still include an opportunities row, but you can tailor this row to be specific to items that are nice-to-have enhancements that the team can work on after you launch your minimum viable product. There is also the opportunity to add new rows based on your project’s needs. For example, if it is helpful for your team to include a row that provides an explanation for the creation of a page or action, feel free to add that!
Mapping out how you want the user to think and feel while using your website is crucial to providing them the best possible experience. If we can correctly gauge their needs and understand what they want, their positive experience with the site will likely carry over to their perception of the overall brand. It’s important that the journey map conveys to the organization what is important to the user as they navigate the website, which isn’t always obvious to the organization. The point of the journey map is to gain understanding, so add and tweak the process as you see fit – it’s perfectly normal for no two journey maps to look the same.
While journey maps are great tools to help you, your team and your stakeholders visualize the new workflow you will be implementing, the greatest value of the journey map is the process of creating it. By working through the entire process from the perspective of your users, it helps everyone understand and buy into what changes you are proposing because they understand where the change is coming from, and why it’s necessary. In our final segment, we’ll discuss how to validate your project has been successful – by testing with actual users.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...