I wrote a slightly grumpy post yesterday about some problems with the Ordnance Survey maps app. It went on my other blog, because of the circumstances in which it happened. But it’s worth mentioning here too, because it’s an example of a service design failure with some wider implications.
Things go wrong. Things go wrong in complicated ways because they have to operate in complicated environments. When things go wrong they should degrade gracefully, not break abruptly when there is no need for them to do so.
Graceful failure operates at different levels. Dan Catt has just written a marvellous post about designing ‘shutdownability’ from the outset. It is one of the principles of agile working that failure should be embraced. As Paul Clarke said a couple of years ago
As ever, design systems for the things that will go wrong, not the things you expect to go right.
And so to the grumpy post. This is the key paragraph – but do read the whole thing.
It should be pretty obvious that updates – particularly updates requiring significant amounts of data – should happen when the user chooses. It should be pretty obvious that the fallback to a failed update should be that the earlier version continues to work, not that the whole app locks up completely. And if progress is being stopped by a preference setting, it should be pretty obvious that giving the choice of changing the preference is better than defaulting to failure.
We could all do with failing better.
I always enjoy reading @pubstrat but my he’s very good when he’s angry (or at least irritated) https://t.co/RtlmzTF16t
Comments are closed.