More than a component library
The previous post argued that service patterns - the repeatable structures of work that users perform across multiple products - need to be understood before the components that implement them can be designed coherently. This post extends that argument upward: the design system is not just a component library but an attempt at platform infrastructure, and the distinction between the two has consequences for governance, ownership, and what the system can actually achieve. A component library is a collection of parts that solves a technical problem (reuse); platform infrastructure solves an organisational one (coherence across services that share users but not teams).
What "Platform" Means
Richard Pope, who was part of the founding team at the UK Government Digital Service, provides the clearest framing. In Platformland (Pope, 2024), he describes "Government as a Platform" as a shift from building bespoke systems for each service to building shared components and data infrastructure that multiple services can use. Common components, Pope argues, "make it simpler and cheaper to build public services, meaning that the teams that are building services can focus on things that are unique to their domains" (Pope, 2024, p. 46).
The UK examples are well established: GOV.UK Notify for sending emails and text messages, GOV.UK Pay for taking payments, GOV.UK Verify for identity verification. Each is a component that any government service can use, maintained centrally, improved collectively. The model emerged from GDS in the early 2010s, built on the insight that many digital services need the same things; building them from scratch for each service is wasteful, building them once and sharing them is efficient. Singla (2019, p. 23) captures the broader ambition, quoting Mike Bracken's original formulation: Government as a Platform is "a common core infrastructure of shared digital systems, technology and processes on which it is easy to create excellent, user-centric government services".
The Platform Reality
The healthcare data platform I work on does not yet have this. Beyond the fact that most products are built using the same vendor-provided application framework, there is little standardisation at an interface or service pattern level. Each product team makes its own decisions about navigation, information architecture, and terminology. Consistency happens by accident - through the vendor framework's defaults - rather than by design, and certainly not in any way informed by testing these products at scale with representative users.
This is the gap the design system could fill: not just providing components, but establishing shared patterns that create coherence across the product portfolio. The hierarchy from policy patterns down to interaction patterns identified in the previous post makes the ambition concrete; a platform-level design system would need to operate at multiple levels of that hierarchy, not just at the bottom.
The Standardisation Tension
One of the recurring themes in the platform literature is the tension between standardisation and local adaptation. Pedersen and Ferlie (2016), writing about healthcare specifically, observe that resolving the tension between local needs and system-wide requirements for interoperability and standardisation may not be fully achievable. In principle, a shared design system spanning dozens of provider organisations with different contexts, workflows, and user populations should encounter this tension at every turn.
In practice, the tension has not manifested - but for the wrong reasons. The vendor's proprietary framework has already constrained everything. Navigation patterns, form interactions, data visualisation approaches - all are bounded by what the framework can do. Products look similar not because of deliberate design coherence but because they are all bumping against the same walls. If these products had been built in an open framework from the start, with genuine design freedom, they might have diverged substantially; the design system becomes more important in that world, not less. It is the thing that creates coherence when platform constraints are removed rather than imposed.
The Governance Gap
Platform components require governance. Pope emphasises this throughout Platformland - someone needs to decide what goes in, how it evolves, who maintains it. Singla's (2019, p. 23) research found the same: "the change to a shared platform culture will call for strong leadership at the government and departmental levels". Governance in the platform context means not just technical decisions about component APIs but accountability structures for who owns the patterns, who decides when they change, and who is responsible when they fail.
The governance question for this platform is complicated by a structural ambiguity: the commissioning organisation sets policy and owns outcomes, but the vendor builds the products and controls the technical decisions. Design governance forums tend to be oriented toward risk management and delivery reporting rather than design quality or service coherence. When ownership itself is ambiguous - when it is unclear whether the commissioning body or the vendor owns the product backlog - effective design governance becomes difficult. The product/service distinction compounds this: each product has its own governance, but the services that cut across products have none.
Building Toward Infrastructure
Platforms require sustained investment, not project funding. Singla's (2019) research found that successful Government as a Platform implementations had committed, long-term resourcing; project-based funding - build it and move on - does not work for infrastructure. The current design system exists in a space between what has been sanctioned and what has been resourced, and that gap shapes what is practically achievable.
Despite the governance gaps and resourcing uncertainty, the platform framing clarifies the ambition: shared components that any product on the platform - and potentially any staff-facing health service - can use, with consistent accessibility, branding, and patterns; a token architecture that enables theming and multi-brand support without fragmenting the component base; and open documentation and open-source publication so that the work can survive beyond any individual's involvement or any single organisational relationship, and so that the decisions behind the patterns are legible to the teams adopting them.
Whether this becomes genuine platform infrastructure depends on factors outside my control. But building with the platform model in mind means building something that could become infrastructure if the conditions allow; and the signal model and accountability framework developed earlier in this series provide the conceptual vocabulary for what that infrastructure would need to promise and deliver.
The Political Dimension
Pope ends Platformland by asking what "the politics" of digital services and infrastructure will be. That question lands differently when the design system sits between a commissioning organisation and a vendor. Building it in the open, publishing it to npm, making it independent of any specific contract - these are design decisions, but they are also political ones. They are statements about where capability should sit: inside the public institution, accessible and transferable, rather than locked within a vendor relationship.
This connects to Mazzucato and Collington's (2023) argument about capability erosion in outsourced public services: the less an organisation does internally, the less able it is to do in the future. A design system built in the open, with documented decisions and transferable patterns, is a small act of capability building - an attempt to ensure that the commissioning organisation retains some understanding of and control over how its services are designed, regardless of how the vendor relationship evolves. The design system cannot, on its own, reshape the operating model; but it creates an option that did not exist before, and what happens with that option is a political question rather than a technical one.
References
Mazzucato, M. and Collington, R. (2023). The Big Con: How the Consulting Industry Weakens Our Businesses, Infantilizes Our Governments, and Warps Our Economies. Allen Lane.
Pedersen, A. R. and Ferlie, E. (2016). Managing healthcare reform. In E. Ferlie and E. Ongaro (eds.), Strategic Management in Public Services Organizations. Routledge.
Pope, R. (2024). Platformland: An Anatomy of Next-Generation Public Services. London Publishing Partnership.
Singla, P. (2019). Government as a Platform (GaaP): A New Model for Public Service Delivery. IGLUS, EPFL.