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 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)
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.
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
For example, when we talk about a POS at a counter at a Supermarket