What’s the Purpose of a Journey Map?

This is the third in a series of writings on experience. I will draw on my academic and professional experience as an architect/designer and attempt to pair that with some of the external resources, influential figures, and challenges that I have run into along the way. I’m trying to figure out what makes a design practice at this particular moment in time.

But at the moment I’m trying to figure out what form should the Journey Map inhabit within an organization.

_______

First, what is a Journey Map? In my experience, a Journey Map is a method designers and teams use to express qualitative data about the delivery of a product or service comparatively across a timeline. In order to under the cumulative effect and sequence of these qualitative moments as well as how best to change, add, or modify each moment, It is also necessary to be able to understand how a specific customer or customer persona will navigate this timeline of events to achieve a desired outcome. This comprehensive documentation should denote the background for the User Experience that a customer will receive.

Journey Maps can be used internally as for organization and understanding tool for a company and externally with a client as a proof of work and engagement tool.

Journey Map as Customer Facing Tool

As a method of organizing thoughts and fostering client engagement journey maps are a tricky offering. While they can promote sense making between business and client they are also an easy way to get lost in assumptions and details that don’t matter to the client. Typically they are only necessary for complex rollouts or managing product or system ecosystems in which new aspects are frequently being added, modified, or taken away.

Because of the potential expansive nature of Journey Maps, they don’t yield themselves to being consumed as bight sized directives that offer quick agency to stakeholders but are primarily used as diagnostic tools to set up and explain a scenario to both design teams and clients who then must, on their own, assess the sequence of events through discussion or prototyping before editing the journey. If all parties buy-in, Journey Maps are an extremely effective tool for organizing concepts and meeting project goals as well as loftier objectives such as mission statements.

Journey Map and Organizational Structure

In most organizations marketing, product, and design teams make different parts of what could combine to become a journey map. In many ways a journey map is the interaction encyclopedia for a product or service, so it would make sense that all of the elements from each department could an should come together in one place. The believe the biggest questions are when and how?

I think in an evolving company where the executives are trying to bring together departments that have been historically siloed within their company, one method could be to force each department to create the journey map together before further work on the project details can be started. Obviously this requires enough information to exist for the map to be created in the first place, as well as some version of a product or service for a customer to engage.

Let’s say then, that for a new product or service, a journey map and its timing within the development cycle can be planned to take place strategically at a moment when all pre-work is completed, when each department has enough information to create a skeleton of their inputs, output, and department forces. These skeletons can be put together to create a larger infrastructure to shape the movements that each department with focus on in detail to delivery their primary function to the company. The infrastructure, or the journey map, is then perpetually modified and added to by each department as progress is made. The living document is also used to determine deadlines for milestones and key functions within each department and for the company as a whole.

To restate this entire process another way: There is an initial push for amongst all departments to build a skeleton journey map for a product, product line, or service that will then be modified asynchronously . This method would need to be scalable so that it can graft on to projects of different sizes in accordance with strategic priority with the company’s directives.

But what about existing projects? Or situations where new initiatives are not as beneficial as legacy ones? While it might be difficult to insert this technique into an ongoing project, it is likely that the resources to construct it already exist in some form siloed within the various departments of an organization. It will be like untangling a working cable setup to an old stereo system that has always just worked, but no one really knows how. If capacity permits, reverse engineering a journey in this way will pay off immensely as decisions made with legacy products and services in mind will likely involve high level reshaping of how to move forward and decisions that need to filter down to end user. Because it is very difficult to keep this legacy within the mind of any organization that is going through its generations of employees, this institutional knowledge is a precious resource that could be preserved within a Journey Map for both designer and client.