Design integrity

Designing complex systems is complicated. Sometimes there are interactions between the pieces which don’t quite join up, customer journeys which turn out to have structural obstacles. Some of that can be obscured or avoided through good interface design, but sometimes the underlying ugliness just pokes through. This screen marks the successful end of a transaction. […]

Reading and doing

The team have released a new version of their home page. It’s now quite a long way from the simplicity of where they started – but kudos to them for respecting the discipline of user focused design. But looking at the page, one small thing struck me (well, one thing other than the other […]

Systemic distortion

We all know too much. What each of us knows too much about is very distinctive, but it’s a safe bet that we all know too much about something. When other people, who know that thing less than we do, attempt to describe it or to understand it for themselves, they get it wrong, not […]

How many things does government do?

Easy: 1,479,025,887 GDS has produced another fascinating tool, this time providing a list and volumes of government transactional services, which it turns out are used a shade under one and a half billion times a year. Richard Sargeant has a blog post introducing the endeavour, and making clear that this initial version is an alpha […]

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…