The double-usefulness of user journeys
In my last post I looked at personas and how they help us design products and services that are centred around the user. But once we’ve worked out who our users are, we then need to work out how we create great experiences for them. Our next step is to look at user journeys.
What is a user journey?
A user journey is a set of steps which a user takes on your website/app/service in order to accomplish something. User journeys can either describe how things work at the moment or how things could work in future. Like personas, they usually come out of the discovery phase of a project and they help develop a shared understanding of what it is you’re building.
By making the steps that a user takes clear, a user journey helps us understand in more detail the needs of the user and what might cause them pain as they try to accomplish their goal. They help us work out what features are needed to meet the user’s needs and remove obstacles. They also help us UX designers and developers communicate our thinking to stakeholders.
Making use of user journeys
We have two main uses for user journeys at Manifesto.
1. Analysing pain points in current websites and giving recommendations
On strategy projects, user journeys are part of the analysis we do. We work with the client to understand how their users are currently interacting with the product or service. For example: the donation funnel, booking system, or sign up to fundraising events. In the process, we create user journeys which reflect these current paths.
The main goal here is to understand whether the journey is working and healthy. Google Analytics can help us: by reviewing metrics like bounce rate, exit rates, volume of unique page views, navigation summary and tracked events, we can determine the flow through the journey and devise user tests to check our assumptions about what’s going wrong.
For example, if we see a high drop-off rate between a landing page and a ‘sign up’ page, maybe something is not working in the landing page and the user needs more information. We might then decide to look at goal-based user testing to find out what’s going on. Similarly, if we see high exit rates from a form page, we might look to obtain heat maps to show how users are interacting with the form.
How do we do it?
We can keep the user journeys pretty low-fi here – arrows, boxes etc – as we’re not using them to build anything. The main thing is communicating to the client where the problem lies and how we can help them fix it.
2. Connecting the research/strategy phase to the build phase
Once we’ve created our personas, we already know who is going to use the product and what they’re trying to achieve. We now need to understand how they’re going to use the product and how we can help them accomplish their goal as quickly and easily as possible.
User journeys create a focal point for discussions both within the team, and between the team and client, about what we need to build in order to generate the most value.
- They help the client to see the overall picture, to understand what we are trying to achieve and to give feedback on our approach;
- They help the team to work out what features are required and to build a backlog;
- They give designers a clear picture of what screens we need to design and the most important elements in each;
- They help developers determine what functionality is required and the best way to implement it.
How do we do it?
For the first step I like to draw the flow of the user through the product with boxes and arrows.
When it’s a big project I prefer to do it with the team and even the client. That way, everyone gets to have their say about how to make the user journey as effective as possible and we can all reach consensus on a single vision.
When it’s a small project, like a campaign with a very specific goal (e.g. sign up, donation) I usually skip the boxes part. Instead I go straight to sketching wireframes and mapping the journey with these. We can then test out this sketched product by “using” it and checking that we are not missing anything.
We then usually put the user journeys up on the wall in the office, where we can add post-its with comments and ideas. As the project evolves, we print the designs and add these to the journey as well.
Later on, we use the user journeys as the basis for creating detailed experience maps. More on those soon…