Facilitating a Service Blueprinting Workshop — as colorful as the artifact itself

Service Blueprinting might best be known for its many colored stickies, but the process of running a service blueprinting workshop can be as colorful as the artifact itself. In this post, we share our approach to service blueprinting and will breakdown a workshop format that we have developed by running dozens of workshops, welcoming a wide variety of people and services.

The Service Blueprint is a collaboratively-made artifact built with the input of many different expertises like UX Designers, Software Engineers, Service Designers and people from disciplines such as People Services (HR), Legal and Risk. This makes it a truly a co-created artifact; seldom do you have so many and such different backgrounds under one roof.

Due to this diversity of experts, you end up with an atypical group. The challenges with working with a group like this are people are used to doing things “their own way”, and are not accustomed with design techniques, and working in a group requires explicit effort to track social interactions.

That being said, you need each expert to feel comfortable enough to contribute their important knowledge.

Our workshop format offers a structure suitable for breaking a group into pieces, while maintaining the bigger picture as people work in parallel. It creates a setting where it is safe to talk and not too much energy goes into minding each other so people don’t have to compete for their turn to speak.

It is a result of several inspect and adapt cycles, and we are pleased with how it goes. Because of that, we thought we’d share!

Service Blueprint — the method and materials

If you’re not familiar with Practical Service Blueprinting , it is a structured method for designing and talking about the experience of customer with your services. Often these services comprised of many different teams and stakeholders behind the scenes. It helps gaining a bird’s-eye view of how the different elements of the service align to create value. And helps you to take small and large decisions about actions you can take to make the service experience better for customers. .

Making the actual Service Blueprint, involves participants discussing different perspectives of each step in the actualization of your service. For example, who are the actors, what systems are needed, how do we measure and are there policies that influence the service. These topics are carefully chosen, each with their own color and collectively they provide the participants some grip on an otherwise non-linear discovery and delivery process. The artifact itself is a lush representation of the various parts of an organisation and its people involved in the service.If you want to read up on some of the finer details of the method, or familiarise yourself with the required materials, both the Practical Service Design and our own website are good starting points.

Furthermore, to cement the understanding of dependencies and teams, we’ve pulled in the creation of Product Backlog items in this workshop. This way, the group co-creates a Service Blueprint and associated Product Backlog Items as part of the workshop, typically something reserved for a follow-up session when synthesizing the output of the blueprint.

Product Backlog & Agile Software Development
In many organizations, the products and services they deliver are digital. In these environments, teams are often engineering teams who focus on shipping software to production.

Most have adopted Agile Software Development practices for making continuous improvements. Frameworks like Scrum offer teams a structure to sense and respond and with short iteration cycles to continuously add value.

At the heart of this way of working is the Product Backlog; a prioritised wish list of tasks for the team to work on. The entries on a Product Backlog are questions for the team to resolve. These drive the development of the service and reflect what is to be done in the future. The product backlog is owned by a Product Owner who is responsible for formulating and maintaining these questions.

An example of a Product Backlog Question is — ‘The elderly have trouble reading the small font on our website. How might we help them?’

During the workshop, the participants are encouraged to formulate new items for the Product Backlog of the service they design. We insist on framing these as a question, maintaining as much of the original context. Questions provoke problem-solving and retaining the context invokes empathy.

Workshop Mindset: Go slow to promote discussion

The goal of a Service Blueprinting workshop is to discuss how the service can be best delivered, if organisational changes need to be made, and whether the people involved understand their respective parts. To do so, it is important not to hurry and try to finish the full artifact in one go. A rush to complete the service blueprint often comes at the expense of discussion, depth, and insight.

We’ve experienced this haste much too often. Therefore, thinking slow needs explicit stating and it is important that we — the facilitators ourselves — don’t come across as stressed or in a hurry as we guide people through the day.

It is highly unlikely that the entire project will hinge on this one session — our intention is that people take enough time to observe, understand and contemplate.

Social Animals

We have observed that when people collaborate in a group exceeding four, it becomes strenuous to keep track of all the social interactions. The resulting confusion breaks healthy discussion and it becomes impossible to explore all the trails with the required detail. People start to check their phones more often than needed, create larger physical distance and end up in a general sense of aloofness.

To accommodate for this, we’ve designed our workshop so it mixes plenary exercises where the entire group is involved with exercises where clusters of maximum three to four people are working. We divided the workshop in several parts that differentiate between social and mental intensity. By having these transitions you can pack a lot of stuff in a few hours — and not be completely exhausted at the end of the day.

Workshop Structure

The day looks as follows; we start with a welcome and a get-to-know-the-method part. After this opening, people familiarise themselves with the scenario, the topics and their associated colors the set of colours through an exercise round. From this moment forward, the group diverges into small clusters of 3 to 4 people.

The workshop comprises of multiple time boxes; at the end of each time box, the groups present their results or people shuffle around to get a fresh perspective. This presenting and mingling propagates knowledge throughout the group, without the taxing group dynamics.

Facilitator Advice

The role of the facilitator is to synthesize, nudge and help people should they get stuck. Before the workshop, we conduct an intake with the service owners. We have a simple intake form and inquire details like — service name & description, description of the service scenario, scenario steps, workshop participants & their roles, and whether the scenario plays in the as-is situation or is a to-be situation.

The as-is (current state) versus to-be (future state) is important to know upfront to overcome confusion while blueprinting. Mixing these is often a bad idea.

No more than three of the same color rule — avoid topic clustering
Sometimes, we see a group clustering around a limited set of topics. For instance, the group focuses exclusively on Systems or Metrics. This can be because they feel comfortable with a specific area or because there is a dominant voice in the group that skews the discussion.

Whatever the reason, we think breadth is more important than depth in these co-creation sessions. We want people with from different expertises to comment on topics they typically wouldn’t consider — it often changes their mind and results in creative thinking.

To encourage seeing the wider spectrum of the service, we limit groups to using a maximum of three stickies of the same color per column. If there is still ground to cover, we plan a separate session at a later moment in time. This way, the result of the day holds a more balanced view, and contains input from everybody on all topics.

Design and solve Critical Moments
Next to the no-more-than-three-of-the-same-color rule, we encourage people to solve and design a way out of Critical Moments. The workshop should be more than building an inventory of concerns, we want people to actively solve problems and come up with clever innovations.

Don’t start at a dashboard or login step
One final thing to note, is that when designing digital services, we avoid starting with blueprinting a login or dashboard-like step.

The reason for not starting with login or dashboard-like steps is that a lot needs to be resolved and understood for these to work. These are typically steps where the whole service comes together. For a login step to work, there needs to be an understanding of who the users are, what authorization rights do they have, what they can access and how do they enter the selected service scenario. Similarly, a dashboard-like step requires a good understanding of data to show charts, reports, overviews, trend analysis and more.

In other words, you need to design the entire universe for that one step — that is a tough start.

Workshop Flow

Below you’ll find the flow of the workshop in finer details. Feel free to mix it up and take or alter whatever works for you.

We’re curious to learn what you think of it and if there are sections you would do differently.

Agenda

We start off the workshop by describing what today looks like, perhaps like this agenda:

15 min — Hello!
30 min — time box 1: first round of plenary blueprinting with the entire group
15 min — coffee break
40 min — time box 2: second round blueprinting in sub-groups
20 min — time box 3: third round of blueprinting in sub-groups
30 min — lunch break
40 min — time box 4: from a broader perspective (sub-groups)
10 min — closing comments

Opening

We state the Working Principles. These make some of the obvious explicit and allows the group to build trust in the facilitators:

understand by doing
trust the expertise & knowledge of your colleagues
be smart & design the solution
no more than 3 stickies of the same color per column
future thinking required. ideas beyond the MVP
trust us with the process. Be open for FRIENDLY nudging

Followed by House Rules; it’s important that the group understands and obeys them during the time of the workshop:

honor each other’s time
don’t leave during the workshop
we have plenty of breaks
honor time box times
clean up afterwards

Shortly after, we state today’s goals. As mentioned earlier, explicitly stating the goals redeems the group from a rushed feeling to a situation where discussion and design are stimulated. Hence only 50% Service Blueprint completion is expected.

an understanding of the service scenario, both end-to-end & surface-to-core
50% service blueprint completion
creating product backlog items & identifying dependent teams
gathering ideas to improve the service experience
an understanding of the relationship between design & software development
confidence to DIY

Introduce the service scenario

We have the service owners briefly describe the service scenario. This is necessary since often not everyone in the group is familiar with the service and it helps to avoid assumptions. Introducing the service scenario gives the whole group a common starting point.

Introduce the Service Blueprinting Method & Product Backlog Items

We describe the Service Blueprinting Method, its layers and value with a couple of examples. Likewise, we explain the Product Backlog Items and their link with a Service Blueprint.

Time Box 1 — Plenary round of blueprinting

The first time box is an exercise with the entire group. In it, all participants together attempt to blueprint the first column of the service scenario and create Product Backlog Items for it. This is when each participant acclimatizes themselves with the service scenario steps, layers in a service blueprint, the product backlog items, colors of the stickies, and each other.

It’s important that the entire group traverses the service blueprint layers one by one, without skipping them and creates at least one Product Backlog Item. The time box ends only when the group feels they’ve understood the technique and feel comfortable with it.

Time Box 2 and 3 — Split in small groups

The group is then split up into sub-groups of maximum 3 people. The split is made in such a way that expertises are mixed evenly. You as the facilitator can use the intake to assert the team brings the right combination of participants.

Each sub-group is assigned a part of the service scenario. Depending on the length of the service scenario, these parts are created. In time boxes 2 and 3, each sub-group blueprints the assigned part and creates Product Backlog Items for it. At the end of the time box, it presents results to the others.

After time box 3, the whole group completes around 50% of the Service Blueprint and associated Product Backlog Items.

Time Box 4 — From a broader perspective

In this time box, the whole group looks at the service scenario from a broader perspective. They look at the service as a whole. This adds an extra dimension to design and often invokes smart choices.

For this time box, the group is split into two sub-groups. Each sub-group attempts to answer the following questions. They are also encouraged to add their own questions to this list.

when is the journey successful?
how do we measure this?
when does the experience break down?
whom do you need to realise this?
what are you NOT going to do?
what keeps you up at night?
where can we be smart?

A short round of reflection follows outlining how this perspective helped to design a better service.

Closing

We applaud the group for their energy, do a short round of feedback and close the workshop by asking the group to clean up. Cleaning up acts as a wonderful closing ritual.

—

And that’s how we facilitate a Service Blueprinting workshop. A format that allows for structured conversations, identifies bottlenecks and creates a sense of ownership for the service. We encourage you to try it out and get back to us with feedback.