What is a Service Pattern Exactly? (And What it is not?)

The first time I introduced the concept of service patterns to a programme team, I was interrupted before I had finished the second sentence. 'So it's like a user story template?' said the business analyst on my left. 'A process map?' said the delivery manager opposite. 'Is this the same as the GOV.UK design system?' said the service designer at the end of the table.

All three were wrong, and all three were wrong in ways that are entirely understandable. Service patterns occupy a conceptual space adjacent to several things practitioners already know, and the temptation to collapse a new concept into a familiar one is strong. That collapse is the source of most confusion about what service patterns can and cannot do.

So here is the definition, before anything else.

A service pattern is a named, reusable structural unit that describes how a specific type of service interaction works, regardless of the domain in which it occurs. It has stages, governance conditions, handoff rules, and exception flows. It exists at the level above the user story and below the operating model. It is the design constraint that any service of that type should follow, and the accumulated institutional knowledge of every time that interaction type has been designed before.

That definition will become more precise as this article progresses. But it is worth holding it from the start, because the lineage of the idea, and the distinctions that separate patterns from adjacent concepts, only make sense once you know what you are trying to define.

Where the idea comes from

The concept of a pattern as a reusable solution to a recurring problem did not originate in government digital services or in business architecture. It was introduced by the architect Christopher Alexander in his 1977 work A Pattern Language, which proposed that the built environment could be described as a set of recurring, named solutions to recurring spatial problems. A courtyard, a window seat, a street cafe: these were not arbitrary design choices. They were patterns, each with a name, a context, a problem it solved, and a solution structure.

The software industry formalised the idea in 1994, when Gamma, Helm, Johnson, and Vlissides published Design Patterns, introducing 23 reusable object-oriented design patterns. The template they established has endured: each pattern has a name, an intent, the context in which it applies, the problem it solves, and the consequences of applying it.

The Government Digital Service began applying pattern thinking to public services around 2014, with the publication of patterns for common service interactions: registering for something, checking your answers, confirming a submission. These were interface patterns, consistent and reusable design solutions for the user-facing elements of digital services.

The cross-government service patterns published by MOJ, DWP and Defra in 2025 extended this thinking to the structural level: not just how a page should look, but how an entire service interaction should work. Apply, Get a Decision, Pay, Book. These are not interface patterns. They describe the structural logic of a repeatable interaction, not its visual presentation. That shift from interface to structure is the step this series is building on.

A definition, unpacked

Returning to the definition: a service pattern is a named, reusable structural unit describing how a specific type of service interaction works, regardless of domain.

Named means the pattern has a stable, agreed label. Capture and Triage. Apply and Submit. Get a Decision. The name is not decorative. It is the shared vocabulary that allows people across different teams and different programmes to discuss the same structural concept without re-describing it from scratch each time. In organisations without this vocabulary, the same interaction type gets reinvented repeatedly under different names by teams who do not know the others exist.

Reusable means the same pattern applies across multiple services and contexts. The interaction in which a citizen reports something to an organisation, the contact is received, validated, classified, and routed, occurs in noise complaints, safeguarding referrals, planning enforcement, and benefits fraud reporting. The domain differs. The structural logic is identical. One pattern, multiple applications.

Structural means the pattern describes the logic of the interaction, not its surface presentation. It specifies the stages the interaction moves through, the conditions that govern each transition, the handoff rules between stages, and the exception flows that handle non-standard cases. It does not specify what a form looks like, what language a notification uses, or what system stores the data.

Regardless of domain is the most important phrase in the definition. A service pattern is not a description of how a particular organisation handles a particular type of interaction. It is a description of how that interaction type should be structured wherever it occurs. The pattern for receiving and triaging an inbound contact applies in a local authority, in a central government department, in an NHS trust, and in a regulatory body. The specifics of implementation will differ. The structural logic should not.

What a service pattern is not

Confusion about service patterns almost always takes one of four forms. Each is worth addressing directly.

It is not a user story. A user story describes a specific requirement from the perspective of a specific user: as a benefits claimant, I want to submit supporting evidence digitally so that I do not need to attend an office. A service pattern operates at the structural level above user stories. It defines the interaction type within which many individual user stories sit. The pattern is the container; the user stories are the contents. Designing a pattern is not a substitute for writing user stories. It is the work that tells you which user stories you need.

It is not a process map. A process map describes the specific sequence of activities, decisions, and handoffs in a particular service, as it is currently or intended to be designed. A service pattern describes the structural logic that should govern any service of that type, regardless of the specific sequence of activities a given team chooses to implement. The process map is the implementation. The pattern is the design constraint against which the implementation is validated.

It is not a design system component. The GOV.UK design system provides reusable interface components: buttons, form fields, error messages, task lists. These operate at the level of the user interface. A service pattern operates two levels above this: it describes what stages an interaction passes through and how those stages connect, not how any individual stage looks on screen. A service pattern might govern a journey that uses twenty different design system components. The pattern is not one of them.

It is not a service blueprint. A service blueprint maps the full cross-section of a service: the user journey, the front-stage actions, the back-stage processes, the supporting systems. It is a documentation tool for a specific service as it exists. A service pattern is a design standard for the structural logic that any service of that type should follow. A service blueprint might reveal that a service deviates from its governing pattern. The pattern is what the blueprint is assessed against, not a version of the blueprint itself.

The level at which patterns live

One way to locate service patterns is to think in terms of architectural levels, from strategy down to interface.

At the top is the organisational strategy: what the organisation is trying to achieve and why. A government department commits to reducing the time taken to process a benefit claim. Below that is the operating model: how the organisation is structured to deliver against that strategy. The department creates a case management function with defined roles and accountabilities. Below that is the service architecture: the structural logic of the services the operating model delivers. This is where service patterns live. A claim is received via a Capture and Triage pattern, assessed via a Check and Assess pattern, and decided via a Get a Decision pattern. Below the service architecture is the process design: the specific activities within each service. Below that is the system design: the technology supporting those activities. At the bottom is the interface design: what the citizen actually sees.

Service patterns live at the service architecture level. Above user stories, process maps, and interface components. Below operating model decisions about structure and accountability. This is a level that most organisations have never explicitly addressed, which is part of why services designed by different teams, at different times, for different purposes, end up looking like they came from different organisations.

A caution about overhead

Practitioners who manage delivery programmes sometimes push back at this point. Does introducing service patterns add another layer of governance? Another review gate before a team can get on with the work?

The honest answer is: it can, if patterns are applied badly. A pattern library that functions as a compliance checklist, where teams must seek approval before deviating from a pattern, will slow delivery and generate the same resentment that any heavy-handed architecture function generates.

Applied well, patterns do the opposite. They reduce the number of decisions a team has to make from scratch, because the structural decisions have already been made. They reduce the number of review cycles, because a service built to a known pattern is easier to assure than one built from undocumented first principles. The overhead is in establishing the patterns. The return is in everything that follows.

Precision as a design tool

There is a reason this article spends time on definitions before moving to application. Imprecise vocabulary produces imprecise design. When a team thinks a service pattern is a user story template, they write user story templates and call them patterns. When they think it is a process map, they draw process maps and call them patterns. Neither of these is the structural work that patterns are designed to do, and neither produces the consistency and reuse that a real pattern library makes possible.

The next article in this series takes the vocabulary established here and puts it in direct conversation with service design, the methodology most practitioners in this space already know. That conversation reveals something counterintuitive: the two approaches are not alternatives. But understanding why requires being precise about what service patterns are, and precise about what service design is. The distinction, when you see it clearly, changes how you use both.