It can be easy to confuse leadership with charisma. Charisma may for some leaders be some part of how they do leadership. But for most leaders, most of the time, it’s about keeping the plates spinning.
How do you stop your stock of nuclear weapons accidentally blowing up the world? How do you devise a straightforward system for recording penalties on driving licences? Those sound like very different questions, but they turn out to have some unexpected similarities. Let’s start with nuclear weapons. Eric Schlosser has written an extraordinary book about […]
Last week, in a post ostensibly about fixing printers (so all is forgiven if you glazed over and didn’t read it), I talked about rapid and iterative design, but wondered how minimal a minimum viable product could be: There is a risk the other way too, though: how good does it have to be to […]
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…
I went to two events yesterday. The first was the launch of the Government Digital Service, or rather a housewarming party for their shiny new offices. In fine agile tradition, they put on a slick show and tell with short sharp presentations about their work and achievements topped and tailed by Francis Maude, Mike Bracken […]
Everybody who has had much to do with the development of government web services knows that there have been failures of imagination, failures of bravery, failures of technique and failures to seize opportunities – as well as successes in the teeth of opposition and incomprehension. Few have had the opportunity to start from scratch (though […]
I went a couple of weeks ago to a fascinating discussion about the nature of service design, organised around a book published last year called This is Service Design Thinking. The two editors of the book were due to lead the session but were at the wrong ends of a skype three way video conference […]
I have cracked the problem of government IT. A few months ago, I argued that there is no such thing as the government. Now, in a further breakthrough, I have realised that there is no such thing as IT either. Putting those two thoughts together leads unavoidably to the conclusion that the problem of government […]
I have written a couple of times about the gap I see between the brilliance of hack days, as exemplified by Rewired State, and the need to build customer needs and user experience into the mix: These projects can get off to a great start using their originators as their own use case, but they […]
The Google Reader team are pleased with themelves, not without reason: Today we built the 500th version of Reader; over the 5 years that we’ve worked on Reader, that works out to almost two builds a week. I suspect that’s distinctive, if at all, only in that they are both keeping score and saying so […]