service design

Service design is not user experience design at greater scale

Simon Morgan-Wilson

12 May 2026 • 7 min read

Preface: What's going on here?

These thoughts were poked to the forefront a few months ago leafing again through one of my foundational reads around service design. And then I was seeing people saying service design is UX design at greater scale. And then seeing UX design being presented as service design.

So, I've put my head down here and there over the last few weeks to lean into my service design and system thinking foundations and weave in some now. Throughout I've tried to reference some of those foundations as references. Think of this as a brain-mashing in progress. There are likely to be holes and flaws.

Service design as systems work – not bigger UX

Service design gets framed, again and again, as user experience design at greater scale. That framing to me is wrong, wrong, wrong – and the wrongness is consequential. Most people who claim to have moved from user experience design (UX) to service design haven't really moved. They've added stakeholder maps and front-stage/back-stage diagrams to a fundamentally interface-shaped practice. This is just reportage, conceptualising the front-end, the interactions. Service design is a shift in what you're designing, not how much of it.

What you're actually designing is different

UX takes a piece of a system, an app, a flow, a touchpoint, and tries to make it work well for the person using it. The system is held constant. You inherit the business rules, the back-office processes, the technical platform, the organisational boundaries. Within those, you design.

Service design works the other way round. The system itself is what gets designed. The screen, the form, the call centre script, the letter: these are outputs of decisions made elsewhere, and those decisions are the ones to question. If a person abandons a journey, a UX response is to redesign the journey. A service design response is to ask why the journey exists in that shape; which policy created the form field, which integration constraint produced the wait, which team's incentives produced the handoff.

This isn't a matter of zooming out. Zooming out is still a UX move. Service design is doing different work. Lou Downe's Good Services makes this distinction more clearly than anything out there.

What systems thinking actually gives you

The working vocabulary here comes from Donella Meadows, whose Thinking in Systems and her 1999 essay on leverage points are foundational. The concepts below are hers, summarised briefly, the service-shaped examples are mine.

Feedback loops. Services have reinforcing and balancing loops that produce their behaviour over time. A queue forms, so the service tightens eligibility, so people work around the rules, so caseworker time goes up, so the queue gets worse. None of that is visible in a journey map, because journey maps are snapshots.

Stocks and flows. A service runs on accumulations and rates: backlogs, capacity, trained staff, unresolved cases. Many "user experience" problems are actually stock problems wearing a UX costume. Waiting time isn't a user interface problem: it's the consequence of an inflow exceeding an outflow somewhere in the operational chain.

Leverage points. Meadows' central insight is that the highest leverage interventions in a complex system are structural (paradigms, goals, rules, information flows) rather than parametric (numbers, settings, copy). Most UX work sits at the bottom of Meadows' hierarchy. Service design earns its name when it operates higher up. A useful diagnostic falls out of her argument: when you finish a piece of work, ask whether you changed a number, a buffer, a delay, a rule, a goal, or a paradigm. If the only honest answer is "a number", that's fine, but it's UX.

Unintended consequences and dependencies. Any change to one part of a service produces effects elsewhere. A "delightful" front end can swamp a back office. A clarified letter can drive a spike in calls. Designing without modelling these dependencies is the systems equivalent of refactoring code without running the tests.

Where services actually live

There's a useful iceberg picture worth pairing with all of the above: Downe uses a version of it in Good Services and it's still the clearest way to make the point.

What the user touches is a small fraction of what the service is. Underneath sit the operational workflows, the case management systems, the legacy databases, the data-sharing agreements, the regulatory regimes, the funding mechanisms, the contracts, the supplier ecosystem, the staff training, the audit requirements, the political and historical context that produced any of it. The service is the whole of that, in motion.

UX work treats the visible bit as the thing. Service design treats the visible bit as a symptom, and the rest as the territory of intervention.

It's not UX plus extras

Becoming a service designer is not UX plus extra.

It involves trading off some of the depth of interaction craft for literacy in adjacent disciplines: organisational design, policy and regulation, enterprise architecture, operations, procurement. Dan Hill's Dark Matter and Trojan Horses is clearest in this expanded territory, the "dark matter" he describes is most of that list. (And probably where I started nabbed "dark matter" to refer to this.)

I don't think you need to be the expert in any of these, but you do need to have enough knowledge to understand them, to hold a useful conversation, to recognise where the real constraints are, to know what levers needs changing and how, and to call out when a stated constraint is actually a convention dressed as a constraint.

Most of the daily work is talking to people in those disciplines, not making artefacts. The artefacts get less polished, the meetings get longer, the wins are harder to put in a portfolio. A working service is the deliverable. Very little else counts.

The cosmetic service design trap

The practice that uses the language of service design without doing any of the systems work. We have all seen it. This sits in Hill's territory directly: design work that doesn't engage with the organisational, political, and contractual matter above the designer's head is decoration.

A team produces a beautiful blueprint. The blueprint sits next to an unchanged back-office process. The recommendations are about the front end. Nobody renegotiates a contract, changes a policy, redesigns a team structure, retires a system, or amends a funding flow. The blueprint becomes a research output. The blueprint is filed.

This happens partly because the systems work is genuinely hard and slow, so slow. Partly because it requires authority the design team often doesn't have. And partly because the incentives in many organisations, and inside the design profession itself, reward visible output over structural change.

The honest test of a service design engagement is whether anything structural is different a year later. A year later. If only the screens have moved, it was UX with a vocabulary upgrade.

Why this matters more in 2026

Two things make this shift urgent now. (He says remembering saying this in 2020. And then 2017. And...)

The first: The parts of UX that were the day job, wireframes, flows, component-level decisions, are increasingly the things AI could probably do fastest. The economic value moves up the stack, towards the work AI can't yet do well: framing the right problem, navigating organisational politics, holding the model of a complex service in your head, deciding what to design and what to leave alone.

The second is that the services that most need design attention are the gnarly ones: public sector, healthcare, finance, regulated industries. These services are not failing because their interfaces are bad. John Seddon has been arguing this for thirty years – and the evidence has only accumulated. They are failing because their underlying systems were assembled over decades, with overlapping incumbents, contested ownership, and contradictory goals. You can't UX your way through that, adding to the papier-mâché. You can only design with it, by being literate in how it actually works.

What this really requires is a change in stance. Stop treating the service as something to be improved at the edges. Start treating it as something whose shape can be redesigned, slowly, by people willing to do the unglamorous work in the middle of it.

the tldr

Service design isn't just doing the screens. Service design isn’t just user experience (UX) design at greater scale. It changes what you're actually designing. UX takes the system as given and improves a component within it. Service design treats the system itself as the thing being designed, which means engaging with policy, operations, contracts, technology, and organisational structure rather than just screens. The most powerful interventions sit furthest from the interface, at the level of rules, goals, and information flows. Anything less, however well presented, is UX with extra vocabulary. Deal with it.