How to define ‘service’?
Originally published 2021, updated 2025
Defining what a 'service' is sounds straightforward. In practice, it's one of the most contested conversations in any organisation attempting transformation.
Over the past decade, I've worked across government, health and private sector organisations, and in almost every case, the absence of a shared understanding of what 'service' means creates real problems before the design work has even begun.
Health context has sharpened the thinking
Much of the refinement in this framework came from working with NHS Digital. Health services are among the most complex service environments: networked, interdependent, and rarely linear. When service design practitioners tried to apply standard 'end-to-end' service thinking in that context, they found it overwhelming. The scale felt impossible, the scope unclear, and the language just didn't fit.
That experience made clear that oversimplifying service design narratives, reducing everything to a single journey or a single definition, can become a barrier rather than a help. In complex organisations, people need precise language to describe their part of the system without losing sight of the whole. Good communication and shared understanding aren't a nice-to-have. They are a fundamental condition required for anything else to work.
The framework draws on a decade of practice and research
Developing this thinking involved interviewing practitioners across government and health who had worked on service strategy, service lists and digital transformation, and reviewing existing frameworks from GDS, Lou Downe, Richard Pope and Kate Tarling. The five considerations below aren't a definitive taxonomy. They're a practical framework that has helped teams and leaders in complex organisations describe their service reality more clearly, and work together more effectively across it.
1. Services are networks, not linear paths
Service journeys are not straight lines from start to finish. They are networked and interconnected systems, where people move in and out at different points, across different channels and organisations. Language like 'end-to-end' can imply a linearity that doesn't exist, and a design that follows that assumption will miss the complexity.
What this means in practice
Use language like 'whole service' or 'service system' rather than 'end-to-end'.
Help stakeholders understand the networked nature of delivery, not as a problem to solve, but as the reality to design within.
2. Services are delivered in parts, by different owners
No single team or organisation delivers a whole service. Journeys are made up of parts: owned by different teams, built on different technology, operating under different mandates. Together, these parts make the whole, but they are rarely designed by a single team.
What this means in practice
Be explicit about where organisational structure or boundaries create complexity for users and tackle these areas as potential risk areas.
Even when you can't design the whole service, you can design better connections across it.
3. The service as experienced is what matters — not what was intended
When we try to understand a service, we need to look at the actual journey as experienced by the people who use and deliver it, including all the unintended parts that nobody designed. The gap between intent and implementation is where most service failures live.
What this means in practice
Be clear about the difference between intended and actual service states.
Measure performance against the service as it is, not as it was designed to be.
Make the case for human-centred approaches in terms of business and policy value, not just user experience.
4. Not all service journeys are goal-based
The standard service design model assumes users have a goal they're trying to achieve. In health, particularly, that framing breaks down. A person managing a long-term condition isn't trying to 'achieve' a goal. They are in an ongoing relationship with a service, aiming to achieve the best possible health outcome they can. This is a relationship that may never reach a clear conclusion.
What this means in practice
Be sensitive to the nature of the journey when defining success. In health, a good outcome isn't always the achievement of a goal.
Health services involve multiple, sometimes competing motivations: patients, clinicians and organisations all have needs and obligations that must be held together in the design. Understanding these is part of designing well in this space.
Look at motivation and triggers as well as goals. Why someone is doing something matters as much as what they're trying to do. Having a valid passport or travel vaccine isn't a user goal. Going on holiday is. The passport is a government requirement that stands between the person and what they actually want to do, and the vaccine is a risk mitigation.
5. Services are best described by their qualities, not a single definition
A service is never just one thing. It has a shape, a position, a set of relationships, and a context. Trying to capture all of that in a single definition of 'service' is a losing battle. A better approach is to describe services additively, building up a picture from multiple qualities rather than narrowing down to a label.
What this means in practice
Use qualities or tags to describe services rather than definitions.
Bring together the perspectives of UCD teams, enterprise architects and operational managers; they often describe the same thing in different languages.
In conclusion
Getting shared language around 'service' right is unglamorous but necessary work. It doesn't produce a visible output, and it can be hard to put a value on. But in every organisation I have worked with, its absence shows up everywhere: misaligned teams, siloed business areas, broken handoffs, digital product teams working in isolation and a service journey that puts the burden of all of this onto its users.
Getting service right is the foundation on which everything else is built.
——
This post sits alongside others that look at related questions: Design bias in ‘service blueprints’ and How to understand ‘services’ as a tool for your whole organisation
