This week moved into the mechanics of service blueprinting in more depth, building on the introduction from week 3. The focus shifted from what a blueprint is to how you actually construct one and what questions it forces you to ask about your service.
The framing that opened the session was a useful one. As a team, what backstage processes must exist for your design to work? What support systems need to be in place? Who is doing invisible work to make the visible experience possible? And crucially, are you able to interview those people? That last question is one that often gets overlooked. The people operating in the backstage of a service, the ones the user never sees, are frequently the ones who determine whether the service actually works or quietly fails. Understanding their experience is just as important as understanding the user's.
This line of thinking was directly applicable to our project. The intake officer processing a prisoner on day one is a backstage actor in the Flare service. The API firing a notification to a provider is a backstage process. The administrator confirming that an account has been paused is invisible to Dean but essential to the service working as promised. Blueprinting is the tool that makes all of that visible and ensures nothing gets designed around an assumption that a process exists when it actually does not.
The technical structure of a service blueprint is built around swimlanes, horizontal bands that represent different layers of the service experience. Each swimlane captures a different dimension of what is happening at any given moment in the journey.
The key lines that divide and organise those swimlanes are as follows.
The line of interaction sits between the customer and the service provider. Everything above it is the customer's experience. Everything below it is the service's response. This is where the visible exchange between user and service takes place.
The line of visibility separates what the customer can see from what they cannot. Above the line is the frontstage, the touchpoints, the interactions, the moments the user is directly aware of. Below the line is the backstage, the processes, systems and people doing work that makes the visible experience possible but that the user never directly encounters.
A third line was referenced in the notes, the line of internal interaction, which separates the actions of frontline staff from the deeper support processes and systems that sit behind them. This is where things like IT infrastructure, databases and automated systems live.
Together these lines give the blueprint its structure and make the dependencies between different parts of the service legible in a way that a written description never could.
This week also included a talk from Deloitte. Unfortunately my notes from this session are incomplete so I am not able to document the content in the detail it deserves. What I do know is that it provided an industry perspective on service design practice at a professional and organisational scale, which was a valuable counterpoint to the academic framing of the rest of the module.
<aside> 💡
Blueprinting week felt like the point where the theoretical side of service design and the practical side of our project finally came together properly. We had been talking about backstage processes and support systems in the context of Flare for weeks without having the full vocabulary or framework to map them precisely. This session gave us that.
The questions posed at the start of the session, what backstage processes must exist, who is doing invisible work, can you interview those people, were ones we had already been grappling with intuitively. The mentor interview with Barry was partly an attempt to answer exactly those questions. He was one of the backstage actors in the system we were designing for and his perspective was invaluable precisely because of that. This week gave me a clearer sense of why that conversation had been so important and how to use what he told us more deliberately in the blueprinting work that followed.
The swimlane structure also helped me understand the service blueprint Paul produced for the panel pitch more clearly. Looking at it through the lens of lines of interaction, visibility and internal interaction made the logic of how it was structured much more legible and gave me a stronger foundation for thinking about the interactive version we were building as our prototype.
</aside>