Mapping experience through journeys
To get into the topic, let’s take a fairly emblematic example. Of course, any resemblance to real events would be pure and accidental coincidence 😀
Journey = Stakeholders + touchpoints + interactions
In 2015, a ski area launches a major transformation project, aimed at digitising the resort and the mountain tourist experience. Among the major workstreams is a mobile app project whose promise is to “put the mountain in your pocket”.
In the rollout strategy for the app’s MVP, the choice is made to involve the staff at the lift pass desks. Their mission is simple: act as relays for this new app with users. They are one of the strategic touchpoints of the skier journey. The idea seems perfect.
On a peak Saturday, as happens every season, the waiting time at the pass desks explodes. The queue thickens, people get impatient. Thinking he’s found a solution to clear the queue, a staff member takes the initiative of handing out blank magnetic cards, to be loaded “directly in the app”. The idea immediately appeals to people and the queue clears very quickly. Action, reaction.
Except there’s a problem. Like any MVP, this app doesn’t do everything. In particular, it is impossible to buy a new lift pass. But the staff don’t know that, because they haven’t been told much about what the app does or doesn’t do. We’ll leave you to picture what comes next, with a nice boomerang effect.
Three key ideas on user journey modelling
The previous example is a textbook case, which on its own illustrates the 3 main ideas of our argument:
1/ Modelling journeys is necessary and creating a model means making choices
2/ Experience must be looked at as a whole and not only for end users
3/ The journey is a shared reference and a decision-support tool for project teams
Why look at user journeys in UX?
The need for a journey view in UX
Our work is about designing products and services that fit intelligently with users’ needs. We need to step back, understand the context in which the solution we’re designing sits. What other way than a journey (more or less detailed) to position ourselves within an overall view of the service and how it’s delivered? None.
Modelling is about trying to move from the complexity of a dynamic world to a synthetic, simplified representation that gives an overall view. Intercepting every flow and processing every stimulus from the world around us is impossible. Our brain reasons on simplified models of the world (opens in new window) and yet it manages to make sense of the world.
Modelling means flattening an experience onto a page, to try to outline as much of it as possible. A bit like screen printing.
Mapping the experience is, broadly, making the choice (a slightly arbitrary one) of breaking down the activity into sequences on the horizontal axis and lining up against them elements tied to the experience on a vertical axis. Depending on what is being studied and the aim of the exercise, the rows will vary, generally with needs and pain points set against opportunities. In short, it’s a table.
A basic model is better than no model at all
And as we covered in an earlier article, there is the need and the representation of the need. Creating a model means distorting reality, and that’s not a problem. The model isn’t there to be perfect, nor is it exhaustive or fully accurate. Some things are heightened, others are toned down. The elements you want to surface inevitably go in, just as the reader will see what they want to see or what makes sense to them. You have to accept this, embrace it, because that’s what the process requires: modelling is choosing, and choosing is giving up.
The other very interesting element tied to the notion of model is its systematic side. One of the first steps is to list the stakeholders. Logically, you will look at those who contribute one way or another to the experience your user is going through. This exercise alone will let you identify lines of work and conversations to have with the direct or indirect actors who contribute to the satisfaction, or dissatisfaction, of your users.
Questions to ask to lay out user journeys
If there is only one thing to remember, it is the fact that laying out journeys is a complex exercise. The few points that follow show how demanding it is.
Representing user journeys
As we said, modelling experience is trying to capture the complexity of the world on a sheet of paper. This limitation of a two-dimensional space forces choices. For example, you can’t represent both space and time in journeys. Picking one comes at the cost of the other.
Naturally, you immediately think of the link between personas and user journeys. Being specific surfaces more opportunities than staying at a very generic level. You can position the details of a type onto the same journey. That brings a finer level of detail, which also helps the project teams take ownership of the deliverable.
Not to mention cross-channel journeys, which mix digital use with the physical, tangible world for example. Modelling them lets you grasp questions of breaks in the experience. Here again, adding a dimension makes the model harder to read.
Focus, frames of reference and user journeys
Modelling a journey also means making a choice on the focus, to offer a unified representation of a portion of the world whose key components you want to synthesise. You have to bound the journey in time, since being perfectly exhaustive isn’t possible. Deciding how far back to go upstream and how far to go downstream is also part of the exercise. The level of detail is often consistent within an experience map, to make it easier to read. And yet you realise that some moments deserve more detail. It can be useful to mix the formalisms used to represent experience (e.g. storyboard, movement flow) to keep this zoom-in / zoom-out option open.
Finally, we constantly move from one journey to another while using products and services every day. Sometimes everything is well signposted, and sometimes it’s frankly the desert. Users’ mental models are shaped by the journeys they come across. Standardisation through use happens in particular through the types of journeys we go through. That fully justifies the importance of benchmarking and the choice not to limit yourself to direct competition. Be careful, though, of the counter-productive effect, with the risk of flattening everything by replicating the same journeys endlessly. You need to know the references, but not copy them.
Grasping the experience across the whole user journey
The experience map as we’ve known it since Adaptive Path’s work for Rail Europe is one of the formalisms that broadly serve as a reference for journey modelling. We have used it a lot too, but less and less for some time now. It offers a kind of necessary flattening, but not a sufficient one. You could even say that it isn’t the right candidate to represent the experience as a whole. It is limited to the front-stage touchpoints with end users. The format is incomplete, in that it under-represents the internal users who make the system, in favour exclusively of those who use it.
The end user is king
Not quite. We mostly work in services. So we step into a sociotechnical system (human–machine–human relationship). And the approach has to involve users on both sides of the machine. Historically, user-centred approaches emerged in highly technical systems (e.g. cockpits in aeronautics, supervision desks in nuclear power plants). In this kind of human–machine interaction context, taking a “purist” approach focused exclusively on the end user is perfectly defensible.
Aren’t user-centred approaches turning into a self-caricature? 🤔
By dint of repeating that the system has to adapt to the end user, the message has become a bit distorted. It was never about limiting ourselves to the end user. So we forget that in any system with a social dimension, there are internal or intermediate users who will contribute to delivering the service. They are also fully part of the experience. We’ve moved from a tech-centred view to an end-user-centred view, sometimes absolutist and senseless.
The nonsense of FUX*
*Final User Experience. Yes, after all, it’s very fashionable to coin new expressions in our field.
For example, we worked on a project around the management of HR requests within a public-sector organisation. Concerns about employee satisfaction led the HR team to launch a UX initiative. Their reflex? Going to meet employees to better understand their needs. Fine. But the needs of the HR team members to carry out their mission, who is worrying about those? Nobody. And this example from the institutional world is far from an exception.
Thinking that we’ll be able to evolve the visible part of the experience without a fine-grained knowledge, a clear view of what is happening behind the scenes, is a fantasy. A change at the front impacts the back, and vice versa. These are two sides of the same coin, and it’s this whole that needs to be unpacked and modelled.
“Yes, but that’s not us, it’s…”
The other element that seems critical is the importance of going up the value chain and involving the actors who contribute, more or less directly, to the experience we care about. We’re talking about the strategic, tactical, but also operational levels of the system. That is what we had the chance to do for the modelling of the arrival-day journey at a ski resort.
The project, led by the tourist office, brought together resort actors as well as private and public service partners. The goal? Broaden the perspective across the ecosystem. The result? An overall view that lets us:
- question interoperability in the broad sense,
- foster mutual knowledge,
- dismantle certain beliefs,
- spell out implicit procedures,
- identify dependencies,
- spot points of desynchronisation,
- spot points of synergy, and so on.
By doing this work with all these crossed perspectives, we were able to identify a wide part of the system’s components. The opportunities identified concern various levers: human, digital, tangible, infrastructure and organisational. That is the principle of a systemic, all-encompassing approach, run through the lens of the user journey.
The user journey = the shared reference!
For users internal to the system, we go from the sum of individual experiences to a result that focuses on all the key elements that support the experience. Sharing a consistent level of knowledge of the exploration data and actively involving people in the modelling process is one of the keys of the approach. It’s about sharing the choices, the trade-offs, what is in and what is out of the model, and so on. The work doesn’t stop with the handover of a nice deliverable. Following the take-up, helping with the ownership and the upkeep of the produced model is very important.
Modelling the journey means creating a shared language that brings together stakeholders and operates at the level of the experience lived by the user. It’s about defining a grammar that helps build common ground. And for the silo organisations we work with, that makes a lot of sense.
Taking action thanks to the user journey view
Formalising journeys gives an overall view of the components and their interactions, lets you step back and spot patterns of dependency, but also shared opportunities. The journey view lets you adopt a more effective global, coordinated approach. For example, the work done with the Paléo Festival in Nyon around the festival-goer journey is very interesting.
The sectors in charge of welcoming and security work in concert to gradually settle festival-goers as they progress along their journey. The aim is simple: ensure the right level of information at the right moment. Without going into detail, this kind of joint approach is made possible by a shared representation of needs, an optimisation of the touchpoints and the festival-goer’s “bandwidth”.
Finally, the user journey lets you anticipate the future state of the world (nothing less). It is a tool that will support the shared situational awareness of all stakeholders. Each person should be able to find in it the elements that let them rebuild a representation of the system and of the situations they care about. It is a tool for measuring impact before applying decisions. It lets you pre-assess the impact of a change, whether in the organisation, in the front-stage part of the journey, or both. Modelling journeys means giving yourself the means to prioritise, arbitrate, plan and roll out your strategy in an informed way.
So, what does a user journey actually look like?
We don’t have a universal or absolute answer, but we can show you what we’ve been testing for several months. As these are client deliverables, we can’t give the detail of the content, but we can talk about the structure:
On the vertical axis, you place layers of system users (everyone, not only end users), like a service blueprint. On the horizontal axis, you propose a breakdown by phase, like an experience map. In the middle of all this, you place a model of the activity, whose form can vary depending on the topic. We really drew on what exists in this area (flow models, activity diagrams, mediation of activities, and so on).
It’s a hybridisation that wasn’t necessarily intended, but emerged from our clients’ need for an overall view and a global mapping. We have had the chance to test this kind of formalism in several fields (e.g. for an SME wanting to put together a new offer, for a metropolitan area’s community-life portal, or for a conservatoire on a digital platform project aimed at the general public, students, teachers, administrative staff and partners). This formalism is definitely not perfect, like any model. It is a heuristic, in that it has shown a strong ability to bring teams along when we have put it into practice.
Takeaways
Beyond the main ideas laid out above, here is a very schematic summary:
1/ Modelling journeys makes UX projects more coherent.
Really. Otherwise, you end up sinking into solving microscopic problems. Clearly, UX isn’t limited to producing wireframes. We need to step back and carry an overall view in order to think of products and services as a coherent whole.
2/ We need to demystify the voice of the end user
The awareness of user-centred approaches has reached a high level. That’s good. The take-up and the implementation, on the other hand, are sometimes nonsensical in how exclusively they turn towards the end user, at the expense of all the other components of the system, including internal users.
3/ For the client, the process matters as much as (if not more than) the deliverable.
Modelling journeys lets you anticipate the organisational side while handling the functional question. Journeys provide a synthetic view of things, so that everyone can rebuild their own representation and link their issues to those of the group. All of that lets you prioritise improvements on an informed basis.
4/ New deliverables need to be invented!
Let’s stop going through the motions and congratulating each other with our experience maps, personas and wireframes. Let’s evolve our practices, experiment and share.
There is still a lot to say about user journeys in UX and service design. If you’d like to discuss it with us or get started with this kind of approach, we’d be glad to talk.
