Service Blueprint Year 5 IxD · Live Tool
Intro · Year 5 Interaction Design · 60-min class

Service
Blueprints.

A view of the whole system, not just the screens. What the customer touches above the glass, and the people, handoffs, and systems that hold it together below.

01 / The question this tool answers
What's the difference between designing an experience, and designing the service that produces it?

A service blueprint is the tool for the second question.

A customer journey map centres the user. It traces one person's experience across touchpoints, emotions, and decisions. It's a powerful tool, but it stops at the glass.

A service blueprint keeps going. It exposes what's below the glass: the people, interfaces, handoffs, and systems that actually produce the experience. The screens you design are the top layer of a much deeper stack, and most service failures don't happen on the screen. They happen in the handoffs the customer never sees.

02 / You already know one of these

Journey map or blueprint?
The difference is where it stops.

Journey Map

Centres the user.

Traces one person's experience across touchpoints, emotions, and decisions in time. Deep on the felt experience. Stops at the glass.

Service Blueprint

Centres the system.

Does everything the journey map does, and keeps going. Exposes the people, systems, and handoffs that actually produce the experience. Goes below the glass.

03 / When to reach for one

When a blueprint earns its keep.

A blueprint is not always the right tool. It pays for itself when you need to reason about the system, not just the screen.

A

Designing a new service from scratch.

To force specificity about operations before anything ships. You find the gaps while they're still cheap.

B

Debugging a service that's failing.

The customer symptom is rarely where the problem is. A blueprint lets you trace the failure back to its source below the line of visibility.

C

Aligning a cross-functional team.

One shared artifact where research, ops, tech, and design can argue from the same picture instead of their own.

D

Preparing for an operational change.

New policy, new vendor, new automation. A blueprint shows what ripples to everything the change touches.

E

Finding fragile handoffs.

Most breakages live at handoffs between people, teams, or systems. A blueprint puts every handoff on one canvas.

F

Translating research into operations.

Turn 'customers are frustrated at pickup' into specific backstage actions and support processes that need changing.

04 / Anatomy

Five rows.

Read top to bottom. The further down, the further from the customer.

01

Physical evidence

What the customer encounters. Signage, app screens, receipts, the yellow bag.

02

Customer actions

What they do, in sequence, across time.

03

Frontstage actions

What employees or interfaces do, visibly, in response to the customer.

04

Backstage actions

What employees do that the customer doesn't see. The hidden work.

05

Support processes

Systems, vendors, internal teams, databases: everything that enables the whole thing to work.

05 / The part that matters most

Three lines.

The rows are useful. The lines are the point.
Line of interaction

Sits between customer and frontstage.

Every crossing here is a touchpoint. This is the line the journey map already draws.

Line of visibility

Sits between frontstage and backstage.

Below this line, the customer sees nothing. Most service failures hide here. This is the line that makes a blueprint a blueprint.

Line of internal interaction

Sits between backstage and support.

Handoffs between people and the systems they depend on. Where an employee hands work to a database, a vendor, or another team.

06 / How to build one

A way in.

There is no single right order, but this one teaches well. Work outside-in: start where the customer is, move inward.

01

Pick a tight scenario.

One service, one user, one moment. "Returning an online purchase to a store," not "Amazon." Scope is the whole game; it's better to do one slice well than the whole service poorly.

02

Lay out five to seven customer actions, in order.

These become your columns. Chronological. If you find yourself wanting eight or nine, that's a signal your scenario is too big, not your blueprint too small.

03

Fill in physical evidence and customer actions.

What the customer sees, touches, receives at each step. What they actually do. This is what your journey map would already show you.

04

Draw the line of interaction.

This is the line your journey map already implies. Everything you write below it, the customer never directly does.

05

Fill in frontstage, then backstage.

Frontstage: the visible response from staff or interface. Backstage: the hidden work that makes the frontstage possible. Be specific. "Staff inspects item, scans barcode, confirms against order" is more useful than "Staff helps."

06

Draw the line of visibility.

This is the blueprint's defining move. Below this line, the customer can't see what's happening. This is where most failure lives. If you drew this line wrong, the whole blueprint is wrong.

07

Fill in support processes, then draw the line of internal interaction.

The systems, vendors, databases, and teams your backstage depends on. The line of internal interaction marks where an employee hands work off to a system or another team.

08

Review for fragility.

Scan below the line of visibility. Which of those cells, if they broke, would collapse the customer experience? Those are your fragile handoffs. That list is the point of the whole exercise.

07 / Scope discipline

Four rules, before you start.

01

Five to seven customer actions. No more.

The constraint forces you to think about scope, not exhaustiveness. If you need more steps, your scenario is too wide.

02

You are not making a detailed journey map.

If the only thing you've added is more rows, you're not using the tool. The strategic value is in the lines.

03

Be specific about what's above and below visibility.

When your group disagrees about where a cell belongs, that's the interesting moment. Don't paper over it; surface it.

04

Diagnostic, not documentation.

The point is to see fragility, not to frame a poster. The day you print and frame a blueprint is the day it stops being useful.

08 / If you remember three things

What a blueprint is for.

01

The lines, not the rows.

The strategic value sits in where you draw the three lines. The rows are scaffolding for the lines.

02

Below visibility is where failure lives.

Most breakdowns are not on the screen. They are in the handoff the customer never sees. The blueprint is how you find them.

03

Shift the conversation from screens to operations.

This is the move Year 5 designers haven't made yet. The blueprint is the tool that makes it unavoidable.

Now you

Pick a scenario
and try one.

Scenario · Active Worked example · Read-only reference