Service Design Terms Explained: A Beginner's Glossary

Service design borrows vocabulary from research, operations, policy and product, and then uses several of the borrowed words slightly differently. That is why newcomers often feel lost in a meeting where everyone else appears fluent. The terms below are grouped by how they are actually used in practice rather than alphabetically, with a note on where each one tends to go wrong.

Terms about the service itself

A service is what a person is actually trying to get done, together with everything an organisation does to make that possible. Booking a medical appointment, applying for financial support, returning a delivery: each is a service, and each runs across websites, phone lines, letters, buildings and staff decisions. The common misuse is treating "service" as a synonym for the digital product, which quietly excludes most of what determines whether the thing works.

A touchpoint is any specific point of contact between a person and the service. A confirmation email, a reminder text, a form field, a reception desk and an automated phone menu are all touchpoints. The term is misused when it is applied only to screens, and when teams start counting touchpoints as if fewer were automatically better. Some touchpoints exist because people need reassurance, and removing them saves nothing.

A channel is the medium through which touchpoints happen: web, mobile app, telephone, post, in person. Channels and touchpoints get conflated constantly. A useful separation is that a channel is the route, and a touchpoint is the specific moment on it. Frontstage and backstage describe which side of the line a part of the service sits on. Frontstage is everything the person can see or experience; backstage is everything that has to happen out of sight for the frontstage to be possible.

A service moment is a point in a journey where something meaningful is decided, resolved or lost: the moment an application is submitted, the moment a decision arrives, the moment someone realises they have been waiting too long. There is no settled industry definition here, and some teams use "moment of truth" for the same idea. Treat it as a way of drawing attention to weight, not as a technical classification.

A proposition is the promise the service makes about what it will do for someone, in language they would recognise. It is not a tagline and not a feature list. The misuse is writing a proposition as internal ambition ("a seamless, joined-up experience") rather than as something a user could hold you to. A service ecosystem is the wider system the service sits inside. The Journal of Service Management editorial on service-dominant logic, service ecosystems and institutions describes it as a relatively self-contained, self-adjusting system of resource-integrating actors connected by shared institutional logics and mutual value creation. In plainer terms: many organisations and people whose behaviour shapes an outcome none of them fully controls.

Terms about the people involved

An actor is anyone who participates in creating value, whether that is a customer, a member of staff, a partner organisation or a supplier. The word comes from service-dominant logic, developed by Stephen L. Vargo and Robert F. Lusch, whose later work deliberately replaced producer and consumer language with actor-to-actor networks. The point of the word is that it refuses the assumption that one side produces and the other side receives.

A stakeholder is anyone with an interest in the service or influence over it: budget holders, operational managers, policy owners, frontline staff, regulators. The frequent misuse is using stakeholder to mean senior people who must be kept happy. Used that way, the term quietly reorganises a project around approval rather than around the work.

The distinction between participant and user matters more than it looks. A user is someone who uses the service. A participant is someone taking part in your research, whether or not they are a user. Calling everyone a user flattens the fact that a research session involves a person doing you a favour, and it also hides the cases where the people affected by a service are not the ones using it, such as carers, family members and staff.

Co-design means designing with the people affected rather than for them, in sessions where they genuinely shape decisions. It is one of the most misused terms in the field. Showing a finished concept to users and collecting reactions is consultation, not co-design, and calling it co-design tends to make people cynical about being asked again.

Facilitation is the skill of running a session so that a group can think together and reach a decision, including managing whose voice dominates. It is not the same as chairing a meeting or presenting slides. In practice, facilitation is a large part of what many service designers do, and it is systematically underrated in job descriptions.

A service owner is the person accountable for a whole service, across teams and channels, rather than for one product or one department's part of it. The role appears widely in public sector delivery and increasingly elsewhere. The honest position is that many organisations have the title without the authority to go with it, and a service owner who cannot influence the operational teams is a name in a governance document.

Terms for the artefacts you produce

A journey map shows a person's experience over time, usually as stages, actions, thoughts and feelings, with the pain points marked. It is a communication tool as much as an analytical one. The common failure is a journey map built from what the team assumes rather than from research, which then circulates for two years as if it were evidence.

A service blueprint extends that view downwards. It keeps the user's journey along the top, then adds the frontstage interactions, the backstage activities and the supporting systems and processes underneath, usually separated by a line of visibility. Blueprints are the artefact most likely to change an operational conversation, because they make it visible where a delay actually originates.

An ecosystem map steps back further and shows the actors, organisations and relationships around a service, including the ones nobody in the room controls: partner bodies, suppliers, regulators, community organisations. It answers a different question from a journey map. Ecosystem thinking does not replace journey mapping, and any suggestion that it supersedes it should be treated with suspicion, since the two operate at different altitudes and are most useful together.

A proto-persona is a provisional description of a user type built from existing knowledge and assumptions, created quickly and explicitly labelled as unvalidated. It is a starting hypothesis, useful for exposing what a team believes. The misuse is obvious and very common: a proto-persona that never gets tested, loses its caveat and becomes the thing everyone designs against.

An operational model describes how the organisation actually delivers the service: teams, roles, processes, systems, decision rights and handovers. It is where service design meets operations, and it is the layer most often left undesigned. A redesigned journey that requires an operating model nobody has agreed to will not survive contact with the working week.

Terms about evidence and research

Discovery is the phase of work in which a team learns about the problem before committing to a solution, usually through interviews, observation, existing data and process analysis. The word carries a specific meaning in public sector delivery, where it names a formal phase. Its misuse is the compressed discovery run to justify a decision that has already been taken.

Synthesis is the work of turning raw research material into something structured and defensible: clustering observations, comparing accounts, keeping contradictions visible. It is analytical work, not summarising. When teams skip it, they end up with a highlights reel of memorable quotations and no argument.

An insight is a statement about why something happens, grounded in what was observed, that changes how the team understands the problem. "People abandon the form at step four" is an observation. "People abandon at step four because it asks for a document they were never told to bring" is closer to an insight. The word is heavily overused for anything mildly interesting, and there is no industry-wide test that separates the two cleanly.

An opportunity is a restatement of an insight as a place where design could act, usually phrased as a question, such as how the service might tell people what to bring before they begin. Keeping opportunities distinct from solutions preserves the space to explore more than one answer. A pain point is a specific point of friction, effort or distress in someone's experience. The term is fine, though it flattens a wide range of severity: a mildly annoying form field and a person losing income while a decision is delayed are not the same category of problem, and a map that marks both with the same red dot is telling you very little.

Terms about delivery reality in GDS UK (Public Sector)

Alpha is a delivery phase, used most consistently in public sector service delivery, in which a team builds and tests the riskiest parts of an idea quickly in order to learn whether an approach can work at all. The work is deliberately rough: prototypes rather than production systems, tested with real users, with the expectation that some of it will be abandoned. The misuse is running an alpha as an early build of a decision already made, which produces reassurance rather than learning.

Beta follows, and is where a working version of the service is built properly and released to real users, usually to a limited group first and then publicly, while the team keeps improving it. The distinction that matters is that a beta carries real consequences for the people using it, so the standard of care changes even though the work is still unfinished. In commercial settings the word travels badly and often means little more than a release nobody wants to be held to.

These phase words are worth handling carefully outside the context that defined them. A team can be in beta on a digital product while the surrounding service, its letters, its phone lines and its exception handling, has never been designed at all. The phase describes where the build has reached, not how much of the service is covered by it, and mistaking one for the other is how a launched service still fails at the parts nobody scoped.

How to use the vocabulary without turning it into jargon

The real risk with a glossary is not that people misuse the words. It is that a team starts speaking a private language that sounds precise and excludes everyone whose agreement the work depends on. A service manager who has run an operation for a decade will not be persuaded by a sentence containing three of these terms, and will reasonably conclude that the designer is describing something other than the work she recognises.

Use the plain version first, and reach for the term only when it is doing work the plain version cannot. Say "we mapped what has to happen behind the scenes for that letter to go out" before saying blueprint. When a term genuinely earns its place, define it in the room, once, without ceremony.

Vocabulary is useful to the extent that it lets more people think together about the same thing. The moment it starts doing the opposite, put it down.