We’re currently providing design and data capabilities to Placecube on a project for Huntingdonshire District Council—supported by the Ministry of Housing, Communities and Local Government (MHCLG)—to develop a new service that helps residents find the help they need before their situation becomes more difficult.
This service might be used in several different ways. Residents could ‘self-serve’ by engaging with it online,or community organisations and service providers might use the tool to coordinate their assessments and recommendations. Part of the service design is about finding ways to support these different use cases and scenarios.
We’re working with a user researcher to understand how and why residents might use the service, but we’re also talking to Huntingdonshire staff and partner organisations to explore how the service fits with what’s happening now and how this will change when the service is live. The main tool we use to map this out and understand how the pieces fit together is a service blueprint.
What is a Service Blueprint?
A service blueprint is a visualisation of the processes and parts that constitute a service. Originating in a 1984 Harvard Business Review article by G. Lynn Shostack, the service blueprint has gone on to become an essential service design tool.
Original Service Blueprint by G. Lynn Shostack
Early versions like this example resemble process diagrams much more than the service blueprints in use today, although the principles remain the same.
Like most service design tools, the blueprint puts the customer (or user, resident or citizen) at the heart of the service. But unlike some other tools (for example, journey maps), the service blueprint allows us to look deep inside an organisation for the functions and collaborations that make a service happen.
The process of creating a service blueprint can be as valuable, if not more so, than the service blueprint itself: bringing everyone together to discuss and show how an organisation delivers a service can be a vital step in understanding the customer experience.
One of the biggest changes in the format of a service blueprint since its 1984 debut was introducing theatrical metaphors. A modern blueprint will most likely divide activities into “frontstage” and “backstage”, clearly defining what is seen by the customer and what is not visible. And blueprints now often provide a space for visualising what the customer sees (physical evidence), which can be a useful tool for planning prototypes (such as mock-ups of screens people will see or even conversations that might take place over the phone).
A small section of a simple service blueprint with explanations (click here for larger version)
Most importantly perhaps, the development of blueprints has sparked innovation and variety around just how much information they can contain: the various “swimlanes” (the horizontal strips that map specific information across the timeline) can be adapted for the particular needs of any organisation. Should your blueprint show data, how machine learning is used, what rules and regulations apply, or which metrics are relevant across the customer journey?
Basic Types of Blueprint
This completeness and flexibility makes a service blueprint useful for all sorts of applications, but most uses fall into one of two broad categories:
- As-Is (or Current State)
- Future State
The As-Is (or Current State) Service Blueprint
This form of blueprint can provide a solid, practical first step for a service design project: by getting everyone together and visualising how a service works an organisation can quickly get an idea of how different people see their role in the service, where some parts of the process are not well understood, and where things are not working as well as they might be.
More importantly, perhaps, this form of blueprint can provide a canvas where specific opportunities for improvement can be highlighted. By visualising these we can clearly shown what needs to change, and make sure everyone understands and agrees before moving forward with a service design project.
The Future State
By describing a future state (or what a new or improved service might look like) the service blueprint acts as a form of prototype. It gives the organisation a way to explore and test assumptions internally before moving to the next stage in service design. This type of blueprint can become a portfolio of things to be prototyped; a resource-planning document; a central reference as the service is developed; or a way to keep in mind critical considerations like rules and regulations, or data processing.
Developing Service Blueprints in Huntingdonshire
We’re producing several different service blueprints as the Huntingdonshire project evolves. At the beginning of the project we created a very simple example to help us think through what a final version might show. A service blueprint can be a very complex, detailed artefact, but rough versions can also be really useful for thinking out loud. As with any kind of prototyping it helps to think by doing, and work iteratively.
Beyond this initial version we’re developing various other forms of blueprint for different needs and audiences. There’s an overview version which shows elements at a higher, less detailed level, and there are individual blueprints for different stakeholders so that we can talk them through a simplified view without getting stuck in too much complexity.
There’s also a very detailed version to help with technical prototyping – the individual screens and interactions that the customer will see, along with the Placecube technologies that will underpin those. All these different versions will eventually be linked together with a narrative that helps everyone understand what they show and which parts to look at for different requirements. And each of these versions will have been developed by talking to the people involved and making sure that what is shown is feasible and represents what they do.
Platforms for Prototyping
At the moment we’re relying heavily on Miro to build and collaborate around the service blueprints. We’re also using Figma for the detailed version so that we have some extra functionality around prototyping. Before we all went online—for projects like this—we’d have expected to be gathered in a room with post-its to build service blueprints, but with this not being currently possible, tools like Miro plus online collaboration sessions help us get closer to a workshop environment.
For the final blueprints we’ll still go back to some simpler technology. We’ll keep the Miro and Figma versions but we’ll also reproduce the blueprint in Microsoft Excel. As sophisticated as some platforms can be it also makes sense to produce service design artefacts in software that pretty much everyone has access to.
Simon Gough is Design Lead at The Data Place. We’re supporting Placecube with design and data capabilities on the Huntingdonshire District Council project.