Service blueprints
Frontstage, backstage, and supporting processes on one canvas. Usually the quickest way to find the gap nobody owns.
What we do · Service lens
Service design.
The parts of the experience that sit around the product. The onboarding email arrives late. Support cannot see what the user just did. Billing uses a different language. None of that is inside the interface, but the user still experiences it as one thing.
What it really is
The product is only one moment in the relationship.
Service design looks at the frontstage your users see, the backstage that makes it work, and the supporting processes in operations, finance, support and training that keep the whole thing running.
A common failure: a strong product that people cannot sign up for cleanly because onboarding lives on another team's roadmap. Or a product that handles most of the journey well and then breaks at the support handoff. To the user, that is still the product.
When service is the problem
A service lens is useful when...
- The user journey crosses multiple channels: web, mobile, call centre, email, branch, partner.
- You are launching a new product on top of an old support model and the friction lives in the gaps.
- Customer satisfaction is fine on the product but bad overall. The shape of the service is the issue, not the screens.
- Two teams are quietly building the same thing because nobody has drawn the full journey.
- An incident exposed a backstage failure that the frontstage was hiding.
- Onboarding works but second-month retention doesn't, and nobody owns the gap between them.
What we deliver
Artefacts that make the whole service visible.
These artefacts put teams that usually work in different rooms in front of the same service at the same time. That is usually when the gaps become obvious.
Journey maps
The user side of the service. Steps, channels, expectations, emotional arc, and the moments where the relationship is won or lost.
Touchpoint audits
Every point of contact across every channel. Who owns it, what it promises, and where the promise starts leaking.
Support flows
How problems escalate and resolve. The shape of the service when things don't go well, which is when service quality really gets measured.
Channel maps
Which channel is doing what work, and where they collide. Useful when web, app, call centre, and partners all think they own the same step.
Role & capability maps
Who needs to be in place for the new service to run. Roles, skills, tooling, and training, drawn so the org-chart shadow of a service redesign is visible up front.
How it connects
Service design widens the frame around the product.
UX looks at the screen. Process looks at the work behind it. Service design follows what happens before, after, and beside the product: channels, support, onboarding, handoffs, follow-up.
Sibling lens
UX design
The screens, flows and small decisions people have to live with.
Sibling lensBusiness process design
How the work moves behind the product. The roles, steps, and handoffs the screens have to support.
You're hereService design
The broader experience around the product.
Service design without UX can become a strategy deck nobody can use. UX without a service view can ship a great screen into a journey that breaks two steps later. The trick is knowing where the risk really sits.
Where it shows up in our process
Service work frames the project, then checks the edges.
It is heaviest in Plan and Gather, where the boundary of the service is set. It returns in Test, when field issues outside the interface start showing up.
Plan
Which service are we really designing?
We frame the boundary: which channels, which roles, which support paths are in scope. The wider the lens, the bigger the conversation about ownership.
Gather
Frontstage, backstage, supporting.
We talk to users on the frontstage, staff on the backstage, and the operations teams whose work the service depends on. Then we put it on one canvas.
Ideation
Multiple service shapes.
Different ways the same outcome could be delivered, weighed against cost, complexity, and how much of the organisation would have to change.
Build
Service shape feeds the product shape.
The chosen service blueprint sets the constraints the product has to honour. It tells UX what the product owns and what it hands off.
Test
Real journeys across the full service.
We test the full service, not just the product. That means following users across channels and watching the handoffs that usually live in nobody's test plan.
A failure in Test usually points to a backstage process or a missing channel, not a screen. We loop back to Gather and adjust the blueprint.
Got a service that's bigger than its product?
Tell us where the experience is breaking. We'll help you see the whole picture and decide what to design first.
Talk to us