The Question That Reframes Everything
A few months into building components for the design system, I keep returning to a question that predates the code: what are these components actually for? Components are for building interfaces, but interfaces serve tasks, tasks serve journeys, and journeys serve goals. If we do not understand the higher levels, we risk building components that do not add up to anything coherent.
This is why, before any of the development work began, the design systems working group spent time on service patterns - not UI patterns, but the repeatable structures of work that users perform across multiple products. The hierarchy of action I explored earlier provides the theoretical basis; this post attempts to apply it practically to the platform context.
What Are Service Patterns?
In public sector design, service patterns are reusable models for common activities that occur across many services. They are more than UI components; they are practical guidelines for end-to-end journeys that deliver user needs, composed of multiple steps. The Government Digital Service has been developing this thinking since around 2016, and by 2018 had articulated ten principles for service patterns (GDS, 2018), framing them as ways to standardise repeated services like "getting a licence" or "renewing a passport" across government.
Lou Downe pushed this further in Good Services (Downe, 2020). Their argument was that public service design had spent decades defining how to design services - methodologies, canvases, journey maps - without ever clearly defining what a good service actually is. Their fifteen principles provide that missing vocabulary: services should enable users to complete their goal, be easy to find, set expectations clearly, and so on. But at their simplest, as GDS put it, service patterns are common user tasks and common stages of a service.
Kate Tarling, in their work on types and stages of services (Tarling, 2017), identified common stages - discovery, routing, eligibility, suitability, issuing - that apply as abstractions across many services, whether applying for a driving licence or a benefits payment. The Ministry of Justice has been one of the leaders in putting this into practice, identifying around 25 potential service patterns by 2023 - things like "apply for something", "book an appointment", "get a decision". A cross-government working group including MOJ, DWP, and Defra has since been developing shared patterns that could work across departments (Ford-Downes, Stephens and Thomas, 2025). FutureGov developed a complementary taxonomy for local government (FutureGov, 2020) that distinguishes between high-level service patterns, building blocks such as "fill in something" or "pay for something", and micro-interactions such as "get a notification".
The Hierarchy Problem
All of this points to a hierarchy that needs to be made explicit. "Patterns" exist at multiple levels of abstraction, and conflating them produces incoherent design systems. As I explored in the earlier post on the hierarchy of action, Leontiev's (1978) activity theory distinguishes activities oriented to motives, actions oriented to goals, and operations oriented to conditions; Burns and Hajdukiewicz's (2017) abstraction hierarchy decomposes work domains from functional purposes down to physical forms. These frameworks explain why "ensure safe patient flow" and "click the filter dropdown" are not the same kind of pattern - and why a design system that treats them as commensurable will produce confusion rather than coherence.
Working through this for platform products in a healthcare data context, the hierarchy maps from the most abstract to the most concrete across six levels. At the top, policy patterns set the intent: referral-to-treatment standards, cancer pathway targets, elective recovery goals. Below that, platform patterns describe the shared data infrastructure that multiple products draw on - the data layer, the application framework, the integration services. Service patterns sit at the level of individual products with their own outcomes: "validate a waiting list", "book an outpatient appointment", "transfer a patient to another provider".
Transaction patterns are more abstract than services but more concrete than policies: "discover and prioritise", "cohort", "validate", "route for review", "delegate", "approve", "track outcomes". These are the fundamental task stages that compose larger service journeys. Capability patterns are self-contained modules that solve specific recurring tasks and can be composed into multiple journeys; GOV.UK Notify is the canonical example, and a task inbox might be another. At the bottom sit the interaction patterns where traditional design systems live: page structures, operative workflows, data tables, input groups, buttons, tokens.
Most design system work focuses on the bottom two or three levels. But if we do not understand the levels above, we are building components without knowing what services they need to support - or what promises they need to keep.
Lists All the Way Down
Working through this hierarchy for the platform's products revealed something that Pope (2024) captures precisely: "governments run on lists. An authoritative list required for operating a modern state is termed 'foundational data'. Foundational data creates expectations, rights and responsibilities".
The clinic and room management tool manages lists of clinics, rooms, and their capacities. Several waiting-list products - spanning cancer pathways, elective care, and referral-to-treatment validation - all manage lists of patients waiting for treatment. A patient transfer tool manages lists of patients to be moved or shared between providers. Bed management and patient flow dashboards manage lists of patients and beds, tracking who is waiting to be discharged. A theatre management tool manages lists of theatres and their surgical capacity. A clinical notes review tool manages lists of notes from discharged patients. A system-wide operational dashboard aggregates lists of pressures across providers and integrated care boards.
Almost every product on the platform is fundamentally a list management product. Users are analysing lists, filtering lists, acting upon list items, and tracking list items through workflows. This reframes what the design system needs to support: not generic components assembled ad hoc, but patterns specifically designed for displaying and filtering lists of varying sizes, comparing items across lists, taking actions on items individually and in bulk, tracking items through workflow states, and visualising list data as distributions, trends, and outliers.
Vertical Integration
The Ministry of Justice's approach to service patterns includes a description defining scope and purpose, examples of existing implementations, relevant user research findings, links to reusable design artefacts, considerations for happy and unhappy paths, and recommendations for components (Ford-Downes, Stephens and Thomas, 2025). The last element is the crucial one: service patterns should link down to UI patterns. The service pattern for "apply for something" should reference the specific components and interaction patterns that implement it well.
Working the other direction, UI patterns should link up to service patterns. A filtered data table component is not just a generic table; it is a building block for "discover and prioritise" and "cohort" transaction patterns, which in turn support "validate a waiting list" as a service pattern. Without this vertical integration - without understanding how the hierarchy of action connects the levels - service designers create journey maps that cannot be implemented, UI designers create components that do not serve real workflows, and developers build features that do not connect to user goals.
The product/service distinction matters here in a specific way. Each product on the platform has its own team, its own roadmap, its own delivery cadence. But the service patterns - "validate a waiting list", "manage patient flow through a ward" - cut across products. A patient's journey from referral through to treatment may touch three or four products, none of which was designed with awareness of how the others work. The only thing they share is that they happen to use the same underlying toolkit; that is not design coherence but accident.
Implications for the Design System
If we thought in terms of service patterns across the platform - mapping all the different lists users are managing, the tasks they are trying to fulfil, the common stages of their workflows - we could begin to identify where shared patterns would add genuine value. The design system cannot just be a component library; it needs to be infrastructure that supports coherent service delivery.
At the bottom of the hierarchy, we are building tokens, atoms, molecules, organisms. That work is progressing. But we also need to build upward: templates that embody common page structures for list management; capability patterns like task inboxes that can be composed into multiple products; and documentation that explicitly links UI patterns to the service patterns they support. And we need governance that thinks at the service pattern level, not just the component level. When a new product is commissioned, the question should not just be "what components do you need?" but "what service patterns does this implement, and how do they connect to existing products?". That governance does not exist yet; but the design system - and particularly the signal model and accountability framework developed earlier in this series - could help create the vocabulary for it.
References
Burns, C. M. and Hajdukiewicz, J. R. (2017). Ecological Interface Design. CRC Press.
Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.
Ford-Downes, M., Stephens, L. and Thomas, G. (2025). Developing service patterns: reusable designs for building government services. Services in Government Blog. https://services.blog.gov.uk/2025/03/19/developing-service-patterns-reusable-designs-for-building-government-services/
FutureGov (2020). LocalGov Patterns: Service Patterns for Local Government. https://patterns.wearefuturegov.com/
GDS (2018). 10 principles for service patterns. Design in Government Blog. https://designnotes.blog.gov.uk/2018/05/17/10-principles-for-service-patterns/
Leontiev, A. N. (1978). Activity, Consciousness, and Personality. Prentice-Hall.
Pope, R. (2024). Platformland: An Anatomy of Next-Generation Public Services. London Publishing Partnership.
Tarling, K. (2017). Types and stages of services. Home Office Digital Blog. https://hodigital.blog.gov.uk/2017/07/31/types-and-stages-of-services/