Sketching the Future – with Service Blueprints
Studio Notes | Long Reads
by Sean Casey, Service Designer
What is service blueprinting?
Service Blueprints are a tool which service designers use to visualise and understand the intended user journey through a service, and the systems and processes which will be needed to support that service.
A blueprint is detailed, and it breaks the entire service down into stages of the customer/user journey, and even further into the things the user will experience and interact with along the way. These are called frontstage touchpoints. It also includes the things which need to happen behind the scenes to make the service work. We commonly call this the backstage of the service.
At Context Studio, we like to distinguish between “maps“and “blueprints“. We use maps to illustrate the how things currently work in a service – and blueprints act like architect’s drawings – they show what’s planned for the future before it’s implemented or built.
Why do we use blueprinting?
Creating a service blueprint allows us – and the teams we work with – to see a full picture of how the service will operate. By putting a blueprint in front of a team, we can gather feedback and learn about what will and won’t work, and what needs to change before any prototyping or implementation starts. This saves time and money.
Seeing the service laid out clearly also fosters alignment between the stakeholders who will be delivering the service – making sure everyone is “on the same page” when it comes to understanding how the service will work, and what their responsibilities will be.
Additionally, a blueprint of your service can be helpful when onboarding new team members, allowing them to quickly gain an holistic understanding of how the service works – and see how they fit into the bigger picture.
Lastly, a good service blueprint can be of great benefit when talking to potential vendors or suppliers of tools and technology, by allowing you to communicate quickly and effectively the requirements you have – accelerating procurement processes and helping prevent misunderstandings in the specifications.
When do we use blueprints?
When it comes to understanding existing services, we start by doing some mapping. Maps of various kinds, informed by research, are useful for visualising the current way a service works, including potentially complex processes and interactions that occur between systems and stakeholders. They help identify inefficiencies that can be eliminated, pain points, and opportunities to create an improved service experience for both your users and teams.
During the design process we map first – and only then can we begin to create a blueprint for the future of the service.
In the rare case of a brand new service being developed – there is no “current state” to be mapped. In this case, we will begin to design a blueprint only once we have gained a well-founded understanding of your users’ needs and organisational goals.
Creating the service blueprint is the first step towards prototyping the new service, and as mentioned above, plenty of iteration and development can take place with the blueprint alone – making it an extremely cost effective way of preparing for change.
So how do Blueprints work?
While every blueprint is unique to the context of the service it represents, most service blueprints will follow a similar fundamental structure.
At the very top there should be a step-by-step sequence of key moments in the user’s journey through your service. This is read from left to right.
Below each of those steps, you will find the specific touchpoints that your users interact with as they move through your service. A touchpoint can be something physical or digital, and can include anything like an app – a phone call – a sign post – an interaction with staff – or a web page… the list goes on!
Below the touchpoints you’ll find more operational information. You will see actions undertaken by staff that are user-facing – which are called frontstage activities – and below these will be the backstage activities that power the service. The user will not see (or often even be aware of) the backstage activities that are going on to help make everything happen!
Lastly, it is useful to feature in your blueprints any supporting technologies, systems, or other resources that will be required for your service to operate properly.
To begin reading a service blueprint, start at the top left and move through the steps of the user journey, and then explore the supporting activities and touchpoints below each of these steps when needed.
Use wisely!
Service Blueprints are a powerful tool – but they must be used carefully, and they’re not the perfect fit for every project. If there are assumptions or uncertainties about how the service might work, then these need to be highlighted in the blueprint and tested through further research and prototyping. Some things can only be learned through real-world testing – so it’s important to iterate and be open to improving your service as you learn.
It’s important too, that service blueprints form part of a wider process of service design. A blueprint based only on the input of a few “experts” will be devoid of all the rich insight that research, co-creation, and iteration can provide. That’s a risky approach for a service that might scale!
Have a complex service that could do with some clarity? Get in touch!