As a service designer, I’ve found it is much easier to create a journey map than it is to keep it alive. But journey maps have so much to offer teams. In this post, I’ll give you some tips on how to make sure your map stays useful and interesting beyond its first few weeks with a team.
We explained in previous blog posts how to create journey maps and why journey maps are important in government. Journey maps are often created when a service team starts working together, when the team distills all the knowledge from research and stakeholder engagement into an ‘As-Is’ journey map of the current service.
Through a journey map, team members create a shared understanding of the service experience. The team is often passionate about sharing what they know and curious to see the result, and teams feel a sense of achievement when the journey map is complete. Often, this is the first time they will have a birds eye view of the whole service. But after the initial excitement, the maps rarely see a version 2. They become obsolete whilst the team shifts focus to solutions and prototyping.
But a journey map can be a great asset to a service team throughout all phases of a service. To do this, the team needs to see the map as a live, evolving tool, rather than as a single deliverable.
A journey map can allow a team to zoom out from the small details and look at the whole service they are creating. It can help teams prioritise what to work on next, while staying focussed on the end goal. To realise these benefits, teams should create a to-be map as well as an as-is map. This will help the team imagine what the future service could be and help the team align to a common vision. The building industry takes a similar approach by creating a blueprint of a building before they start building it.
In this post, I want to share what I have learnt on how to keep a to-be journey map up to date and useful for the team throughout the project.
Allow a to-be journey map to change and grow over time
A to-be journey map is never a fixed or final product. It should evolve with the service, as the team prototypes features, iterates ideas and acts on research findings. The journey map should be one of the ways the team reflects on and changes its shared vision for the service.
As the team starts to prototype and test ideas, initial ideas will become more refined, some ideas will become obsolete and new ideas will be generated. The to-be map of the future service will quickly get out of date if no one takes ownership of making sure the team is using it, updating the content and adding new insights to it.
Assign an owner to the journey map
In order to keep a map updated and relevant, someone needs to be responsible for making sure the map is still adding value and ensuring the team keeps it up to date. This person might do things like bring the map to meetings, refer to the map when making decisions, talk new team members through the map and remind people to update the content when it changes.
If your team has a service designer on it they are often the ‘natural’ owner of a journey map. However, if there is no service designer on the team other types of designers, product managers, delivery managers, business analysis and user researchers can take ownership of a journey map. The reason it works well for these roles is because they have oversight of the development of the new service as well as the authority to implement new tools and ways of working.
Owning a journey map doesn’t mean having the sole responsibility for updating it. Service teams should share this load, as long as team members have clarity of what is expected from whom – for example, new user insights should be added by a user researcher.
Some people might be afraid to make changes to the map, or feel they don’t have the right to if it has been created by someone else. The owner’s role is to ensure every team member is aware of how to use the map and what to use it for. They should make sure people have clear roles and responsibilities on how to keep the map up to date and make people comfortable using it.
Agree how you would like to use the journey map moving forward
The purpose of a journey map changes throughout a project. It is up to the team to decide if and how using a journey map will add value to the team.
Maps can be used to show what different teams are working on or to help prioritise which service features will be built next.
Incorporate the journey map into team rituals
Identify key rituals where it will be beneficial to use the journey map. For example, you might decide to use the journey map in sprint planning to prioritise work. Using the journey map in key rituals ensures that everyone is familiar with it and is engaged.
Don’t be afraid to hack the map to make it do what you need. You might decide to add a row where you can record which team members are working on what area of the service.
Keep it where most team members can see and use it
It is important that the journey map lives where people will use it the most. This could be in either a physical or digital form. If the team is based in the same location use, a physical map can be helpful and dynamic. If digital is more convenient for the team, then the map needs to be created in a tool which most team members can use – as opposed to specialist software that only designers know how to operate. I have worked with teams who use Google sheets or Microsoft Excel to create and distribute their maps.
Please let me know in the comments of any other tips for how to make sure your journey map stays alive and useful.
From 3–7 February, Services Week 2020 gets people from all parts of government to discuss how we can work together to deliver end-to-end, user-focused services. Follow #ServicesWeek and join sessions in person or remotely.
If you work in the public sector, take a look at the open agenda and find a session in your area that interests you.