Designing for Everyone

2025-12-19

I've spent the last week diving into the GOV.UK Design System, and it's completely shifted how I think about building user interfaces. This isn't just another component library - it's a philosophy backed by years of research into how real people actually use digital services.

The One Thing Per Page Pattern

Ask one question at a time. That's it. That's the pattern that underpins almost every government service.

Coming from a world of complex forms with multiple sections and validation states, this felt almost too simple at first. But then I started thinking about who these services are for. Someone applying for Carer's Allowance might be exhausted, stressed, using a phone on a bus, or struggling with the language. They don't need a clever interface - they need to answer one question and move on.

The research backs this up. GDS found that breaking forms into single questions reduced errors and abandonment rates significantly. It's not about what looks modern or what saves screen real estate. It's about what actually works for people.

Content Design is Interaction Design

I dusted off Sarah Richards' "Content Design" book, which I have had on the shelf for sometime and read it alongside this project, and it changed how I approached every label, every hint, every error message.

Government services target a reading age of 9. Not because users can't read - but because when you're stressed, tired, or unfamiliar with a topic, your effective reading ability drops. Short sentences. Active voice. Front-load the important information. Remove every word that isn't earning its place.

The error messages were a revelation. Instead of "Please make a selection" you write "Select yes if you are 16 or over". You use the same words as the question. You tell people exactly how to fix the problem. It sounds obvious written down, but I've built countless forms that did none of this.

Accessibility Isn't an Add-on

Every component in GOV.UK Frontend has been tested with assistive technologies. The focus states, the colour contrast, the semantic HTML - it's all baked in from the start.

But what struck me most was the thinking behind features I'd never considered:

  • Visually hidden text that gives screen reader users context ("Change whether you are 16 or over" instead of just "Change")
  • Error summaries that link directly to the problem field
  • Conditional reveal patterns that don't hide required information
  • Skip links as the first focusable element on every page

This isn't about compliance checkboxes. It's about the 1 in 5 people in the UK who have a disability, and the many more who might be situationally impaired - bright sunlight, broken arm, sleeping baby in one arm.

The Constraint of the Design System

Working within GOV.UK Frontend means accepting constraints. You can't just add a gradient or pick a trendy font. The components look the way they do for researched reasons.

At first this felt limiting. But constraints force creativity in the right places. Instead of bikeshedding over button colours, you focus on the service design. What questions do we actually need to ask? What order makes sense for users? What happens when someone isn't eligible?

The consistency also matters at scale. Someone using a DWP service has probably used HMRC, DVLA, or their local council's website. They shouldn't have to relearn how radio buttons work or where to find error messages. The familiarity is a feature.

Building for the Real World

The GOV.UK approach assumes nothing about its users:

  • They might be on a slow connection (progressive enhancement, minimal JavaScript)
  • They might not have JavaScript at all (forms still work)
  • They might be on any device (responsive by default)
  • They might need to step away and come back (clear, stateless URLs)
  • They might not speak English as a first language (simple vocabulary)

This is defensive design in the best sense. Not defending against users, but defending users against everything that might go wrong.

What I'm Taking Forward

I built a Carer's Allowance eligibility checker as my learning project. Three questions, error states, a check-your-answers page, and results. Simple on the surface, but it forced me to think about every micro-decision through the lens of user needs.

The principles here apply beyond government work. Ask one thing at a time. Write error messages that help. Test with keyboards and screen readers. Remove complexity that serves you rather than your users.

Whether I end up working on government services or not, this week has made me a better designer. Sometimes the most radical thing you can do is make something simple.

Resources

LinkedIn