Designing with the Government's Digital Service

January 16, 2024
5 min

What is a design system anyway?

Many terms are thrown around when expanding on what makes a design system. Some of the terms used interchangeably are; pattern library, component library, design system, and style guide.

Here is a quick run-through of how these elements come together to create one part of a design system:


A style guide is related to the brand guidelines. It includes information and rules related to colours, typography, icons and spacing usage. It influences the style of all components and patterns, defining how the whole interface should look and feel.

Component library

Then we have the component library, which is the code equivalent of a UI kit. A component library would have code snippets for each component in the UI kit.

Pattern library

If we understand components as individual puzzle pieces, patterns are best practices for combining those components for specific user-focused tasks and page types. A design pattern is an evidence-based solution addressing a common design problem.

If you are as geeky as me about design systems, check out my talk, which discusses the ins and outs of building a robust design system foundation and the elements that come together to create one.

What is GDS, and why does it exist?

The Government's Digital Service (GDS) is a Cabinet Office unit in charge of driving digital transformation within the government. A big part of government digital services use this system for their design and development.

GDS has one clear goal:

"to build platforms, products and services that help deliver a simple, joined-up and personalised government experience to everyone."

GDS began in 2011 following the need "to champion a 'digital culture' that puts the user first and delivers the best, low-cost public services possible."

To deliver on this vision, they created a "new streamlined, agile organisation and an operating structure with an integrated, flexible team of skilled staff".

Benefits and drawbacks of using GDS

At Fruto we have experience designing for government websites (check out a recent project we did in compliance with GDS). In this blog I write about my personal takeaways when working with the GDS design system.

I found the GDS design system to be an excellent choice for several reasons:

As I used the GDS design system I also found a few challenges along the way:

Tips for using the government's design system

When using the GDS design system, here are some things that helped me, the wider team, and, ultimately, the service we designed.

Check out the service design manual for government services.

The GDS design system is only one piece of the puzzle. To truly understand the government's approach to designing digital services and products, you need to look at their service manual. You can find important information about user research, agile delivery, measuring success, and other key areas to delivering an excellent governmental service. The service manual is a valuable resource as the guidance for each of its areas has been thoroughly thought of, and it gives you a good idea of the elements you need to consider to design a good service. I often come back to this manual, even in projects unrelated to the government. Their 14-point Service Standard helps you have a checklist that ensures you think of users, solve the right problem, make your service easy to use, and much more.

Find the design principles that drive decision-making.  

This might seem like an extra hassle before you start the design but being familiar with their five design principles is essential to speed the process and have something to refer to when you need to make decisions. The government's digital design principles help keep user needs at the centre of your decision-making.

Get to know the GDS components and patterns before you begin.

This is helpful if you've never designed a government service before. Exploring the system before designing any pages helps you know the available options. The design system also has design patterns that you can use for specific actions. For example, if you ask users for their addresses, they have a pattern. If you don't explore the system beforehand, you might miss existing patterns for certain user actions.

Get everyone on the same page.

Even though GDS has a public design system, you'd be surprised how often I had to clarify what this was and where to find things. Make sure the rest of the team knows where to find guidelines for their work area from the get-go. (i.e. developers need the code for each component whilst a copywriter might be more interested in any guidelines around copy and content). I found it helpful to communicate with developers throughout the implementation phase.

Don't forget you're still the designer.

It's easy to fall into the trap of pulling components and styles from the design system without much thought. As designers, we often create everything from scratch on other projects that don't have an available design system. Even though this is not the case with GDS, and it considerably speeds up the process, the design system was born to provide solutions to problems that multiple teams, products and services have had. That makes a public design system valuable; it provides easy access to solutions and designs for recurrent needs or problems. If there were a solution to every design problem in the book, the system would be useless and difficult to navigate. Therefore, as a designer, you still need to problem solve and ultimately design.

Read our case study on GDS-compliant UI design and User research for the BEIS if you want to know more about how we applied GDS and met the Service Standard.

Let’s design something together, say hi.