Taming the Usability Monster, one button at a time

Talking of silicon/carbon interfaces, let's return to the curious case of usability. It has been known forever in IT that there's no point in having smart technology if it's unusable – and, conversely, if you make something that's very easy to use you can get away with murder behind the scenes (Stand up, Twitter. If you can).

The trouble with usability is that it's very hard to get right, and much, much harder to keep it so. Most IT engineering fits well into the cycle of design, implementation, test and fix: you can write down the functionality of your new product in terms that can be quantitatively communicated and checked, and come up with a final specification that's comparatively simple to check against what you're produced.

Usability doesn't work like that. There are plenty of sound usability design principles that can be applied, but if you drift away from them here and there then it doesn't seem so bad – at least when you're in the middle of a product where the tech specs are shifting, time is tight and there are all manner of compromises needed anyway. And it's not as if most programmers or their managers want to waste time on frills when there's interesting tech work to be one, nor that marketeers would know how to sell usability as a killer feature anyway. Plus, usability testing is expensive, slow and difficult: unless you're in an exceptional environment you can't afford to apply it across the board all the time. But how do you know where to focus it?

The end result, nearly thirty years after Steve Jobs saw the light at Xerox PARC, is that even with Apple's rampaging success as a guiding star nobody else gets it. It's tempting to say that Apple only gets it because it's an extension of that one man's ego – and that doesn't scale industry-wide (thank heavens). Whatever the reason, trying to design usability in from the start clearly doesn't work, not with the people we have doing things in the way that they do.

So I have a cunning plan. Now we have the Internet, we also have centralised bug reporting: something goes wrong in software these days, and you get the chance to send back the smoking ruins to HQ for them to rake over. It's not that this increases the chances of you getting your bug fixed as a direct result, more that this provides the software companies with a statistic sampling of where the real problems are. That is a very valuable insight, not only for fixing the current generation of software but in deciding where to concentrate in the next.

You can't do that for usability. Broken usability leaves no traces in the machine; there's no crash dump, no corrupted data structures, no nice hexadecimal listings. All that happens is that the user doesn't get the job done; they get frustrated, angry and confused. Yet even if they knew exactly who to talk to, they probably couldn't describe the problem. There is a huge disconnection, and nothing gets fixed. Ever.

So let's fix that first. Let's have a "This doesn't work!" button in as much software as possible, labelled in large, friendly letters and placed where the user can always see it through the tears and red mist. When the user presses it, the software sends back a trace of what parts of the user interface had been involved up to that point. And that's it.

It's tempting to add stuff like a dialogue box requesting more details from the user, or perhaps a tick list to squeeze out just a bit more information. That would be a mistake, at least at this stage: you can't expect users to be able to diagnose the problem in ways that make sense to engineers. It's far more valuable to build up a profile of frustration points, in the same way that a profiling compiler highlights areas requiring design attention for performance reasons without trying to second-guess what's actually happening. Once designers become aware of what doesn't work, they can go and fix it – in fact, they'll be gagging to make it better. It becomes the sort of problem they're trained to sort out.

The long term effect of this will be to teach the entire product generation process about usability, through providing the feedback path that's currently missing. It will quantify the results, help manage the application of usability ideas by showing what works, and get people at all levels thinking about the human interface implications of the technical decisions they make. It has the potential to kick off cultural change, and that's what's needed more than anything else.