React GOV.UK Design System

While working at CGI, I supported public sector teams using the GOV.UK Design System.

The system is strong in accessibility and consistency. It works well for standard service journeys. It breaks down when teams build more dynamic, interactive products.

I have worked previously on a Figma Design System and meantioned some issues I have encountered previouly, take a look here.

My goal was to extend the system into a workflow that supports:

• Component-driven development.
• Faster iteration from design to production.
• Richer interaction patterns.

Audience

• Designers working in Figma.
• Frontend engineers building React applications.

The issue was not the design system itself. It was the workflow around it.

Prototype to production gap

The GOV.UK Prototype Kit uses Nunjucks and static templates.

This created friction:

• Manual refresh cycles.
• Page-based templating instead of reusable components.
• No clear path to production React code.

Limited component capability

The system supports basic UI patterns.

It does not support:

• Searchable inputs like comboboxes.
• Rich interactive states.
• Advanced loading patterns such as skeleton screens.

Fragmented tooling

To move from design to production, I had to:

• Reinterpret Figma designs.
• Rebuild components in a different paradigm.
• Cross-reference multiple documentation sources.

This slowed delivery and increased inconsistency.

I owned the project end to end:

• Defined the problem.
• Designed the system.
• Built the component library.
• Set up documentation.

Constraints

• GOV.UK visual and accessibility standards had to remain intact.
• No team support or dedicated time.
• Needed to balance fidelity with flexibility.

This was a side project alongside client work.

Step 1: Fix the design foundation

I created a Figma library aligned with the updated GOV.UK branding.

Key changes:

• Built a full colour scale from 50 to 950.
• Moved styles into primitives and theme variables.
• Introduced viewport-based typography.
• Expanded missing components.

This created a reusable design foundation.

Use Chakra UI instead of building from scratch

• Alternative: Custom component library or GOV.UK Prototype Kit.
• Trade-off: Less control over low-level implementation.
• Why: Reduced build time and ensured scalability.

Move from templates to components

• Alternative: Keep Nunjucks-based approach.
• Trade-off: Increased complexity for simple services.
• Why: Enabled reuse and consistency in complex products.

Extend GOV.UK component set

• Alternative: Strict adherence to existing components.
• Trade-off: Risk of divergence from official system.
• Why: Supported real product needs such as search and dynamic states.

The final system includes:

• A Figma design library aligned with GOV.UK branding.
• A React component library built on Chakra UI.
• Storybook documentation for all components.
• Direct mapping between design and code.

This creates a unified workflow:

• Designers use structured tokens and components.
• Engineers use matching React components.
• Both work from the same system.

This is an early-stage project with measurable signals of adoption.

Adoption signals

• 547 npm downloads in 10 days.
• 378 downloads in the first week.
• 30 to 40 weekly Figma views.
• 14 to 30 duplications.

Workflow improvements

• Reduced repeated design setup through reusable tokens.
• Reduced translation effort between design and code.
• Faster implementation of complex UI patterns.

This shows early demand for a React-first GOV.UK workflow.

Strong design systems fail when workflows do not support them.

The GOV.UK Design System solves consistency and accessibility. It does not fully support modern product development patterns.

This project extends the system into a component-driven workflow.