~$10K
Savings in meeting time in one week
Product and Development understood the product we were building differently. This lead to many rounds of development that did not meet the expectations of stakeholders.
redIQ (a Berkadia Company)
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, 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 without factoring the value of increased speed to market.
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 ethnographic 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.
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 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.”