The digital transformation illusion

This is something you see quite often as digital impinges on old-fashioned industries, that first of all digital makes the old product better, and then all of a sudden it creates a new product that kills the old product entirely. And so digital looks to begin with like everything’s going great, that it’s going to be wonderful, we’re going to make lots more money than we did before, and then all of a sudden, somebody comes along and crushes you.

Story and history

This post is mainly about The Imitation Game but was written before I had actually seen it. So it’s not a film review in any normal sense. Having since watched the film, I have added a short update at the end, which isn’t a film review either. What’s the difference between history and a good […]

Modes of failure

A lot of care goes into designing successful interactions. The same level of care is needed in the design of unsuccessful ones. Three times in the last three days I have been wrongfooted by interaction failure, from which I draw three lessons. The three examples are very different from each other in some ways, but in each […]

Service as a service

Not long ago, staying in Cornwall entailed giving up on most modern forms of communication. This summer, the house we have rented there for the last few years had sprouted broadband. Not very fast broadband, admittedly, but a big improvement on no broadband at all- and it’s just there, no fuss, no charge. Back in London, […]

Turning on the tap of affordance

The semiotics of plumbing is a slightly unlikely topic, but having not long ago discussed the affordance of soap dispensing, I now turn to the tricky question of how to turn on a tap. There follows a ludicrously detailed description of an utterly trivial process. If that prospect does not fill your heart with joy, […]

Better questions get better answers

Getting the right answer is important. But it is impossible to get the right answer unless we ask the right question. Time and effort invested in better questions pays off in better answers. There used to be a zebra crossing across the main road. Pedestrians could get across easily and motorists were discouraged from using […]

Print and be damned

The private sector, as everybody knows, has clear and customer-friendly systems and services, because the customer is king. The public sector, on the other hand, revels in the obscure and incomprehensible because… well, just because.

And so it was with a light heart that I set out to fix a security flaw in my printer (one of those chores which never existed until Moore’s law came along to free us from drudgery).

The rest of this post sets out the process in mind numbing detail, partly as minor therapy for me, but more importantly because as with several recent posts, telling these stories is a powerful way of bringing to life why service design is not just an affectation and because every one of them is a reminder that we are constantly at risk of inflicting this pain unless we are as constantly vigilant in avoiding it. Fixing printers, opening bank accounts and paying for parking permits don’t on the surface seem to have much in common, but in each case the problem was not that the task could not be completed, it was that there was no sign that anybody involved in designing the service had ever systematically worked through what it would be like to do it as an ordinary user.

The blow by blow account which follows is a fairly grim one, but there is some good news. I went through this process and wrote the account back in January but never quite finished it. Quickly checking the links today shows that the process is now not quite as bad as it was then, with broken links fixed, cumbersome steps made slicker and FTP documents converted into web pages (it also reveals that the printer needs updating again, but lets not worry about that for now).

But that in turn throws up an interesting question about agile approaches. Iterate, then iterate again say the GDS design principles:

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

I am with them on that, not least because of the risk they identify in the small print of bottleneck by specification. There is a risk the other way too, though: how good does it have to be to reach the minimum standard? Is anything functional good enough for a first attempt? If we are feeling relatively generous, we can set the bar fairly low for publishing a security alert where there may be real urgency (though it’s not as if this was the first time there had ever been a security alert), but there is a cost. If it was bad enough the first time, it doesn’t matter how good it gets by the second or third time, because I won’t be back to see. Not so much of an issue, perhaps, for an obscure bit of technical support, but critically important in trying to establish a customer relationship.

So the thing which is too often missed in the practice, rather than the rhetoric, of minimum viable products (though not, to be clear, by GDS) is that the minimum is about scope more than it is about quality. That’s not to say that further iterations won’t improve quality; done well of course they will. It is that iteration and user feedback are no substitute for not having done a good enough job in the first place.

And so to the quest through a land of magic and adventure…