How we crafted a design language for hundreds of services across government
Most people would recognise the GOV.UK design language. It’s the work of many wonderful designers and its most distinctive elements are the crown logo and GDS Transport font. The design language is so well known that if I asked you to draw a government website, I expect most would draw a black bar, black text on a white page and maybe hints of blue elsewhere. Services on GOV.UK, like applying for a passport, filing a tax return and many others used by millions of people each year are built using that design language.
The government also delivers services for staff which sit outside of GOV.UK. These services help the government to work effectively and make decisions that affect millions of lives. However, services that sit outside of the GOV.UK structure can't use the same design language because of licensing restrictions, which leaves designers in government with a problem.
Creating a new design language
Working in the design operations team in one of the large government departments, my role was to scale design across hundreds of services. I had already built a design system and this seemed like another problem worth solving, which would complement the design system work and build on what we had already learnt. We knew teams could waste time and effort reinventing solutions, or leaving services essentially ‘undesigned’ because of the lack of a clear design language.
Like any language, a design language relies on rules to help people understand how to use it. It explains those rules, guiding designers how to consistently implement the language. So we set out to create consistent guidance that could be used across government when designing services for government staff users. We wanted to lay the foundations for a more cohesive experience that teams could build upon over time.
To make the project a success, we knew it’s main goals had to include:
- a clear language that removed any ambiguity
- a language that could be scaled to be used across hundreds of services
- a language other government departments would use
Language at scale
One problem we knew a clear language could solve was the inconsistency of staff services, which made them less usable. Inconsistent services force users to learn new ways of doing things, which leads to more errors and users completing tasks slowly or failing to complete them altogether. Some users relied on multiple systems, and having to constantly switch between differently behaving systems made things even worse for them.
One thing we did was start with the least amount of design we could get away with and only add if we saw a need. We used a very minimal colour palette and very few UI elements. This perceived simplicity, like anything simple, took a lot of work. But by focusing on simplicity, we knew there would be a better chance that the work would scale.
To make it scale, I had to make sure it was well researched and simply crafted. I encouraged select teams in my department to use it and only increased the amount of teams using it when my confidence in it grew. I worked closely with the teams, learning about unexpected issues This approach meant we could keep learning while slowing scaling, turning the tap to fine tune its use until we were ready to release it.
Accessibility
To create a design language that would scale across hundreds of services, we knew accessibility was going to be important. It always is. The biggest decision we could make when looking to increase accessibility was choosing a typeface. I focused on a font with a high x-height, good character recognition and readability at small sizes. The typeface also needed to be open source and a clear winner was Inter.
Other aspects of the work like clear menus and navigation and a consistent styling of interactive elements increased accessibility. We also made other small decisions that would help, including using a very light grey as a background. From research, we knew many users were on these systems for long periods and the contrast between a white background and black text was a lot for people's eyes.
Reuse and sell
To help make the project a success, I knew the importance of reusing what was already available in government. By extending the existing patterns and components, and leaning on existing research evidence, I could not only move more quickly but also justify and sell the project to the many design teams across government departments.
We purposely designed this work to be used across teams and departments. I worked with a lot of our departmental teams to understand how well our language was understood and how it could be applied to their work. We also strived to make it as easy as possible for other departments to re-use it with minimal changes, reducing wasted effort across government.
I initially collaborated with Government Digital Service (GDS), Ministry of Justice and the Department for Work and Pensions to make sure our work would scale. By working with both teams and departments, I was able to learn a lot and iterated the language to better meet services needs.
Checking back in
I left the government over a year ago but one of the reasons I wanted to write this post was because I see old colleagues still iterating and improving the guidance I first worked on. I built the design system which contained the design language in GitHub and so I still get notified of the improvements that are being made. I love that something I started is still being used today.
Checking in with Karwai, who is now the lead on the project, it’s interesting to hear the iterations that are being made. They’ve made the different design language options in government clearer as our initial guidance left teams still confused. And it’s great to hear the team has grown and is now cross-functional with researchers and content designers working on the language. And many other cool things. Go team.
The design language can be found in the Home Office design system.
My thanks to Andrew Travers and Karwai Pun for helping with this post.
Back to journal