Getting started with Service Blueprint

Silentium Vietnam

Have you ever worked on a system where you have to navigate through wires of processes, tons of requirements, complicated processes across teams and departments? Then people even ask you, hey, how can we improve the situation?

Well, if you have ever been in that situation, this post is for you. With the post, Silentium Vietnam'll address you through a problem that this technique is trying to solve, opportunities by accomplishing the activity, and even further benefit for all of you people.

(And by people, we actually refer to both Product Managers, Business Analysts, Product Designers, Developers, and QA or QC, well, this technique benefits EVERYONE)

So, hey, what is a Service Blueprint?

Service design is the activity of planning and organizing a business’s resources (people, props, and processes) to (1) directly improve the employee’s experience and (2) indirectly the customer’s experience. Service blueprinting is the primary mapping tool used in the service design process.

The definition above we shamelessly copied from the Nielsen website. We actually refer to the mentioned document a lot. We link to the article by the end of this blog post.

We use this technique A LOT, we actually have a project that has built AROUND a giant Service Blueprint, and we can't wait to share the experience with you.

Strawman speaking, a Service Blueprint is a document, with visual aids, to demonstrate "human & machines & systems & processes and everything else" interactions. And by doing that, everyone has a better understanding of involved stakeholders.

Why Service Blueprint?

Firstly, when we talk about "Service" and "Service design," we normally talk about complex domains. Why is "Service" supposed to be complex?

Well, because most of the services will likely involve

Multiple direct users where they are a part of the service
Indirect users where their actions may be interested in those direct users
Multiple organizations where they concern about the different angle of the process

For example, when we talk about a POS at a counter at a Supermarket

Direct users are cashiers; they do manage checkout operations
Store managers do care about daily reports, statistics, and inventory
Customers are indirect users, as normally they don't interact with your system, casher will process those activities
In the middle, there will be systems for billings, a system for invoices, a system for inventory management, a system for report and statistics, systems for user management, rights, and roles

Benefits of using Service Blueprint

You see, just from a seem-to-be straightforward service, there are thousands of details that may involve in.

The straight benefit of Service Blueprint is letting all of the involved stakeholders understand these domains, processes, and the relationship between them.
Once everybody understands the current process, it's much easier to discover weaknesses, manual processes, human interactions, or a sluggish system.
Naturally, we may observe opportunities to digitalize systems, optimize the manual processes, or mitigate existing weaknesses.

When and when not using Service Blueprint?

Well, Service Blueprint is to be used in most situations but the simple one.

The rule of thumb is, if there is only one direct user with zero indirect users, you are unlikely to need to use Service Blueprint

Service Blueprint terminologies

We'll go through terminologies really quickly beforehand on a more concrete example

The direction from the left to the right of the diagram represents chronological order. Items on the left will for sure happen before items on the right
Evidence - an indicator of stage changes, especially in multi-stage processes, it's much easier to explain in the example; we'll get there
Customer journey - normally we'll try to target the "Indirect user" of the system. We use this to distinguish with Employee actions (think of Service user and Service provider)
Line of interaction - a line to separate between Service user and Service provider
Frontstage - where Service users are still in interaction, they may provide input and be directly or indirectly involved in the success of operations
Employee actions or human interactions - describe the human interaction part of the Service provider
Technology or touchpoints - interface where Service user or Service provider interact with the system
Backstage actions - direct operation, normally start from touchpoints, user DO care about the result of the backstage actions
Support operations - behind the scene operation, user DON'T care about the result of these actions

Few, quite a long list, it may confuse some of you. It is actually much easier to explain that with an example

Service Blueprint in action

Let's stick with a very classic example of Service design - let's describe a Service design of this operation - "Describe the checkout process via POS at Supermarket."