Service Blueprints Workshop
Overview
Constraints
Audience
Role
ProbleM

An introduction to Service Blueprinting as a way to make cross functional collaboration more effective .

Design at redIQ had been non-existent for almost 2 quarters. The handoff process was inefficient. Devs weren’t getting the support they needed in knowledge transfers.

Internal Product Teams

Instructor & Facilitator

Run a 2 hour workshop to diagram a workflow & its user touchpoints, and the services on-stage and backstage processes.

Process
Step 1 // User journey map


It helps to have a basic understanding of what the user is currently doing or attempting to accomplish to complete a task successfully.  This can be accomplished with a low fidelity artifact like a storyboard, or something higher in fidelity like journey or experience maps informed by deep enthnographic research. Wherever you are in your products design process maturity, bring something to the meeting to act as a starting point.

Step 2 // Select participants


Anyone from the org can participate so long as two criteria are met. There is a sufficient representation from design, product, & development; Those selected have enough domain knowledge to be able to contribute to the process.

note: This doesn’t exclude additional team members from participating. I recommend it, as this process is very effective in getting new team members up to speed on the product and all of its moving parts.

Step 3 // Set a time, set a place


Make sure that place has a whiteboard and a lot of sticky notes and markers. It’s also important to timebox these activities. While the process can be very liberating for your team in getting a holistic vision of your product, the process can be very monotonous if the session is drawn out.

Step 4 // Put the knowledge up

This step is always super precise. It’s one of those processes that relies on iteration. Just get the service up there. I needs to include what the user does, sees, doesn’t see, and friction/opportunities for us to make improvement. This includes areas of ambiguity that need to be solved thru design experiments and development spikes.

Step 5 // Preserve the artifact


Take photographs of your wall often so you don’t forget anything that might shift during the process. Eventually your efforts should make their way into a digital format. You can use a whiteboard tool like Lucidchart or Mural; a design tool like Sketch or Figma; or a spreadsheet like Excel. I recommend a tool that allows for multiplayer editing, especially for remote teams.

I store photos of progress with the digital version of the blueprint. It serves as a record of thought captured in space which helps facilitate memory & recall. It also provides smart people at the sticky wall photos for your case studies.
Results
Learnings

We spent 3 hours in this workshop and training  session. From there the development teams went into Domain Driven Design meetings to determine best methods of breaking up the process into code. These DDD meetings were notorious for taking multiple days worth of workshopping or around 30 hours. After the Service Blueprint workshop, they were able to complete their workshop in around 4 hours over two sessions.

Based on an estimated average salary of developers who participated in both the Service Blueprint Workshop & the Domain Driven Design workshops I saved the org of somewhere between $4-11K in the first week. If this is protracted out to a full year the savings would be $24-70K annually (or that intern we we were able to hire.)

Workshops rarely go as planned. The initial workshop was scheduled for two designers, two developer leads, & two product managers. Then I got sick. When I returned, the day before the workshop, I found that the invite had been extended to the entire product team companywide. This meant I wasn’t going to simply facilitate a simple workshop, I had to teach the principles as well.

It turned out great.

Never let an opportunity to educate design principles to non-traditional designers go to waste.

3 hours is a long time.
 Remember to regular breaks; at least hourly.

Establish expectations early. 
In the case of service blueprints, they aren’t ever ‘done.’ We are identifying both what is and what can be. When those changes do come, the blueprint needs to change too. With this in mind, define what done looks like for today. I usually kick this workshop off with something like, “Let’s get the gist of user journey in place and identify the major front and backstage events. We can identify areas of ambiguity to come back to later this week.”