Jan. 31, 2023
“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.
The service blueprint allowed us to:
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.
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.
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.
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:
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.
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.
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:
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
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:
As we went through it we asked people:
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)
Once you have a blueprint it can help you answer questions in your project. We found it useful for:
“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.”
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:
We could then identify the things we wanted to do as part of our MVP.
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
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.