User needs, not government needs

My last post talks about how government services aren’t working. This is true in a wide variety of cases, both in the sense that the IT systems underlying them are unreliable or at the end of their lifetimes, and that people trying to use the services in question can’t successfully do so.

The perennial question is, why does this happen so often in government? It’s not a matter of people deciding to build good or bad systems and services, that if people only knew better they’d be able to implement reliable IT systems and user-friendly online services. It’s that there is a whole range of government processes and activities that take time and energy away from focusing on whether actual people can use a service or not. And, they take away teams’ ability to course correct and do things differently based on what they’ve learned.

Take the road less travelled

In Ottawa I had this poster above my desk, taken from a UK Government Digital Service (GDS) catchphrase: “User needs, not government needs”.

You can download a copy of this poster in English and French.

When you’re prioritizing what activities to work on, it’s usually not that hard to tell if something is responding to a user need or a government need. Does the activity help understand an actual person (outside of government) and how they’d use the service you’re building? Does it let particular users (like people using accessibility software) more effectively interact with your website or online services? Does it generate data that can help inform future improvements to the thing you’ve built, improvements from the perspective of actual end-users?

If it’s not doing any of those things, it’s probably solving for a government need: a presentation deck for a project oversight committee; a detailed rationale about why you need to use the cloud infrastructure you’re planning to use; a roadmap of feature requests stretching long into the future, past where you know if they’d be useful to people or not; an IT request for permission to use a non-standard tool; a report on your progress in the form of a long narrative document.

Although some of these (particularly navigating through various gatekeepers) end up being unavoidable prerequisites, none of them directly contribute to making a working, user-friendly piece of software.

One of the ironies of government IT work is that these “government needs” – cumbersome project management processes, governance and oversight committees, layers of stakeholder approvals – are often created or expanded in response to previous IT failures, even though over time they become one of the root causes of subsequent failures.

Don’t revert to what’s familiar

Gatekeepers notwithstanding, part of the reason that teams spend so much time on these “government needs” is that they’re familiar activities. Successfully designing, building, and shipping software uses different skills and ways of thinking. Writing reports and presentation decks is much more like any other part of working in government, and it’s easy to focus on the things that you’re already familiar with.

GDS’s early years were revolutionary because they really lived by this message. Their first design principle was to “Start with user needs” – with a little asterisk saying, “not government needs”. They followed that up with an unprecedented (and largely new to government) focus on design research: interviewing everyday people who used existing government services, bringing people into their offices to watch them interact with prototypes of new or redesigned services, and using those observations and insights to make changes to the things they were building.

Mike Bracken’s 2013 blog post – The strategy is delivery. Again. – does a great job of capturing how lopsided governments’ prioritization of internal needs over user needs tends to be.

Focusing on user needs – learning from people, building things that meet their needs, and continuing to iterate based on their feedback – is challenging work even without the pressing distraction of government needs. But it’s work that makes it vastly, vastly more likely that people can successfully use the things you build. And that, in turn, is what’s ultimately worth it.

Interested in reading more? Mark Headd’s Process Eats Culture for Breakfast and Peter Karman’s Digital Service is not about technology are both must-reads on this topic, published earlier this month.