Service Patterns: From GOV.UK to Holliday

The previous post examined Brad Frost's Atomic Design - a hierarchical approach to composing user interfaces from atoms through to pages - and the post before that explored Wilkinson's Grammar of Graphics as a formal system for generating visualisations. Service design has its own attempts at reusable structure, though they have emerged from practice rather than from first principles, and their relationship to the kind of formal grammar explored elsewhere in this series remains uncertain.

The concept of a design pattern - a reusable solution to a recurring problem in a given context - has a long lineage. Alexander et al. (1977) proposed that architecture could be understood through patterns: generic, context-sensitive solutions that could be instantiated and combined to produce coherent wholes. The idea was subsequently adopted in software engineering, where Gamma et al. (1995) codified patterns for object-oriented design, and has informed interaction design, where patterns describe recurring solutions to interface problems (Jackson, 2021). Ehn (2008) identifies the development of design patterns as an infrastructuring strategy in participatory design - a way of encoding design knowledge so that it can travel across contexts without losing its essential structure. In service design, however, the pattern concept has taken a somewhat different form; rather than emerging from theoretical reflection on the nature of services or from formal analysis of what services share, patterns have emerged inductively from the observation that many services, particularly in government, follow similar structures and could benefit from shared solutions.

The GOV.UK Origins

The closest thing service design has to systematic patterns emerged from the UK Government Digital Service. GDS was established in 2011 to transform how government delivers digital services, and over the following decade it developed not just individual services but shared infrastructure: the GOV.UK Design System, GOV.UK Notify, GOV.UK Pay, and patterns for common service types (Government Digital Service, n.d.). The patterns emerged inductively; GDS teams noticed that many government services could be categorised by what they helped users do - checking something (such as driving licence status or State Pension age), booking something (a driving test, a prison visit), applying for something (a passport, Universal Credit), reporting something (a change of circumstances, a crime), or paying for something (vehicle tax, a court fine). These are not formal definitions so much as pragmatic categories, but they capture something real: many government services are variations on a small number of underlying interaction types, and recognising this permits the development of shared components rather than bespoke solutions for each.

Pattern Recognition in Practice

Holliday (2022) describes how this pattern thinking was applied beyond central government. At Essex County Council, TPXimpact identified seven core types of patterns across a range of services that had been built independently using different technology solutions for what were, at root, similar user interactions. The value was practical: recognising patterns enabled consolidation of similar services around shared components, consistency of experience for users encountering familiar interaction types across different services, faster development of new services using existing patterns, and iterative refinement based on collective learning rather than isolated experience. The logic extends Atomic Design's core proposition - that building from reusable, well-understood units is more sustainable than building from scratch - to the level of service interactions rather than interface elements.

Tarling (2023) develops the concept further by distinguishing patterns from other reusable elements at different levels of abstraction. In her framework, patterns are recurring steps or interactions that describe what users are trying to do; components are technical building blocks that provide capability, such as a notification service or payment gateway; and platforms are shared infrastructure that enables components to work across services, such as GOV.UK Pay or GOV.UK Notify. The levels are conceptual, technical, and infrastructural respectively, such that a "book something" pattern might be implemented using a scheduling component built on a calendar platform. The distinction matters because it clarifies that pattern recognition alone is insufficient; patterns must be connected to the technical and infrastructural decisions that enable their consistent implementation at scale.

The Platform Perspective

[Section added May 2025.] Pope (2024), in Platformland, takes this analysis further by arguing that patterns are not merely design concepts but architectural decisions with infrastructure implications. When a common interaction type like "pay for something" is recognised as a pattern, it becomes possible to build shared infrastructure that implements the pattern once, well, and makes it available across services. Pope's framing of Government as a Platform envisions a common core of shared digital systems, technology, and processes on which it becomes easier to build joined-up services; the building blocks include common components for payment, notification, identity verification, and forms, shared data through registers and APIs, and design infrastructure in the form of the design system, service standards, and assessment frameworks.

In the terms of the earlier post on Promise Theory, a payment platform is a provider that promises reliable payment processing; services that need payment can rely on that promise rather than implementing payment themselves, and the promise relationship replaces the need for each service to solve the same problem independently.

What Patterns Reveal and What They Lack

Looking across these perspectives, service patterns are reusable solutions to recurring design problems. A "check something" pattern embodies collective experience about how users look up information, what they need to see, what errors commonly occur, and how edge cases should be handled. Implicitly, these patterns also encode decisions about what entities and objects the pattern operates on, which is why, as Objects, Entities, and Things establishes, the same pattern can appear quite different depending on what is taken to be the fundamental unit of concern. Secomandi and Snelders (2011) argue that the object of service design has been inadequately theorised; the material and evidential dimensions of services - what Shostack (1984) attempted to capture through the technique of service blueprinting - remain underdeveloped relative to the experiential and relational dimensions that dominate the field's attention. Patterns as currently conceived inherit this limitation; they capture interaction types but say little about the material conditions, evidence structures, or state transitions that govern how those interactions actually function.

The patterns are not, however, a grammar. Unlike Wilkinson's Grammar of Graphics, there is no formal syntax that would allow patterns to be composed according to rules and the result validated for completeness or consistency. Unlike Frost's Atomic Design, there is no clear hierarchical progression from elementary units to complete services - whether "check something" should be understood as analogous to a molecule, an organism, or a template is never specified. The question of how patterns compose - whether and under what conditions a service can combine checking and applying, and in what order, and with what dependencies between them - is answered in practice (applying for a passport involves checking eligibility, providing information, paying, and booking an appointment) but not by any specification that would make the composition explicit. Vink (2019) observes that the service design literature has placed a strong emphasis on practice, methods, and tools at the expense of foundational theoretical frameworks; the pattern work is, in this sense, characteristic of the field's tendency to codify what practitioners do rather than to develop the theoretical apparatus that might explain why particular compositions succeed and others do not.

Several specific absences are worth noting. The patterns lack state specification: they describe user activities - checking, booking, applying - but not the states that precede and follow those activities, the conditions that trigger transitions between them, or the dependencies between concurrent processes. The journey map tradition addresses transitions implicitly, but patterns do not inherit that vocabulary. The patterns also lack promise structure: they describe what users do but not what providers commit to in return. A "book something" pattern specifies that users will select a time and confirm, but not what the provider promises by way of outcomes, experiences, performances, or affordances - the dimensions that Iqbal's (2018) 16x frame would insist upon. And there is no formal validation; there is no specification against which a service implementation can be checked, and quality depends on assessment and professional judgement rather than on any form of syntactic or structural validity.

Toward Richer Patterns

Developing patterns toward something more like a grammar would require several additions: state semantics that define what states users and services occupy before and after each pattern, specifying transitions and triggering events and connecting patterns through state changes; promise structure that identifies, for each pattern, which commitments are relevant and makes them explicit; compositional rules that define how patterns can legitimately combine and how compositions can be validated for completeness; and formal specification that expresses patterns in a notation capable of supporting simulation and testing. This would move patterns from templates toward grammar - from descriptions of good examples toward specifications of what a given interaction type requires.

The landscape as it stands offers useful categories but not formal types; quality principles (Downe, 2020) but not structural rules; architectural levels distinguishing patterns from components from platforms (Tarling, 2023) but not compositional grammar; practical methodology for pattern reuse (Holliday, 2022) but not formal specification. The next post attempts a synthesis: what would a grammar of services look like, drawing on Wilkinson, Frost, Iqbal, and the pattern work explored here?

Next: "Toward a Grammar of Services" - synthesising the threads into a proposal for what rigorous service specification might look like.

References

Alexander, C. et al. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press.

Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.

Ehn, P. (2008). Participation in Design Things. Proceedings of the Tenth Anniversary Conference on Participatory Design, Indiana University, 92-101.

Gamma, E. et al. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Government Digital Service. (n.d.). GOV.UK Design System. https://design-system.service.gov.uk/

Government Digital Service. (n.d.). Service Manual. https://www.gov.uk/service-manual

Holliday, B. (2022). Multiplied: How Technology, Collaboration and Participation Can Transform Services. TPXimpact.

Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.

Jackson, D. (2021). The Essence of Software: Why Concepts Matter for Great Design. Princeton University Press.

Pope, R. (2024). Platformland: An Anatomy of Next-Generation Public Services. Ash Center, Harvard Kennedy School.

Secomandi, F. and Snelders, D. (2011). The Object of Service Design. Design Issues, 27(3), 20-34.

Shostack, G.L. (1984). Designing Services That Deliver. Harvard Business Review, 62(1), 133-139.

Tarling, K. (2023). The Service Organization. Rosenfeld Media.

Vink, J. (2019). In/visible: Conceptualizing Service Ecosystem Design. PhD thesis, Karlstad University.