The user journey map is a great way to understand and address customer needs and pain points. A user journey map is a visualization of the process that a person goes through in order to accomplish a goal over time and across channels (Gibbons, 2021). It does not only contains the user tasks but also his/her affective experience (thoughts and emotions), which makes the journey map truly powerful. The terms ‘user journey map’ and ‘customer journey map’ can be used interchangeably. Both reference a visualization of a person using your product or service.
Customer Journey Maps can also be created to either i) represent anticipated journeys, called the expected journey; or ii), represent the actual journey, which aims to describe how the journey was “really” experienced by customers (Følstad et al., 2013).
Følstad, A., Kvale, K., & Halvorsrud, R. (2013). Customer journey measures-State of the art research and best practices.
Actor: The actor is the user who experiences the journey. The actor is who the journey map is about — a point of view. The map can include such information as age, occupation, location, as well as details like what device they’re on and what task they want to accomplish. It is advisable to create user journey maps for each of the target users, as their goals and expectations could differ.
Scenario and expectations: The scenario describes the situation that the journey map addresses and is associated with an actor’s goal or need and specific expectations.
Phases: Journey phases are the different high-level stages in the journey. They provide organization for the rest of the information in the journey map (actions, thoughts, and emotions).
Actions, Mindsets and Emotions: These are behaviours, thoughts, and feelings the actor has throughout the journey and that are mapped within each of the journey phases.
Insights: Opportunities (along with additional context such as ownership and metrics) are insights gained from mapping; they speak to how the user experience can be optimized. Insights and opportunities help the team draw knowledge from the map.
1. On top of the Hierarchical Task Analysis it adds the affective and cognitive part. Rather than only focusing on the functional elements of the steps, it addresses emotion in design: it maps out the user’s expectations, questions, thought processes and feelings when using the product.
2. Through thoughts and emotions it is easy to see the problems of the users, which shows how the system should be further refined (i.e. opportunities), who is responsible for the development (i.e. internal ownership), and also allows for prioritisation within the team.
3. The process of creating a map forces conversation and an aligned mental model for the whole design team, which may even be more valuable than the finalised map itself.
4. Understanding the user’s journey – their feelings, motivations and experiences – can help you design a user interface that guides them towards meeting their needs.
How It Works
Think about the approach you want to take:
- Do you want to focus on currently available product and illustrate the current problems end-users may encounter, or do you want to think about an ideal experience?
- Do you already have the data from research, or do you need a solid foundation first that will be validated later with the user insights?
Draw the skeleton of the journey map (actor, scenario and expectations, phases, actions, thoughts, emotions, interaction, opportunities). Templates can be found online (see Kaplan, 2006), but there is no universally accepted version of the map; it boils down to the creativity of the team of how unique they want to make the map. The single most important thing is to illustrate all the key elements of the map described above.
Once the skeleton is ready, the process starts with Zone A:
(1) First, agree on the actor(s) the team wants to cover. Everything that comes after has to be created from the actor’s perspective. As a rule, one actor is covered in one journey map.
(2) Scenario and expectations put the whole map into context. Note that even these two can alter between different actors, but only one scenario should be elaborated in one journey.
The next part to be filled out is Zone B:
(3) Think about the main phases the actor would go through during the journey. They should be worded as verbs to reflect what the user is doing in that set of actions, again from the user’s point of view.
(4) List the set of actions, thoughts (4) and emotions (5), categorized into the high-level journey phases.
The last zone is Zone C:
(7) List the possibilities to improve the journey (opportunities) consequently, one can assign priorities to the functions to be developed.
(8) Ownership and metrics can be added as well, the former facilitates the clarity and awareness of the internal responsibilities to develop the particular functions.
Unmanned Traffic Management (UTM) application prototype for mobile features
The journey mapping was applied in a case study that aimed to create a simple mobile application design for drone pilots within U-Space environment. The motivation came from the problem that Unmanned Aircraft Systems (UAS) operators could be using multiple applications to be able to conduct their flights, submit their flight plan and monitor the status of the airspace of the vicinity of their mission. The use of these applications in parallel may have a significant safety risk which has to be investigated to ensure the safe and efficient operations.
Prior to the journey mapping, the design team created a Hierarchical Task Analysis (HTA) and run couple of usability tests. Therefore the journey map was:
A mixture of future state and current state: Whilst during the activity of creating the journey map the designer team had existing problems with existing apps in mind (current state), this journey map represents a forward-looking scenario. New ways of interactions for emerging roles and responsibilities had to be defined. Therefore both the HTA and the subsequent journey map was a visualization of an ideal journey (future state).
Research-first: After the usability tests the team created the journey map from scratch, but the actions were taken from HTA and have been aligned with prototype. Since the team already knew the user insights by the time the map was created, the process can mainly be regarded as “research-first”- all the thoughts, emotions and opportunities come from real-life testing.
Based on the outcomes of the usability test it became evident that there were two types of users;
- one who clicked through the prototype fast and hasn’t given too much thought to minor details;
- and the other who reads everything, analysed all the small details of the interface and had a lot of comments throughout the journey.
The apparent difference prompted the creation of two journey maps each describing one type of user. The two actors presented in the journey maps are called Matt and Sophie, they are both drone pilots whose journey of using the UTM application during a specific event is shown below. Sophie belongs to the first group and has a rather intuitive personality, whilst Matt is more of an analytical type of user and who is very detail-oriented.
The event that is covered in the journey maps, describes how the two drone pilots execute a foreign object detection (FOD) mission on the runway, within the controlled traffic region (CTR). An arriving aircraft in emergency leads to the suspension of the drone activities in the CTR, thus the drone has to return home immediately. After a while the operation can be resumed and this is what the scenario within both journey maps is about. This scenario requires the drone pilot to create a new flight plan and fill out a pre-flight checklist prior to resuming the mission. To accomplish the goal, the drone pilot has to interact with two software: the app from the drone manufacturer to control the drone and the UTM app to file the flight plans, fill out checklist, monitor the airspace and keep contact with air traffic control (ATC). To sum up, the focus within the journey maps lies on the submission of the flight plans when resuming the FOD mission.
The user journey maps have been created in MS Visio. The design team that took part in the usability test as observes was split into two groups – Team Matt and Team Sophie. Each team illustrated the journey for the according actor.
The two examples below show two slightly different ways of filling out a journey map. Matt’s team added the thoughts and emotions right next to the actions. Sophie’s team tried to stick to the vertical rows and separate these visually. These variations show that journey maps can be easily customized.
From the application of the journey maps for the design of the UTM application the following design implications were identified and should be implemented in a second iteration:
(1) Workflows and input: Show an overview of the steps for multistep actions.
Issue: “Where do I start my journey? How can I create the flight plan and then take off?” These were the questions participants oftentimes were wondering about during the test. This implies that the app did not show the steps to create a mental model for the process.
Solution: If we think about design patterns, an alternative solution could be to show the steps in a collapsed content sort of way: the steps are listed in their separated fields and if the user taps on the field, it takes him/her to a different page which is not actually a completely new one that would take extra time to load.
(2) Symbols, buttons: Use clear labels to tell users what to do next.
Issue: We had a button for Landing. It looked like a download button, hence people got confused. It was the only main button on the screen so they went for it, but they all recited that the button looked weird and out-of-place.
Solution: The participants recommended to spell out the actual letters “LAND” on the button, thus creating “call to action.
(3) How to save the checklist: Save/Submit button at the bottom supports normal flow.
Issue: Once the end users finished reviewing the pre-flight checklist, some of them were surprised that the “Save” button was in the upper right corner.
Solution: The users would have expected it at the bottom, so when they completed the list they could have just easily clicked on it.
(4) Navigation & Information Architecture.
Issue: The prototype had persistent bottom navigation, i.e. it did not move as users scrolled. There were however pages where it disappeared. This happened at one point when the user took off with the drone.
Solution: One user expressed the need to still be able to access the navigation bar for checking the weather or messages during the flight.
(5) Content: Make difficult content easy.
Issue: The critical information related to flight restriction was an in-app notification. The only problem was the way the text was worded. The author tried to convey a complex information with the most important part being at the end. But people rarely have the time to read carefully a whole paragraph on a mobile device.
Solution: It’s best to strive for short sentences that start with the essential.