Note: This is Part 29 of the Ruminations for Aspiring Designers series.
Introduction
The majority of this article came from a discussion between a friend and I over how to interpret service blueprint. At the core of the discussion is around what backstage stands for. I think it could still be useful for aspiring designers to learn about my overall take on the topic.
Additionally, I believe there’s a bigger lesson to learn from it: as design practitioners, we shouldn’t let a tool dictate how we use it and, instead, we constantly invent and reinvent it in order to fit it to the problem at hand.
Also worth noting that here I use “tool” and “technique” interchangeably. As a technique to describe a service and its ecosystem, service blueprint is an essential thinking tool.
Here’s my personal take on service blueprint.
The Essence of Service Blueprint
If you look up service blueprint online, chances are you’d come by definitions from rather credible sources like NN/g, This is Service Design Doing (TiSDD) or Wikipedia.
With no intention to challenge them, I’d like to base my interpretation on how I actually use it over the years.
There are three essential purposes in using service blueprint:
- Visualization: Visualizing people, things, and their relationships through spatial and conceptual articulation;
- Bridging the internal to the external: Clarifying how internal operation enables and supports external user experience and user goals;
- Analyzing problem: Identifying relevant issues, discovering patterns and paving the way for further synthesis.
Let’s unpack those a little bit below.
Visualizing People, Things and Their Relationships
Service blueprint is first and foremost a visualizing tool that captures information in a certain way – in this case, in a temporally sensitive way. That merely means we describe what happens over time.
Many – or arguably all – visual mapping techniques are about visualizing people, things and their relationships, just from different angles and with different focuses. In service design, stakeholder map is also about visualizing people, things and their relationships, just not in terms of what happens over time.
In other words, service blueprint may be useless if what you want to describe is not time-sensitive or does not happen over time.
The bottom line: service blueprint visualizes people, things and their relationships over time.
Bridging the Internal to the External
Service blueprint visualizes how people and things internal to a business and those external to it connect with each other.
A customer often does not see whatever goes behind the scene of a business. In fact, they usually see a very small part of it – e.g. the interface of a service.
But as designers, we cannot limit our views to that of a customer. We need to see the X-ray version of the business. Specifically, we need to understand or articulate how things happening internally influence those happening externally and vice versa. Capturing that causal or correlated connection between the internal and the external is at the heart of service blueprint.
The bottom line: like many other mapping tools, service blueprint is about making comprehensible connections.
Analyzing Problems
This should be obvious, but there seems to be a common misconception that service blueprint is a tool to solve problems, giving the mounting evidence that service blueprint is a rather popular recipe in all kinds of workshops, design jams or consultation sessions.
But service blueprint really is NOT where we can solve any problem. In my experience, it rarely does.
By describing a service – either its current state or its ideal future state – all we are trying to do is to express what we know about the workings of a service in a way that makes it easy for us to analyze it from a certain angle (specifically, a temporal angle).
Expressing visually what we know or what we think to be good about a service is merely the process of framing it. We frame a service in a very specific way (temporal, modular and interconnecting) so that, from there on, we can use the language of that frame to talk about it and analyze it, in hope we can identify patterns to articulate how we can address issues or improve the service.
That’s not problem solving. That’s just about the first few steps to solve problems. To solve a problem, we also have to synthesize what we find from the expression, the frame or the patterns by making human judgements. In most cases, we cannot really analyze our way to judgement – we have to synthesize to it.
The bottom line: service blueprint is mostly a tool for analyzing problems and/or solutions, rarely one for solving or implementing them.
Interlude: The Nature of Mapping Tools
On a more general note, most mapping tools are about:
- Thinking visually: uncovering conceptual relationship by exploring spatial relationship;
- Recognizing patterns: identifying or articulating ways to generalize logic or process from specific instances in specific context.
In the following two sections, I talk about a specific detail (“backstage”) in service blueprint. Read on for the curious or those who are familiar with the concept; otherwise, it’s safe to jump to the section “Five Takeaways.”
Backstage: The Battle of Definitions
TiSDD defines frontstage and backstage abstractly:
“Frontstage” refers to people and processes with which the user has direct contact. “Backstage” represents people and processes that are invisible to the user. Support processes are activities executed by the rest of the organization or external partners.
TiSDD limits backstage only to frontline employees:
Backstage actions are activities by frontline employees that are not visible to the customer; these activities take place below the line of visibility. Backstage inter actions can be connected to frontstage actions and support processes. Optionally, a swimlane visualization here might describe backstage actions by particular employees.
However, NN/g defines “backstage” slightly differently and includes people and things that are not necessarily in front stage:
Steps and activities that occur behind the scenes to support onstage happenings. These actions could be performed by a backstage employee (e.g., a cook in the kitchen) or by a frontstage employee who does something not visible to the customer (e.g., a waiter entering an order into the kitchen display system).
Major sources don’t necessarily agree on things we deem to be settled, but the core thing here is not to assess which version of definition is “more correct” (both are correct).
What’s really significant in both definitions above is that they both emphasize the separation of three things:
- People and things that are visible to end-user (front stage);
- People and things that are not visible to end-user (back stage);
- People and things that are somewhat “external” to the immediately relevant people and things at front and back stages (support processes).
That separation is one of the most important things we need to consider in a service blueprint.
In that regard, it doesn’t necessarily matter whether people and things at backstage have to be exactly the same as those at front stage.
As is the case for service blueprint here, a visualization tool is not a settled thing on details. Instead, it simply tries to reflect the principles that practitioners often try to stick to based on their own experiences.
One of the principles of service blueprint is the principle of separation – an analytical approach to help people break things down to manageable parts for further analysis (and in hope they can synthesize them all back together at a later time with more insights and ideas).
One thing to note is that “external” is always relative. Another unit in the same organization could be considered “external” when it’s not directly related to the unit who provides the service. The key understanding here is about the relative relevance. Something can be considered inside backstage or as “external” depending on our perspective or our focus. According to NN/g, back stage can also include people and things that do not necessarily appear on front stage.
A great example is a restaurant: waiters are obviously on frontstage, but what about the 3-star chef who never appears in front of customers? In this case, should the chef be on backstage? Normally we’d think yes – the chef belongs to the backstage because he’s the critical, directly relevant “behind the scene” person as far as serving food to customers is concerned.
Accordingly, it doesn’t make sense to say that the chef doesn’t belong to backstage because he doesn’t appear on frontstage. It also doesn’t make sense to put the chef to supporting process, because the chef is mostly considered a critical and integral part of the restaurant service, and there’s no way that he’s “relatively external”.
Aligning Spatial Relationship with Conceptual Relationship
There’s no single “canonical” definition of service blueprint. At the end of the day, it’s just a tool, and no one says we can’t make a tool flexible (that’d be dogma).
A tool should be used in a way that make sense, and no dogma should get in its way.
The notion that backstage holds exactly the same people and things as frontstage does comes from TiSDD, which I don’t agree simply because that’s a rather limiting way of using service blueprint.
The core issue with that notion is – it often forcefully (for no other reason than how backstage is defined) pushes often closely-relevant people and things to far down the swim lanes (e.g. supporting processes), making it look like not very integral to what happens on front and back stages.
Sure, we can debate whether a chef should be in the support process lane (there’s no right or wrong in that, it merely depends on one’s point of view), but the simple fact that chef is not placed alongside waiters and other helper chefs (who do appear in both front and back stages and interacts constantly with the chef), just doesn’t feel helpful when we want to look at how restaurant works in general, as least not as helpful as if we put the chef on backstage, along side those other people whom they closely work with.
The original metaphor of backstage is from theatre. In theatre, the back stage includes two types of people: those actors who go in and out of the back stage (from/to the front stage), and those who provide critical and integral support for those actors (e.g. prop master, lighting) – those second type of people are in no sense “external to” or “far away from” whatever’s happening on both front stage and back stage.
Five Takeaways
- There’s no single “canonical” definition of service blueprint. It’s also largely the case for most tools available to design practitioners.
- Service blueprint explores people, things and their relationships, specifically in the context of how an organization’s internal operation enables and supports external user experience and goals of its services.
- Visualizing a service is mostly about setting boundaries (through spatial relationship that reflects its corresponding conceptual relationship).
- The interpretive freedom lies in the utility of the tool, not in the formulation of it.
- When in doubt, choose pragmatic flexibility over inconvenient dogma.
What’s your take on service blueprint? How do you use it?
{END}
Like this post? Subscribe to receive all updates on my writings! 🙂
Noah Fang 
1 comment