Design Systems in the Public Sector

Government websites face a unique set of challenges. They must serve every citizen, regardless of technical skill or device, while meeting strict accessibility and security standards. For a design systems advocate like Amy Hupe, these constraints create an interesting contrast with commercial work.

In a recent conversation, Hupe discussed how government design systems differ from those built in the private sector. The key difference isn't the code—it's the context. Government services are not optional. A citizen filing taxes or renewing a passport cannot simply switch to a competitor if the experience is poor. This places a heavier burden on usability and clarity than in the consumer space, where users often abandon a product for a better one.

Hupe emphasizes that a government design system must prioritize participation and inclusivity over conversion metrics. Success is measured by whether citizens can actually complete their tasks, not by engagement time or click-through rates. This principle shapes everything from component design to content guidelines.

Documentation as a Deliberate Act

One of the recurring themes in Hupe's work is how teams document their systems. Too often, documentation is an afterthought—written once, rarely updated, and focused on what the team already knows. Hupe argues that documentation should be treated as a product in itself, with a clear audience and goals.

The best documentation answers a specific question for a specific person at a specific moment. It doesn't just describe a button or a form field; it explains when to use the component, what patterns it supports, and how it integrates with the wider service. This is especially important in government, where contributors are spread across departments or agencies still managed by separate teams.

Another core lesson relates to change management. A design system is a long-lived piece of infrastructure, but teams that maintain it may change regularly. Clear governance and contribution models prevent the system from becoming a stale artifact owned by no one. Hupe highlights the importance of making contribution as easy as possible—not just for specialists, but for newcomers who may be unfamiliar with the system's history.

Building Beyond a Single Team

In the UK Government's case, the design system supports hundreds of services delivered by many different organizations with wildly different budgets and capabilities. A centralized team cannot realistically understand the context of every service. Therefore, the system must provide patterns and principles rather than rigid templates.

Hupe's guidance for anyone building a design system echoes this modular approach. Create the structural conditions so that components can evolve as the product, team, and surrounding considerations change. For government specifically, this relies on shared values and a transparent decision process that users can trust.

Listeners looking for concrete examples can explore the resources cited in the episode:

Other Reading This Week

The show also highlighted several fresh articles on Smashing Magazine. For CSS practitioners, Rachel Andrew covers how to establish a grid container in the context of the CSS Grid layout model. Vitaly Friedman has published an updated front-end performance checklist for 2020, worth reviewing before your next optimization sprint. Bruce Lawson weighs in on the semantics of the HTML5 article and section elements and why you'd choose one over the other. Finally, Frederick O'Brien looks at the "split personality" of brutalist web development, while Shubham walks through building and deploying an Angular Material application to Netlify. These pieces provide practical context for teams working on everything from layout aesthetics to deployment pipelines.

A Design System Built in the Open

Amy Hupe spent three years at the UK Government Digital Service (GDS) as Senior Content Designer, leading content strategy for the GOV.UK design system. Her route there was indirect—she joined expecting to write guidance, but was placed in a small team tasked with organizing patterns and tools that were scattered across various resources. She arrived knowing little about code or web design; her background was in editorial content at consumer advocacy group Which?. That steep learning curve shaped how she approached the system's documentation and community.

The GOV.UK design system is broader than its public website. The documentation site holds guidelines, components, patterns, and code examples, but the system also includes the prototype kit (a tool for building high-fidelity HTML and CSS prototypes) and GOV.UK Frontend, the framework used to build services. Hupe defines the system more holistically: it also encompasses the processes that let people discover it, contribute to it, and adopt it across government.

Scale, Openness, and a Broad Audience

Working on a design system for government differs from enterprise work in scale and atmosphere. The audience spans 25 ministerial departments plus numerous agencies and local bodies. Unlike commercial settings, nothing is kept under wraps—everything runs as an open source project. Hupe admitted that seeing GOV.UK guidance and code appear in other countries' design systems took some getting used to. The New Zealand government adopted much of the layout guidance and code; the Dutch government used it as a proof of concept; Australia adapted the contribution guidelines and fed findings back.

That global adoption made the team cautious about releasing work prematurely, but Hupe stressed that the primary duty remains to UK government. It is impractical to design for every external adopter; teams elsewhere must adapt the system for their own contexts.

The range of users was her biggest surprise. She had imagined a typical audience of front-end developers with deep technical knowledge. In reality, content designers and others with varied skill levels became key users, and the team had to serve needs as different as a product manager wanting an evidence-backed number of services using a pattern, and a researcher needing to understand whether a pattern fits a specific context. Documentation had to be well signposted so people could skip irrelevant sections and find what mattered to them.

Persuasion Over Mandates

Government departments are not strictly required to adopt the design system. The Government Service Standard—which services above a certain user count must meet to secure funding—mentions reusing patterns and components, but enforcement is loose and depends on assessors. The approach was therefore collaborative: build advocacy, not mandates.

Contribution became a key tactic. The team began courting potential contributors well before the system launched publicly. A service designer named Ignatia identified conflicting patterns across government—for example, 10 different ways to ask for an address—and ran workshops to consolidate them. Those early relationships meant many people had already contributed before the system went public.

That said, contribution does not scale effort down. Hupe noted that supporting a contributor often takes longer than building something in-house, but the payoff is in advocacy. Contributors became invested and became the system's best salespeople. The team used a working group of representatives from different departments, disciplines, and seniority levels to review contributions monthly against a public set of criteria, which helped democratize decisions. A community backlog on GitHub hosted research and experimental examples, keeping work transparent and giving people influence before anything was published.

Would she repeat the process? Yes, but with more realistic expectations. She had hoped contribution would eventually become hands-off; it never did. The investment is still worthwhile, though, and any new system must tailor its process to its own organization. She starts a new role in 2020 managing the design system DNA at Babylon Health and does not expect to transplant the government process wholesale.

Documentation, Accessibility, and Trust

Hupe referenced a talk by Tatiana Mack about the "multiplication effect" of design systems. Centralized decisions—good or bad—ripple across every service built on them. Accessible defaults multiply accessibility; exclusionary choices proliferate exclusion. A design system is a vehicle, but the intention to be inclusive must come from the teams using it.

On change management, she places herself in a "move more slowly" camp. Releasing minimal components and iterating works well for single products, but a centralized system used by many teams can quickly spin out of control. Releasing unvetted updates destabilizes the system and erodes trust; teams become reluctant to install updates. An assurance process that instills confidence before release helps maintain both quality and goodwill.

She offered concrete advice for documenting a design system. First, aim to be clearer than the moment requires—think about who might join the organization later. Second, test documentation with real users, because subject-matter experts inevitably know too much to judge clarity. When evaluating feedback, separate aesthetic preference from actual usability. People may complain throughout a guide yet still complete a task. Also resist the urge to act on every vocal criticism; ask how many people share the problem and whether there is evidence a change is warranted before chasing the loud minority.

Her final takeaway from the GOV.UK design system is that the visible output—code, design, organization—is what teams focus on, but the real work is with people. Building inclusive processes, fostering safe discussion spaces, and cultivating a sense of ownership are what make a system succeed. "How much of it is really just people work," she said, "and not really anything to do with guidance and code."