“Part of a service blueprint is to imagine everything that’s happening as one ‘whole’. But that’s not how services and products are commissioned. It’s not one lovely holistically designed thing, it’s lots of overlapping things which we need to consider but we can’t necessarily influence or impact. This kind of granular mapping hadn’t been done before.”
We created a service blueprint as part of a complex, long-running project with multiple workstreams. Here, we share our approach to preparing and sharing the blueprint and what we got out of it.
Why it was useful
The service blueprint allowed us to:
- visualise and take stock of what we’ve done
- bring people together to critique progress
- identify pain points (internal and external)
- find gaps where we hadn’t even started to address a problem
- prioritise future opportunities
- check facts and information
When to create a service blueprint
Navigating multiple journeys
A service blueprint is helpful when you have multiple layers of technology and user journeys. You might have internal and external users, beta journeys and legacy journeys.
The service blueprint lets you see the flow through those layers.
Multiple projects
It is also useful when you have multiple Product Owners working on different elements of a bigger project. The process of creating the blueprint helps POs familiarise themselves with what others are working on and understand how that relates to their piece of the puzzle.
Multiple features in MVP
When you are building and testing many elements of a minimum viable product (MVP) in parallel, a service blueprint can help to pin point barriers to adoption of different features.
We looked across the service to see which parts of the front end are connected to the end user, and what gaps we have.
We found two big gaps where we hadn’t even started to address the problem. We were able to then discuss what would make these elements acceptable for use and how we could bring these parts of the process up to the same standard as the bits that were already working.
How to do it
Who to involve
When you have a big team of people who are working on several things at once, you need the people who can give you the right information in the right places. This allows you all to gain a shared understanding of what is happening where.
You might have several different voices and viewpoints, making it harder to get consensus. But it allows people to look beyond their immediate role and have a thorough and informed discussion about what to do next.
In our case we included:
- several POs (who were also planning officers from different councils)
- delivery manager
- service designer
- 3 developers, two of who had been on the project for a long time
- someone from the central government department that funded the work
- two designers, one who had recently joined the project
When you have this many people in what can be quite an intense workshop, it’s important to have someone who can facilitate discussion and help everyone get a chance to speak.
Choose your moment
Our service blueprint was a useful reflection tool when we were part way through a long term project. Some people had been there for a long time but others hadn’t - it was a means of sharing knowledge from one phase of the project to another.
Preparing the structure of the blueprint
Our delivery manager and a designer did some mapping before the session, giving us a basic structure or the ‘bones’ of the blueprint.
Our service blueprint showed the end to end journey of how a customer (‘applicant’) completed a planning application to their local council. While this is essentially an interaction between two humans (in this case it was an applicant and planning officer), there are multiple digital transactions happening to make that human interaction as seamless as possible.
We mapped out customer actions in a linear way across different levels:
- frontend activity (what the customer sees and does)
- backend activity (how documents and data are sent by an API, how they’re received and how this interacts with the legacy system)
- human actions (what the applicant does, sends or receives, how the planning officer checks the application)
- legal basis - how legislation affects whether the application is valid or not
The legal basis was crucial in this project but you might use a different level here, such as ‘system resources’ or something else that is essential to the end to end journey.
We got to the point where we couldn’t go any further ourselves. There were some big gaps and questions that we couldn’t answer, so we took it to the wider team.
Preparing the service blueprint
Set up
Our first session was remote. We had prepared the structure using Post-its on a wall and then translated that to Miro. We asked people to read through on their own, then we walked everyone through it together.
A few things we found useful:
- we annotated the Miro with questions we’d come up with during prep
- we took screenshots of the product to illustrate different touchpoints so that people could quickly recognise where they were in the process
- we asked everyone to read through it on their own
- we walked through it together, making sure everyone understood what we were looking at
As we went through it we asked people:
- is that what you expected?
- what would put in here?
That’s where the conversation really got going and people started to collaborate and own the blueprint.
It did take a few sessions to refine and get it to a point where it was useful for everyone. Ideally, you’d get everyone together in a room together for a full day and use a wall to map it out. When working remotely, it can be harder for people to engage for more than a couple of hours, so you might need to break it up into smaller tasks.
Blueprinting a specific user journey (applying for a lawful development certificate to your local planning department)
What you can do with a service blueprint
Once you have a blueprint it can help you answer questions in your project. We found it useful for:
- progress review: comparing the blueprint to our original roadmap
- showing people the wider ecosystem of the project and how their day to day work in one area relates to wider outcomes
- explaining limitations, dependencies and risks to wider stakeholders
- explaining why we’ve made decisions
- prioritisation
- fostering collective ownership: showing people beyond the core team how services overlap
- data centric mapping - we could strip the user experience to focus on the data layer - where data is coming from and going to
“We can remind everyone of the dependencies and why we’ve ended up doing things in a certain way. If people aren’t working on this project full time, it’s not always in their mind and they don’t have this big picture. The blueprint makes things much clearer in a very visual way.”
Prioritisation tool
Up to that point, we had spent a lot of the project concentrating on one aspect rather than thinking about the end to end and what we wanted to achieve through MVP. The service blueprint gave a big ‘frame’ that could hold all the chunks of work together.
We could then discuss what to prioritise from the roadmap. When you see things mapped out across the blueprint you can push people to say:
- what will happen if we do this?
- what will happen if we don’t do this?
- what’s the urgency to do this?
- where are the gaps we need to deal with first to unlock other opportunities?
We could then identify the things we wanted to do as part of our MVP.
Refining the service blueprint
On a big project it’s hard to get everyone together and focused, so you may need follow up conversations to get the blueprint to truly reflect what is happening in the project.
With a more complicated project, people are dealing with more tasks - there will be more tasks that people are not able to speak about. You may not know who you need in the room until you’ve had your first workshop.
We used sub-mapping sessions to get into the details of certain tasks or sets of tasks within the service, then brought these back into the bigger blueprint.
Using screenshots to focus on specific actions within a blueprint
Sharing a service blueprint
A lot of the value of service blueprinting is in the process more than the document itself. It is a massive document. If you came to it without context and without someone to talk you through it, it would be a lot to take in.
It’s not a great document for ‘imagining’ - if you start moving things around in Miro then all your linked objects and journeys can get into a mess.
That said, the blueprint is a great analytical tool.
We shared bits of it through Show and Tells to help tell the story of the project. It’s also been a useful workshop tool to prompt discussion and reflection.
The key thing when thinking about doing a blueprint as with anything else we do is that it has to be adapted and created to suit the purpose. Some service blueprints might be more about learning and looking back at what you’ve done in order to plan the next steps, others might be about blueprinting a ‘to be’ service and helping think through the challenges to come.
The value is in the shared process more than the sharing of the ‘finished’ blueprint, so it’s worth taking the time to plan out when to do it, who to involve, and how to use it.