GOV.UK Figma Design System

CGI delivers public sector services that follow GOV.UK standards for accessibility and consistency. Around 50 designers across CGI worked daily in Figma against those standards, mostly on Ministry of Defence projects.

The most widely used Figma file for GOV.UK was a community contribution by Joe Horton. It was an excellent starting point. It had not kept up with GOV.UK Design System updates, the new GOV.UK colour scale rebranding, or modern Figma features like variables and viewport modes. The result was wasted effort across the CGI MoD portfolio. Designers rebuilt the same components, design reviews surfaced the same inconsistencies, and engineering received Figma files that drifted from GOV.UK Frontend.

The business goal was straightforward. Reduce wasted design effort. Improve consistency in design reviews. Prepare the design layer for engineering consumption to shorten the design-to-frontend handoff. The work needed to ship without protected time, without mandate, and against a moving target, because GOV.UK itself updates faster than any single Figma file tends to.

The lack of a maintained system created friction across teams. I observed the pattern across 8 design reviews over 6 months.

Designers rebuilt standard components from scratch. Buttons, form inputs, summary cards, and navigation patterns were re-created on every project. Legacy components in the existing Figma file did not match current GOV.UK standards, so designers either fixed them locally or replaced them entirely. The legacy file was less reliable than building from scratch, which meant designers stopped trusting it.

Static pages took 2 to 3 days to complete. Most of that time went to component recreation rather than design thinking, problem framing, or stakeholder review.

Outdated components reached production. Without a clear source of truth, drift between Figma and GOV.UK Frontend caused inconsistencies that surfaced late in delivery, when fixes are most expensive.

Design reviews flagged the same issues repeatedly. Spacing, type scale, colour usage, and accessibility states. The same conversations, on different projects, with different designers, week after week.

Community demand reinforced the picture. Designers across the wider public sector design community repeatedly requested updated versions of the GOV.UK Figma file. No one owned the next update. The Joe Horton file had been published as a single contribution, and the GOV.UK organisation itself had no central ownership of a Figma equivalent to GOV.UK Frontend. This was not a tooling gap. The tools existed. It was a system ownership and scalability problem.

I owned the work end-to-end as the sole designer and system owner. I drove the audit of the existing file, the system architecture decisions, the rebuild of 80% of components using Figma variables and viewport modes, the token preparation for engineering consumption, the validation with 5 designers across 3 teams, and the publication and adoption inside CGI. There was no supporting team and no formal mandate.

The constraints shaped every decision. I had 2 weeks of effort, part-time, alongside billable client commitments, with no protected time. The GOV.UK Design System evolves faster than design tooling, so the Figma layer would drift again without ownership. There was no central ownership of the GOV.UK Figma file inside CGI or across government, which meant adoption needed to happen organically. Without mandate, designers had to choose to adopt the system over their existing files.

Audit and gap analysis

I audited the existing Joe Horton Figma file against the latest GOV.UK Design System, including the new GOV.UK colour scale rebranding. I chose this as the starting point because the file was the de facto standard inside CGI, and a clean rebuild with no reference to existing usage patterns would have made adoption harder.

The audit surfaced four gaps. Components introduced in recent GOV.UK updates were missing entirely. Existing styles were tied to the previous colour palette, predating the rebranding. The file had no structure for scaling, theming, or reuse. Different teams used different forks of the file, creating high duplication. This explained the symptom. Designers rebuilt components because the existing file was less reliable than starting from scratch.

System redesign

I built the system around a 3-layer token model. The primitive layer holds raw values tied to the new GOV.UK colour scale, from 50 to 950. Type primitives, spacing primitives, radius primitives. No semantic meaning, no component coupling. The semantic layer holds purpose-driven aliases. Surface, foreground, border, action, focus, error, success. Each semantic token resolves to a primitive and switches cleanly between light and dark modes.

The component layer pulls from semantic tokens, never from primitives directly. This protects the system from breaking when primitives change. I architected the token export to JSON in preparation for Style Dictionary consumption by engineering. The pipeline was set up but not yet consumed by frontend teams. The architecture supports it the day ownership is in place.

Decision 1: 3-layer token architecture instead of flat styles

The legacy file used flat colour and type styles tied to specific values. Theming was impossible. Maintenance scaled poorly with each GOV.UK update. I moved to a 3-layer token model with primitives tied to the new GOV.UK colour scale and semantic tokens that resolve cleanly across light and dark themes.

The 2-week timeline forced a single rebuild. I needed an architecture that would not require another rebuild on the next GOV.UK update. Tokens absorb change at the primitive layer without breaking components.

The rejected alternative was to keep flat styles and update values. That would have shipped in days rather than weeks. The cost would have been a third rebuild within 12 months, once the next GOV.UK update landed.

Decision 2: Viewport variables instead of device-specific component variants

The legacy file maintained separate mobile and desktop component variants. This doubled component count, doubled maintenance, and let the two viewports drift apart over time. I removed device-specific variants and used Figma's viewport modes with variables to switch type scale and spacing at 3 breakpoints.

One component, one source of truth. Designers stop choosing between mobile and desktop versions. The system reflects how the frontend actually behaves.

The rejected alternative was to keep device-specific variants. The trade-off was learning curve. The old model was simpler at first contact, and teams needed a 10-minute walkthrough on the new model. Worth it.

Decision 3: Rebuild 80% of components instead of patching

The legacy file had structural issues. Flat styles, duplicated variants, inconsistent naming, missing components. Patching would preserve the technical debt that caused the original rebuild need. I rebuilt 80% of components from scratch on the new token foundation and kept the 20% that were structurally sound.

A patched system would inherit the same drift problem within months. The token-led rebuild gave the system a foundation that absorbs GOV.UK updates without another full rebuild. The rejected alternative was incremental patching over 3 to 6 months. Patching would have meant a third full rebuild inside the following 12 months. The upfront cost of rebuilding paid for itself within one update cycle.

Decision 4: Architect for engineering consumption, ship without engineering pipeline

GOV.UK Frontend already exists as a code library. Designers and engineers worked from separate sources of truth, and handoff drift was a recurring review issue. I structured the tokens as JSON-exportable Style Dictionary input and set up the export. I did not block on engineering adoption.

I had no authority to mandate engineering changes. I had control over Figma. I made the design layer ready for the engineering integration the day someone owns it. The rejected alternative was to wait until engineering committed to consuming the tokens. That would have meant the work never shipped at all. The trade-off is that the pipeline is not yet active. The architecture is ready when ownership lands.

The shipped system maps directly to the problems surfaced in the audit.

Components mapped to the latest GOV.UK Design System standards replaced the missing and outdated set. Buttons, form inputs, summary cards, navigation, error states, and accessibility patterns. The 3-layer token architecture, tied to the new GOV.UK colour scale from 50 to 950, replaced the flat-style maintenance problem. The semantic layer added light and dark theme support from a single source. Viewport-based responsive typography at 3 breakpoints replaced the device-specific variant duplication. The token export structure, ready for Style Dictionary consumption by frontend teams, prepares the system to close the design-to-engineering handoff. Contribution guidelines documented in-file address the discoverability and reuse gap, with each component page explaining structure, intended use, and how to extend.

Designers start from production-aligned components instead of rebuilding UI.

The strongest signal is adoption without mandate. 5 Ministry of Defence projects adopted the system within weeks of publication. 50 active weekly designers across CGI public sector teams use it. The Figma Community publication reached 500+ usages in the first months.

On efficiency, static page design time dropped from 2 to 3 days to 1 to 2 days, based on team feedback and observation across 8 design reviews. Across the adopting teams, this is an estimated saving of 1 week of design effort per designer per project, roughly £5k per designer per project at typical CGI day rates. Applied across 50 designers and 5 MoD projects, the cost avoidance is in the six-figure range, though I report this conservatively because I did not run formal time-tracking instrumentation. Variant count reduction also produced a smaller file size, which improved load and share times for adopting teams.

On quality, design reviews on adopting projects flagged fewer inconsistencies. The system stays tighter to the latest GOV.UK Design System and colour scale than the legacy file ever did. The token architecture supports light and dark themes from a single source.

On scalability, the 3-layer token model absorbs GOV.UK updates at the primitive layer without breaking components. Viewport variables remove the mobile and desktop variant drift problem. The token export is prepared for engineering pipeline consumption when ownership is in place.

The strongest result was not the system. It was the adoption pattern. I delivered a 3-layer token architecture, viewport responsive typography, and an 80% component rebuild in 2 weeks of part-time effort. Adoption happened without mandate, across 5 Ministry of Defence projects, because the system was credibly better than the alternative and access was free through Figma Community.

The weakness was governance. GOV.UK has no central ownership of the Figma layer. CGI has no central ownership of the system either. I documented contribution guidelines inside the Figma file, but documentation is not governance. The system runs, but no one owns the next update.

If I extended this further, I would define and propose a contribution model through CGI's design leadership, with named owners per component group. I would activate the Style Dictionary pipeline with frontend teams on at least one MoD project, closing the design-to-engineering loop in production rather than in architecture. I would track adoption and rework metrics formally rather than through observation, so the next iteration has defensible quantitative data. I would run monthly reviews with the 50 active designers to surface gaps before they become drift.

The deeper lesson is that design systems fail at governance, not at design. Building the system in 2 weeks was the easier part. Owning it for the next 2 years is the harder problem, and one I would solve next time by securing ownership before publishing.