Why Government Apps Feel Like They're For No One

If you've worked on government digital services, you know this feeling - shipping something that technically serves everyone but doesn't truly delight anyone.

Here's what I wish someone had told me earlier: this is often by design, and it's not your fault.

Why we end up designing for everyone (and no one)

Universal design asks: "How do we make this work for as many people as possible?" This approach is fundamentally appropriate for public services.

When you're building a service that must serve the entire population - from teenagers applying for their first ID to elderly citizens renewing benefits, from tech-savvy urbanites to rural residents with limited connectivity.

The mandate is clear: Create one solution that works for as many people as possible.

Unlike a consumer app that can target specific demographics, a government service can't exclude people. The starting point has to be broadly accessible. Legal requirements around accessibility, language access, and equal service delivery reinforce this approach.

But here's the tension we don't talk about enough: when you design one solution for everyone equally, you often end up with something that's "average for everyone, optimal for no one."

The problem with designs that are for no one

If you've been working on government apps, these should sound familiar:

Forms

• Form inputs need to work for people using screen readers, so you add proper labels. But they also need to work on old browsers, so you can't use modern autocomplete features.

  
  

• They need to work on slow connections, so you strip out helpful inline validation.

  
  

• They need to work without JavaScript enabled, so dynamic help text goes away.

• The button text needs to be clear for people with cognitive disabilities, but also precise enough for legal compliance.

Language

• The language needs to be simple enough for those with limited literacy, but comprehensive enough to satisfy policy requirements.

  
  

• You want to say "Upload your payslip" but legal requires "Provide documentation of earned income from employment for the most recent 30-day period" - you end up with awkward hybrids like "Upload proof of income (payslips from the last 30 days)"

  
  

• Breaking instructions into very small steps helps some users but makes others feel talked down to: "Step 1: Click the button. Step 2: Wait for the page to load. Step 3: Look at the screen"

Flow

• The flow needs to be linear enough for elderly users (one question per page) while not feeling patronising to digital natives.

  
  

• Accordions and collapsible sections reduce vertical space but hide information. Less-savvy users on mobile might not realize there's more content hidden.

  
  

• Explaining why the user needs to submit certain information helps trust and comprehension but makes the form feel longer and more bureaucratic.

  
  

Every decision becomes a compromise. And suddenly you're launching something that serves everyone adequately but no one exceptionally well.

Before you give up!

Recognise that this is the expected starting point for government services. This will help you to:

Manage your own expectations and emotional investment. You're not failing as a designer when your government app isn't a delightful user experience. The constraints are real, and the requirement to serve everyone from day one means trade-offs are inevitable.

Set realistic stakeholder expectations. When leadership asks why the app doesn't feel as smooth as commercial apps, you can articulate that we're solving a different problem. We're not optimizing for one user segment - we're ensuring no one is excluded.

Plan for iteration from the start. Knowing that v1 will be universally adequate helps you advocate for a phased approach with clear plans for improvement.

Document what you're learning. Even in that "fine for everyone" v1, you're gathering intelligence about which communities struggle most, which features cause confusion, where people drop off. This becomes your roadmap.

Progress to inclusive design

After that initial universal design launch, you have a chance to move to inclusive design.

Inclusive design acknowledges that one solution won't work for everyone, so it provides multiple pathways and alternatives.

This is the phase where you add:

• Multiple ways to complete tasks (online form + phone option + in-person)

• Different modes within the digital experience (guided step-by-step flow + quick form for experienced users)

• Alternative input methods (typing + voice + document upload)

• Language options beyond just translation

• Flexible formats (video instructions alongside written ones)

Inclusive design feels like progress. And it is! You're moving from "barely works for everyone" to "offers real choices so people can find what works for them."

Celebrate each new option we added:

• "Now users can save their progress!"

• "We added SMS notifications alongside email!"

• "We offer both simplified and detailed help text!"

• "People can upload photos of documents instead of typing information!"

  
  

These improvements matter. They genuinely help people. And if you're still all fired up after this stage, it's time to bring out the big guns: equity design or designing for social impact. More on that in our next post.