What civil servants taught me about UX

For five years I designed software for a UK government department. I'm not going to name the department. I'll tell you what I learned.

Before I joined I, like most people who haven't worked in government, assumed the software was bad because the people were lazy or the systems were ancient or both. After a month I realised that was insulting and roughly 0% true.

Civil servants are, on average, more accountable to the user than any startup employee I've ever met. Their user is sometimes a vulnerable person trying to register a service. Their KPI is sometimes 'did this person not lose their housing.' They cannot fail upward. They cannot AB-test their way out of a problem because the unit of test is a citizen.

What they need from software, then, is wildly different from what a SaaS company needs:

• —Durability. The system has to work in 2034.
• —Legibility. The case officer in three years who has never seen this case before has to be able to read it cold.
• —Accountability. Every action leaves a trace because someone, somewhere, will need to defend it.
• —Patience. The training cycle is months, not weeks.

A startup PM hears that and recoils. A startup designer hears 'durability, legibility, accountability, patience' and reaches for the espresso machine. I get it. I used to do the same.

Every one of those constraints made me a better designer.

Durability means I stopped chasing the framework of the week. Legibility means I stopped being clever for clever's sake. Accountability means I started writing the audit log first and the screen second. Patience means I stopped optimising for 'user delight' and started optimising for 'user not crying at 4pm on a Friday.'

If you took the average civil servant's checklist of what software has to do and gave it to a startup, the startup would be substantially better. Not flashier. Better.

Civil servants taught me one more thing, which I'll close on. Software that runs the country has, at most, three minor allowed reasons for breaking, and the people working on it know all three by Tuesday. The rest of us, in startups, would benefit immensely from a similarly specific answer to 'what is allowed to fail and why.'

Most startups have no answer. That's the gap.