Service Blueprint

“You may be familiar with customer journey mapping, which is a tool that allows stakeholders to better understand customer interactions with their product or service over time. The service blueprint contains the customer journey as well as all of the interactions that make that journey possible.”

There are three essential requirements for a formal service blueprint:

  • The line of interaction: This is the point at which customers and the service interact.
  • The line of visibility: Beyond this line, the customer can no longer see into the service.
  • The line of internal interaction: This is where the business itself stops, and partners step in.

In between these lines are five main swimlanes that capture the building blocks of the service:

  • Physical evidence: These are the props and places that are encountered along the customer’s service journey. It’s a common misconception that this lane is reserved for only customer-facing physical evidence, but any forms, products, signage, or physical locations used by or seen by the customer or internal employees can and should be represented here.
  • Customer actions: These are the things the customer has to do to access the service. Without the customer’s actions, there is no service at all!
  • Frontstage: All of the activities, people, and physical evidence that the customer can see while going through the service journey.
  • Backstage: This is all of the things required to produce the service that the customer does not see.
  • Support processes: Documented below the line of interaction, these are the actions that support the service.

For clarity, here are some additional swimlanes we recommend:

  • Time: Services are delivered over time, and a step in the blueprint may take 5 seconds or 5 minutes. Adding time along the top provides a better understanding of the service.
  • Quality measures: These are the experience factors that measure your success or value, the critical moments when the service succeeds or fails in the mind of the service user. For example, what’s the wait time?
  • Emotional journey: Depending on the service, it can be essential to understand the service user’s emotional state. For example, fear in an emergency room is an important consideration.
  • Splitting up the front stage: With multiple touchpoints that are working together simultaneously to create the service experience, splitting each touchpoint into a separate lane (for example, digital and device interactions vs. service employee interactions) can be very helpful.
  • Splitting up the backstage: The backstage can be comprised of people, systems, and even equipment. For detail or low altitude blueprints, splitting out lanes for employees, apps, data, and infrastructure can clarify the various domains of the service.
  • Phases of the service experience cycle: Services unfold over time, so it can add clarity to call out the phases of the experience cycle. For example: how customers are enticed to use the service, enter or onboard to the service, experience the service, exit, and then potentially re-enter the service and are thus retained as customers.
  • Photos/sketches of major interactions: Adding this lane can help viewers quickly grasp how the service unfolds over time, in a comic-book-like view.

Like a customer journey map, a service blueprint is focused on one persona’s experience through a single path. Think of it as a kind of scenario. Your blueprint will quickly become too complex and too difficult to read if you put multiple journeys on a single one, or try to capture service use with many variations. Blueprints show one use case or path over time, so additional blueprints must be used for variations of the service journey.

L Chapman-Ruiz

Use scenarios

Scenarios can help uncover gaps in solutions and potential usability issues.


  • What prompted the persona to embark on the scenario


  • Where is the persona while the scenario takes place?
  • Does the context change over the course of the scenario?
  • Who else is involved?
  • What other devices are involved?


  • What kinds of distractions or interruptions typically occur in the scenario?
  • How does the persona deal with such distractions?


  • What is the persona’s goal in the scenario?
  • Is it information, an artifact, an emotion?

Ginsburg 2011: P.82

User Interface Flow Models

Another common diagram to create is a user interface (UI) navigation or UI-flow diagram (…) to explore how you will architect the UI of your system by exploring the flow between major UI elements, including both screens/pages and reports. This is critical to your system’s success because the user interface is the system to your stakeholders. Not the technology. Not the data. Not really cool frameworks that you’re working with. If you do not architect the user interface effectively you run the risk that you will build a system that your stakeholders aren’t interested in working with. See example from the book ‘Maturing usability

Scott W Ambler

User journeys as narratives: From theme to detailed information

Users can take very different journeys within the same domain and every user journey is a narrative in its own right. A consistent structure of the website and its different sections is key to meaningful journeys that are effective and satisfying. Top levels introduce the big idea first and offer choices to proceed. From every level, a journey can proceed horizontolly, i.e. to related aspects, or vertically, i.e. to subordinate levels that provide greater detail. As every level and branch provides a different perspective on the theme, user itineraries can potentially become very complex. For information heavy sites, consider providing tools that allow users “berry picking”, i.e. managing information collected over the course of the journey.