Written by: Laura Blumenthal

For the design enthusiasts in our network, I have a question for you: When you’re working on a design project at your organization and create a customer journey map, do you ever feel like you still only have partial visibility into the challenge?

Many human-centered design methods we teach in Catalyst, our training program in human-centered design, focus on understanding the context of a problem and building empathy with the end-users and stakeholders impacted. Taking those steps to understand the customer journey is necessary and important.

But the Catalyst design methods won’t necessarily give you insight into interdependencies within the system and the ripple effects your redesign might have on the organization and its partners, or what it will take to sustain new changes.

I recently started serving on the San Francisco chapter board of the Service Design Network and I’m learning a lot about service design: a design discipline that approaches the design of services with an “end-to-end” systems lens.

Service designers explore challenges from the end-user’s perspective, while also understanding the frontline and back-office staff activities, core operations, infrastructure and equipment, and partnerships that make the service a reality. Although the service design discipline is lesser known in the U.S., it is more established in Europe and is embraced by the U.K. government, including the National Health Service. Here is a primer on how they’re applying service design.

As with the human-centered design practice familiar to our Catalysts, service design has some of its own lingo, which you can read about more in the links I include in this article.

I’ll instead cut to the helpful part: I have a new, life-changing design tool that you can start using today.

It’s called a service blueprint, and it is a — if not the — foundational method of service design. It is an extension of the journey map (a Catalyst favorite) that maps the interactions, activities, infrastructure, and equipment involved in delivering a service, from end to end and throughout the value chain.

You might ask: Why learn about service blueprinting? My journey maps are keeping me busy enough!

I’m sharing the service blueprint with you for three reasons:

  1. The method truly shines when applied to services in complex systems, like health care.
  2. Many Catalyst teams choose to work on projects that are focused indirectly on the customer’s experience. Often the projects focus on how different roles and teams work together to provide a quality, sustainable service (via new protocols, scripts, workflows, etc.).
  3. I am a BIG fan of service blueprints. If we had any wiggle room in our Catalyst program curriculum, I would without doubt add a module on service blueprints.
How To Do a Service Blueprint

There is a F-A-B-U-L-O-U-S blog post from Cooper, a design and strategy consultancy, that explains how to make a service blueprint. The article outlines a few key points about the method’s utility:

  • Like many design methods, you can use service blueprints for a variety of purposes.
  • The service blueprint you create is not precious — it’s a point of discussion and is a working document that will change.
  • The service blueprint is highly collaborative. Sometimes it’s created for the purpose of sparking discussion among different stakeholders, and it may not ever be codified.

And for the lean enthusiasts: it’s a way to connect the information that you’d normally put in a value stream map with the user experience.

Here are some key elements that structure the service blueprint framework, outlined in the blog post.

Every blueprint includes these two constructs:

  • Line of interaction: Things that cross this line denote customer interactions with the service. These customer interactions take place at service “touchpoints.” Touchpoints can be anything from a customer’s conversation with employee, to use of a device, a form, or another interface.
  • Line of visibility: Everything above this line are actions customer can see. Everything below the line of visibility are actions the customer cannot see but that contribute to the service.

Some places add a line of internal interaction, as well.

In its simplest form, a blueprint has five sections, or “swim lanes,” that orient around the lines of visibility and interaction:

  • Customer actions | above the line of interaction: The actions the customer takes to engage with the service. This looks a lot like what you would include in a user journey map.
  • Touchpoints | above the line of interaction: These are the instances at which the customer directly interacts with the service. Some examples of touchpoints might be a registration form, a reminder email, an onboarding conversation, an educational workshop, and a feedback survey. Some people refer to these as “physical evidence” that a service is taking place.
  • Frontstage staff | below the line of interaction, above the line of visibility: People’s activities, that the customer sees and may engage with during the service.
  • Backstage staff | below the line of visibility: People, activities, and technology that the customer can’t see but play a role in delivering the service.
  • Support processes | below the line of visibility: Protocols, infrastructure, partnerships that aren’t solely there for the service make stuff run.

As an exercise to see how it comes together, I created a service blueprint for our Catalyst program in its current state. This will support discussion on how we might scale the program to bring design mindsets and methods to more people working in the safety net.

Catalyst Program: Current State Service Blueprint

Just walking through the exercise made me reflect in a few ways:

  • I realized that I could provide an ENDLESS amount of detail. So next time, I need to be very clear on the level of operational “zoom” I need to discuss strategic questions. I will likely revise this one to zoom into one section of the end-to-end service that is the most resource intensive (e.g. “Program Activities” section).
  • The exercise also surfaced opportunities for efficiency. For example: why do we ask people to complete Eventbrite forms before each Catalyst workshop, when it’s always the same people who attend? And it’s duplicative information with what’s on the Community Page? Couldn’t we remove one of these steps? (We’ll try!)

I look forward to using service blueprinting to frame discussions about how we could deliver Catalyst in different ways, and how the model might change.

As with all frameworks, service blueprints are less about following specific rules of execution, and more about adapting it in ways that are useful to you and can help your team collaborate, communicate, or problem solve better.

Did you find this useful? Let me know. Below are more resources from people who really know what they are talking about if this whet your taste buds.

                          

                           

Find this useful or interesting? We’re constantly sharing stuff like this. Sign up to receive our newsletter to stay in the loop.