Is the output of a Service design project “not more” than a blueprint?
Reflecting on the communicated output of a service design process—a visual artifact
I used to work as an art director and graphic designer for over 10 years. Recently, I have been presenting myself as a UX designer, product designer, or even an aspiring business designer. However, I am currently preparing to start mapping out a service for a project that will run for a few weeks this fall.
This made me dig deeper into the topic of service design.
I keep seeing these complex (and visually beautiful) maps
When reading up on service design and chatting with colleagues, I often notice that the focus of a service blueprint turns out to be the artifact or visualization. This is something NN Group also sees in a survey where 56% of participants said exactly that.
I’m solution-oriented
My approach to design is simple. I prefer quick actions to extensive user research projects. 😄
Just enough research. Agile ways of working. Minimal Viable Products. Prototyping. From my perspective service blueprinting could, and should, make use of all of it.
For whom is the blueprint made?
The first question would be who would read it, understand it, draw conclusions and take action on the mapping. And when? When the mapping is done, or while the mapping is happening?
Service blueprints might be visually appealing, they hold a lot of information to explain the service from multiple views (customer, front-end, back-end) as well as other aspects of a service (added as lanes) e.g. supporting processes, pain points, time and the tools used.
But, does the level of detail in a service blueprint match the audience? Sometimes it can be so detailed that it’s hard to separate the output from the collected insights. Everything is there.
It could be a visualization problem, but design is also about what not to show.
What does a blueprint really show?
Even though talking to a lot of customers and co-workers, most times it’s not possible to interview all of them. At some point, we need to cluster or group users, use personas, and extrapolate the findings into one “truth” or hypothesis.
More details, more use cases or both
Blueprint can be deeper or wider. A deeper blueprint may mislead the audience if we start to extrapolate on more user journeys.
It’s a snapshot in time
It's important to remember that what we see in a service blueprint is only a snapshot in time. It accurately reflects the service as it was during the discovery phase, but since then, things may have changed. There could be intentional changes made by designers, such as identifying and addressing pain points. Alternatively, there could be unintentional changes due to customers changing the way they use the service. The ideal scenario is for the process of creating and updating a service blueprint to be repeated regularly, so that it remains an accurate representation of the service.
This brings me to the next topic, the outcome of service blueprinting.
When is service blueprinting used?
In the same survey from NN Group, on the question of when service blueprints are used, respondents identified five key moments in the product-design lifecycle in which they use service blueprints:
- Defining a research plan: Service blueprints help pinpoint gaps in knowledge, shaping research plans by identifying “known unknowns” and needed resources.
- Discovery and empathizing: Service design includes understanding colleagues and stakeholders; blueprints aid in grasping their roles, fostering alignment, breaking silos, and enhancing empathy.
- Defining and prioritizing: Blueprints define service areas for enhancement, pinpointing gaps, redundancies, and friction for a targeted redesign.
- Ideation: Blueprints inform ideation sessions, serving as prototypes for envisioning an improved service experience.
- Implementation: Blueprints aid in planning, tracking success, and informing decisions, acting as shared visualizations for communication and prioritization.
Key moments and the double diamond
Those five key moments translate pretty well to the double-diamond model below. But where I think the output is lacking is in the Develop and Deliver parts of the process, referring to the key moments of Ideation and Implementation.
Wanted output of a blueprint
Instead of making the blueprint deeper or wider as part of the Discover phase, as soon as common pain points from the customer’s perspective are identified in the Define phase — pause, prioritize those pain points, and start problem-solving.
Iterating on different solutions, making quick and cheap prototypes of the solution, asking users to test a competitor’s solution or change our existing solution and asking users for feedback.
Wanted outcome of a blueprint
Depending on the type of business, the outcome will be different.
But it would be safe to say, that if we could early identify existing pain points and prove that there might be better, achievable solutions, we could despite not having a “complete” blueprint:
- Get a clearer backlog
- Get happier customers
- Get happier co-workers
- Create a more efficient user journey
- Reduce risk in product development
