DePlaybook › Frameworks › Service Design
FRONTSTAGE Book Confirm Arrive Service Pay LINE OF VISIBILITY BACKSTAGE Booking DB Email svc Assignment Fulfilment Payment API SUPPORT CRM system 3rd party integration Billing system service design · frontstage · line of visibility · backstage · what users see and what causes it · design the full system
Framework ⚡ High

Service Design

Design the full experience — including everything users never see but always feel.

Customer Experience Multi-Channel Design Organisational Design Service Blueprinting Touchpoint Mapping Public Services

01 — TL;DR

Two sentences.

Service Design is a discipline and framework for designing the complete experience a person has with an organisation — not just the interface they interact with but the full system of touchpoints, channels, backstage processes, and human interactions that together determine whether the service works as experienced — making visible the operational and organisational factors that are invisible to the user but directly responsible for whether their experience is good or bad. The central instrument of Service Design is the service blueprint — a map that extends the user journey by adding the frontstage processes users see, the backstage processes users do not see but which directly affect their experience, the support processes that enable the frontstage, and the physical evidence present at each stage.

Service Design as a formal discipline emerged from the work of Lynn Shostack at Citibank in the early 1980s — her 1984 Harvard Business Review article "Designing Services that Deliver" introduced the service blueprint concept — and was developed into a comprehensive methodology by practitioners including the Service Design Network and Marc Stickdorn through the foundational text This is Service Design Thinking. For product teams, Service Design's most important contribution is the explicit acknowledgement that digital interfaces exist within operational systems: the booking flow works perfectly but the confirmation email is sent by a different system with the wrong format; the support chat resolves the issue but the resolution is not communicated to billing so the charge recurs. These systemic failures cannot be solved by interface design alone.

02 — When to Use

Apply this when…

→ A user experience spans multiple channels — mobile app, website, telephone support, email, physical location — and the handoffs between channels are causing failures
→ Customer satisfaction scores are low despite a well-designed interface — indicating that the experience failure is operational or organisational rather than interface-level
→ A new service is being designed from scratch that will require both digital touchpoints and human or operational touchpoints — designing only the digital components will produce a partial experience
→ A recurring customer complaint is being investigated and the root cause is suspected to be in a backstage process rather than in the visible interface
→ An organisation is undertaking a digital transformation where physical or telephone touchpoints are being replaced by digital ones — Service Design ensures the transition maintains experience quality
→ Public services, healthcare, financial services, or other regulated sectors are designing experiences that are legally and operationally complex — Service Design's systems perspective is essential

When NOT to apply it

Skip it when the product is a single-channel, self-contained digital tool with no human touchpoints and no operational dependencies. Also skip it when the team has neither the organisational access nor the mandate to influence backstage processes — Service Design requires the ability to redesign operational systems, not just interfaces. And skip it when the service is already well-understood and the problem is specifically interface-level.

03 — How It Works

The mechanism

Service Design works by making the full system of experience visible simultaneously — the user's journey, the visible touchpoints, the backstage processes, the supporting systems, and the evidence present at each moment — in a format that allows designers, operations teams, and stakeholders to see how every element connects and where the gaps, failures, and friction points are. This visibility is the prerequisite for redesigning the system: problems that are invisible cannot be fixed, and systemic problems that appear to be interface problems cannot be fixed at the interface level.

01
The line of visibility separates what users experience from what causes it
Lynn Shostack's original service blueprint concept introduced the "line of visibility" — the distinction between frontstage processes that users see and interact with and backstage processes that users never see but that directly determine the quality of their frontstage experience. Above the line: the bank teller, the ATM screen, the mobile app, the confirmation email. Below the line: the account verification system, the fraud detection process, the internal ticket that must be created before a charge can be reversed. The line of visibility explains why so many experience failures are attributed to "bad design" when the actual cause is a backstage process failure that the visible interface cannot fix.
02
The service blueprint and its five layers
The service blueprint maps the service across five horizontal layers. The top layer shows physical evidence — the artefacts and digital touchpoints present at each stage. The second layer shows user actions — what the user does at each stage. The third layer shows frontstage interactions — the visible contact with service employees or automated systems. The fourth layer, below the line of visibility, shows backstage interactions — actions service employees or systems take that users do not see. The fifth layer shows support processes — the internal systems and third-party integrations that enable backstage. The blueprint makes every dependency visible, revealing where a frontstage failure is actually caused by a backstage or support process problem.
03
Most customer experience failures are backstage, not frontstage
The most strategically important Service Design insight is that most customer experience failures attributed to "bad design" are actually backstage failures that the frontstage interface cannot fix. A user who books a service through a beautifully designed app but receives no confirmation has not experienced a design failure — they have experienced a failure in the backstage notification process. A user who contacts support through a well-designed chat but does not get their issue resolved has experienced a failure in the backstage process the agent relies on. Service Design makes this distinction visible and actionable: it prevents teams from redesigning the interface to fix operational problems.
04
How to measure it — failure attribution, cross-channel NPS, blueprint coverage
Service Design produces three types of measurable output. Experience failure attribution measures what proportion of complaints are attributable to frontstage touchpoint problems versus backstage process problems — a high proportion of backstage-attributed failures indicates interface redesign is not the solution. Cross-channel NPS measures satisfaction separately across each channel and at handoff points — satisfaction drops at handoffs indicate service system failures. Blueprint coverage measures the proportion of the service that has been mapped and is therefore within scope for systematic improvement — unmapped parts are invisible and therefore unimprovable.

Service Design vs UX vs CX

Service Design is distinct from Customer Experience (CX) design and from UX design, but is related to both. UX design focuses on the quality of specific digital touchpoints. CX design focuses on the overall perception users form across all interactions. Service Design focuses on the operational and organisational systems that determine whether those touchpoints actually deliver. A service can have excellent UX on individual touchpoints and poor CX overall because the backstage systems connecting those touchpoints are broken. Service Design addresses the systemic layer that neither UX nor CX typically owns.

04 — Real Example

Heathrow Airport and the baggage claim service blueprint

When Heathrow Airport's service design team investigated why baggage claim consistently produced the most negative passenger feedback despite being a relatively simple operation, they mapped a service blueprint that revealed the system's full complexity. The frontstage experience from the passenger's perspective: exit the aircraft, navigate to baggage claim, wait for luggage, collect it, and exit. Simple. The backstage reality: twelve separate handoffs between aircraft crew, ground handlers, baggage system operators, customs processes, and belt assignment systems.

The blueprint revealed that the most common cause of baggage delay was not a mechanical problem. It was a communication failure between the aircraft arrival system and the belt assignment system: bags were ready but assigned to the wrong belt, or the correct belt was not communicated until after a significant wait. The frontstage design was not the problem; the backstage communication protocol between two systems owned by different operational teams was. The solution — a direct API connection replacing a manual process — was an operational change that no amount of frontstage redesign could have produced.

Heathrow Airport · Baggage Claim
Service blueprint reveals backstage failure invisible to frontstage design
PASSENGER Exit → Navigate → Check display → Wait → Collect FRONTSTAGE Display screens · signage · staff LINE OF VISIBILITY BACKSTAGE Unload Log arrival Belt assign ✗ Route Deliver SUPPORT Aircraft arrival sys ⚡ Belt assignment sys Manual comms between two systems · bags ready, wrong belt · fix: direct API connection Operational change, not design change Heathrow baggage claim · backstage communication failure · operational fix
Doing it right — operational fix, not interface fix

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a service where the digital interface is polished but the overall experience is broken — or one where even the non-digital parts feel designed and coordinated? Submit what you observed.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Service Design applied well or ignored in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Mapping the ideal journey instead of the actual journey. A service blueprint built from stakeholder descriptions of how the service is supposed to work produces a map of the intended service, not the actual service. The intended service rarely matches reality: backstage processes have workarounds, handoffs that should be automatic are manual, systems that should communicate do not. Blueprints must be built from direct observation — watching the service be delivered, interviewing frontline staff about what they actually do. An ideal-state blueprint is a specification, not a diagnostic tool.
✗ Stopping the blueprint at the line of visibility. Blueprints that document only the user journey and frontstage touchpoints — essentially an extended journey map — miss the backstage layer that makes Service Design analytically distinct. The line of visibility forces teams to ask: for every frontstage experience, what backstage process makes it possible, and what backstage failure could break it? Teams that produce blueprints without a backstage layer produce a sophisticated journey without the operational insight that makes it fixable.
✗ Using Service Design to produce a blueprint without an operational mandate. A service blueprint is a diagnostic and design tool — its value is in the redesign of the system it maps. Teams that produce comprehensive blueprints and then have no mandate to change backstage processes have produced documentation rather than change. Service Design requires the authority to change operational processes, not just interface elements. Design teams given a brief to "improve the customer experience" without operational access will produce interface improvements that are correct and insufficient.
✗ Conflating Service Design with journey mapping. Journey mapping traces the user's experience across stages. Service Design uses the journey map as one layer of a more comprehensive blueprint that extends below the line of visibility. Journey mapping identifies what the user experiences and how they feel; service blueprinting identifies what organisational factors are causing those experiences. A team using journey mapping as a substitute for blueprinting will identify symptoms — "users feel frustrated at payment" — without identifying the cause — "the payment system makes a synchronous call to an unreliable third-party that times out 12% of the time."

07 — Variations & Related Principles

Connected ideas

Service Design is the broadest design discipline in the product and UX toolkit — it encompasses the full system of touchpoints, processes, and organisational functions that constitute a service. Its closest relationships are with the methods that generate its research inputs and with the strategic frameworks that apply its systemic lens.

Journey mapping is the frontstage layer of a blueprint
Journey Mapping
HCD provides the research foundation; Service Design extends scope
Human-Centered Design
The research method for observing front and backstage
Contextual Inquiry
Design Thinking provides the ideation process for system redesign
Design Thinking

The most important pairing is Service Design with journey mapping. Journey mapping reveals the user's experience of the service; service blueprinting reveals the organisational and operational system causing that experience. Neither alone produces the complete picture needed to redesign a complex multi-channel service. Together they produce the comprehensive view — what users experience and why — that makes complex service redesign tractable.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Failure Attribution Test

1. Think of the last three customer complaints or negative feedback items your team has received. For each one, write down the symptom as the user described it — the frontstage experience failure they reported.

2. For each complaint, trace the causal chain backward from the frontstage symptom: what backstage process, system, or handoff would have to fail for the user to experience what they reported? Write down the most likely backstage cause. If the failure was genuinely in the interface rather than an operational process, note that too.

3. Classify each complaint as frontstage-caused (the interface or visible touchpoint was the problem) or backstage-caused (an invisible operational process, system, or handoff was the problem). Be honest — the temptation is to classify everything as frontstage because that is the team's domain.

4. Calculate the ratio: what proportion of your recent complaints are backstage-caused? If more than a third are backstage-caused, your product has a Service Design problem that interface improvements cannot fix — and the next step is mapping the backstage processes that are producing the frontstage failures your users are reporting.

10 minutes