Why the public sector struggles so much with making services easier to use
And why that might not change for a while
Almost every academic paper I read starts with some kind of phrase around the lines of: “today public services are under immense pressure to digitalise and become more citizen-centered.” I tend to roll my eyes at these broad statements, they're like scholarly click bait, but they do speak to something that many of us are confronted with in our work.
It is indeed difficult to speak in general terms about digitalisation in public services, because public services themselves are so diverse that we're talking apples and oranges from the start. But as I tend to do, I see a pattern in how public service organisations attempt to wrestle with making their services easier to use and more accessible for all. And I'm afraid my verdict after over a decade in this racket is pretty dire - I think that a whole raft factors makes it's impossible to make government services human-centered and easy to use.
This is a huge tussle of thoughts. Today I’ll start by setting the scene in my own story, as my career has somewhat developed along the lines of my wider industry.
I’m a user researcher by training. While studying sociology I needed a student job and after many years working customer service in a call centre, by some luck, I snatched a research assistant role at a usability startup in Berlin. For weeks and weeks, I would look over the shoulders of paid participants in our lab, observing how they tackle a task that I had asked them to do on a website - or often a prototype of a website. Across dozens of sessions we could say with some certainty what about the design was working and what confused users - that's the advice we sold. Over time I could see behaviour repeating, and this rule still stands for me today:
Out of 10 people, 6 or 7 would handle the website similar to each other and 3 or 4 would do something completely different, something none of us could foresee.
That's what's so fun about this kind of work, you're guaranteed a few surprises with every new piece of work. After a few rounds of iterations, we’d get that rate down to 1 out of 10 if things went well. This well-worn meme paints the picture pretty well:
This kind of work in the 2000s grew to become several big industries with their own jargon: human-centered design, UX, CX, Service Design. Soon I was no longer just hired to look over someone’s shoulder as they use a certain website. The work became systems-focused, strategic, and its scale got bigger. Now I was charged with making entire products or services “user-friendly”. And I loved it - this was exactly the development I wanted to see. There was so much to do! And I specifically wanted to do this in the public sector, so that I would not just make another bank richer or would be forced to work on dark patterns.
A typical job from here on would start like this:
“We’re bringing in a new document management system for the whole department and we need to make sure that it's easy to use."
Sure thing, I know what to do! So I’d do my research with the users, manage my stakeholders, map some journeys and throw in some personas for good measure. Sooner or later, I would find myself at the same point: talking to the developers it became clear that half the things that the users needed were simply impossible in the system at hand. And why is that? Well…
When a public service organisation wants to make a big purchase like software worth millions, it has to follow a very strict standardised process: a business case gets written (usually in broad language) that bullet points what the software has to do. The details are written by engineers who list “functional and non-functional requirements” – the needs of the people involved are considered “non-functional”, mind you. Being engineers, they don't tend to know much about pesky human diversity and simply write things such as: “must be easy to use”. This information then gets used to ask for quotes from companies, score and rank different options, and then buy something. Only when all this is said and done is it time to hire people like me, people who know that 3-4 out of 10 people do unexpected stuff with software.
So by the time that I can show with data what “easy to use” means in this case, most of the decisions are already made and there's no way to design your way out of the pickle. The system is rolled out regardless, the users get referred to a meaty FAQ document and a corporate training video, and when people complain and do what they can to avoid the clunky new system, it's their own fault and failure.
“These people are grown-ups, they just need to suck it up and deal with it.”
This example is of an internal system, but I have seen the same exact story play out with public-facing websites and entire public services on transformation programmes.
I have spent a good decade slamming my head into this wall, negotiating, nudging, influencing the decision makers who hired me. I would give PowerPoint presentations, write memos and draw procurement timelines in which I point out where the designy,-researchy people needed to be brought in to figure out what “user friendly” means. And I would always get very friendly and interested reactions: “that's great, really interesting, we should definitely look into that”, before never hearing back again. Bringing in designers early in the process would slow down the business case, and that can't happen in a project management red/amber/green world. The time and effort wasted through a clunky system that doesn't fit user needs was never an argument to shift their position. And that's when it would be time to update my CV and start the cycle all over again.
I genuinely don't think this is a problem of intentionality. I think every manager who hired me to make their system/website/product more user friendly really wanted to figure it out. But…
… our public sector is more set up to cater for the way that engineers work over the humanities. It employs designers in ornamental positions without any real power or influence.
Digitalisation and (co-)design in public administration is a massive topic in academia. Even here, researchers find evidence of those nexus points where theory and practice simply don't seem to meet. Like Saad-Sulonenet al (2023) who ran two case studies of attempts to take service design approaches in public sector settings and observe that:
“Limited research with residents and ‘light-touch’ testing was conducted, with their involvement appended onto the design process, or in Case B, not included at all. Consultancy respondents linked this to a lack of ‘appetite’ among the council’s senior management to engage with residents.”
They conclude that “hierarchical decision-making was described as inhibiting creativity, especially the capacity to quickly iterate and re-design services”, before listing what I've described here, only in nice academic speak.
My team mates and I spent unnumbered hours discussing how we might change our plight and do our part in a slow, gradual modernisation of the system surrounding us. Many of us conceded that you have to “speak their own language” and "meet them halfway”, rather than insisting on being able to apply actual design and research methods as our job descriptions stipulate.
Looking back, we internalised a lot of the systemic failures to accommodate our expertise.
A manager once told me: “remember you're working here so that something is just a little better for the users out there”. Most people-centred workers I know I have to make this negotiation with themselves, seeing the big scale of it all and knowing that they can only do so little in its face. I celebrate all those who keep going and make public services a little better, even if the public often doesn't believe it.
To me, this cycle has been so pervasive at all levels of work that I doubt it will change for some time to come. There are exceptions - I have heard of pockets of success where leaders and specialists work together to change some nuts and bolts. But those stories tend to be the exception to the rule, played out on the shoulders of a singular manager who makes themselves vulnerable by going against the grain. The system has ways of sustaining itself, which is why at least for now, I'm attempting to leave that cycle. There is a lot more to be said about those rays of light, those exceptions and ways to break the cycle, but that is for another day.