Bad service design is not a strategy

This week, a very senior UK government official told me that better digital services present a real risk to his department, and that on balance, he might feel more comfortable not bothering.

His argument is a familiar one. An existing online service is terrible. While that’s a pity, the poor design suppresses demand for that service. The department makes plans and assigns resources on the basis of that low demand. If you were to build the service properly so that people actually preferred to use it, you would increase demand. The department couldn’t cope with this and would fall over, thereby breaking the whole service. Oh, and fixing this would mean unpicking enormous complexity and internecine office politics. So why take the risk?

The best way to examine arguments like this is the pub test. Can you go to the pub with friends and family — not work colleagues — and make that argument with straight face to a chorus of appreciative nods? I like to think my friends would give me a good slap if I tried that in this case.

Unfortunately, it’s difficult to take senior officials down the pub to meet your friends (though the Public Accounts Committee is the best proxy for the pub in the current system).

While the argument that doing something properly is riskier than maintaining a broken system sounds (and is) ridiculous, it has a seductive ring to it. Changing anything is always potentially risky. Departments have traditionally been set up in a way that’s predicated on making it difficult for the public to access what they offer.

Counteracting this, as with most kinds of official inertia, means hiding all that dangerous common sense behind reassuringly familiar over-intellectualised argument. Here’s my effort at over-intellectualising.

The first thing is to make clear that there is no version of events where the department should have the sheer front to actually take credit for crappy services. At no point did anybody decide that part of their demand management plan was to build a terrible service. Rebadging incompetence as strategy is denial at best, and downright disingenuous at worst.

(If you’re really deep into the Twilight Zone, some officials might admit that they did, in fact, actually plan to build something terrible. These are dark patterns, and these people must be stopped. As an upstanding citizen, I think you are morally obliged to open a can of FOI on their ass at this point, unless you’re happy with the state doing something even Ryanair has realised is a questionable strategy).

The second argument is all about proving the status quo is actually far riskier than doing nothing. The best way of doing this is to count the cost of current failure. This is easier said than done, because departments go to incredible lengths to hide this information from themselves, let alone the wider world. The standard official argument for not doing anything is that it increases risk in the form of:

• cost
• failing to hit targets
• incompatibility with existing systems
• reputational damage
• security
• people dying

If you’re lucky, you’ll be able to find strong evidence that the current service is palpably failing to achieve an acceptable level of risk by any sensible measure on the first four of these. They’re usually relatively straightforward to build a case around, because there are benchmarks, published stories or compelling anecdotes to draw upon if you dig for long enough.

The last two are the final refuge of the cornered incumbent. They are never backed by data, playing instead on emotion and fear. That’s not saying they aren’t important, it’s saying there’s simply no basis of proving what you have now is working better or worse than any alternative. If you’ve reduced the machine to those arguments, you’re winning.

At which point you’ll need to move on to argument three, which is pointing out how uncomfortable we ought to be about not knowing things. Real service design done properly — considering the system from end-to-end, and confronting every problem you meet along the way — is about knowing that changing the front-end of a service will materially increase or decrease demand.

Many departments still have no idea what effect their interventions will have. Literally none. And certainly, it’s possible that fixing a service will substantially increase demand for appointments, or benefits, or face-to-face support. But equally, a much better online service could cut out huge swathes of failure demand, or duplication, or wasted staff time.

The point is, you don’t know. And that should scare the hell out of you, because it implies you’re giving out billions in public money without any real sense of what might happen as a result. And who would accept or believe that?

Certainly not the people in the pub.