There are countless ways of mapping a service and each is more or less useful, depending on what you’re trying to explore or explain. Before you build or redesign a service it is worth spending time creating a service blueprint to capture the front stage user experience and the backstage activities the organisation needs to deliver to create the new service. It could act as a draft proposal in the beginning and as you prototype ideas you can add more detailed layers to it. In this post, I discuss the benefits of blueprints.
Create a shared understanding of the bigger picture
A service blueprint gives a complete picture of how the service and related experience is delivered, end to end, front to back and across channels. It is a powerful tool that simultaneously provides a high-level view of the user experience and a detailed view of what is going on below the surface.
Having the service overview in the blueprint is important, because it can help teams communicate the project to decision-makers higher up in the organisation before they start building or changing the service.
It also gives stakeholders a zoomed-out view of all things needed to come together before starting to improve parts of the service. This makes it easier for the stakeholders to understand the magnitude of the work needed to deliver the service. It helps stakeholders grasp how a change to a detail of the service might have an impact on other parts of the service, when they can see how everything is connected, as well as what blockers they might need to remove for the team.
As you can see, in addition to creating an understanding of the service, a blueprint can be used as a guide for planning, cost estimation, technology decisions and service team makeup. The blueprint will ultimately give the decision-makers more information when making decisions and help the service team set-up their project for success.
As the service takes shape, the blueprint can be further refined and iterated, enabling the project team to easily onboard new people or build awareness of the service. If you keep the old versions of the blueprint you will have documentations of the project decisions throughout the project and you can see how the service blueprint has evolved over time.
Understand what different teams are working on
Services, as users see them, like starting a business or coming to the UK, may be built by several teams, each working on a specific part of the service. These teams often work in isolation and more often than not, are not even in the same organisation.
This makes it very easy for the respective teams working on parts of the service to lose track of the end-to-end offering they are providing to users. In these cases, a service blueprint can help isolated teams have a common understanding of what they are building, understand where they fit, and what others are doing to solve a part of the same wider problem.
It can also help isolated or siloed senior stakeholders, managing projects across different programmes, to quickly understand the plan of what the service will look like and what the teams are working on. They can see the wider consequence of removing a team from a piece of work.
Enable better communication and outcomes
The process of creating the service blueprint is just as important as the final artefact itself. This sometimes-overlooked, important step in the process helps ensure that everyone involved in the end-to-end service communicates more effectively.
To enable early collaboration, I recommend that the people involved in shaping the service co-create the blueprint. This process relies on a cross-functional collaboration between all the different professions, teams and organisations involved to represent all aspects of the external and internal service provision and experience.
In these co-creation sessions, people can feed in their insights, and agree on things such as service steps, key transactions, channels and the service name. Instead of everyone having a different idea and understanding of what the service vision is, they feed into a single vision.
When everyone has the same understanding of what the end-to-end service will be, communication improves because the teams have a shared view and reference point for the larger service. This allows the teams involved to discuss gaps in the broader offering, plan what to do next, spot opportunities to learn from each other and avoid duplication of work.
It can be hard to reach out and work across organisational boundaries. Service communities are one proven way to do this.
Help identify and explain priorities
A maintained service blueprint can be an effective tool to show how to distribute resources across a given service and provide clarity on where teams should focus their efforts. By providing an overview of the service and its component parts, a team can easily spot gaps where they haven’t done work and avoid spending too much time on small details before they have established a baseline of the end to end service. This use of the blueprint is helpful when trying to prioritise work.
When you start prototyping and testing the service there are benefits of adding qualitative and quantitative data to it. Mapping user insights from different pieces of work against the blueprint can show a heatmap of where the teams did research and where users struggle with specific parts of the service. When planning, the team can use the collated insights to see where they need to spend more time iterating specific parts of the service. This process provides a transparent way to show design priorities based on captured pain points.
If the team uses the blueprint as part of their planning rituals it can become a tool that helps build a case for stopping something, starting something new or continuing the work for longer. It can facilitate conversations regarding how much work remains and if the service team needs more investment to finish the service within the deadline. It can also make it easier for stakeholders to grasp the context of why a specific feature or transaction is being built.
Stay focused by zooming in and out
When working on services we often get lost in the details; with a zoomed-out view that a service blueprint provides, teams who are prototyping features of their service can use it to step back, to think about the bigger picture.
It can function as a useful reminder of the wider problem they are helping solve and inspire them to come up with a wider range of new solutions if they get stuck. This can help a team to totally rethink what they are doing rather than tweaking what they got.
The service blueprint becomes an important artefact that allows teams to zoom in and out, ensuring that nothing is missed in the development of a service.
If you want to build a service blueprint, be aware that it requires time and effort to maintain, and this must be properly accounted for in your team's capacity. How much resource you need to build and iterate the service blueprint is largely dependent on the complexity of your service, how much detail you want to add, and the number of organisations or teams involved in the delivery of the service.
To help you estimate how much effort is required to keep the blueprint alive and useful after you made it for you and your team, we have advised on how to keep a journey map useful long after you make it.
Service blueprints have been used widely in government, in the UK and abroad. At GDS, we have been running blueprinting sessions remotely recently, designers at NHS Digital are using blueprints regularly and the Ministry of Justice blogged about mapping their services a while ago.
Internationally, service blueprints are used at Singapore’s GovTech unit and in Canada’s British Columbia provincial government. If you are just getting started, the US government partner Nava has created a detailed service blueprinting facilitation guide that’s worth reading.