Sunday 14 September 2008, 3:40 PM
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.
Comments on this post
Good idea Rupert. I guess you've offered it here for developers to use though some might also grab what was being done at the time of the unfortunate event.
TFD
I was rereading your old blogs and I found this one about Apple:-
http://blogs.zdnet.co.uk/ruperts-diary/0,1000002156,199707,00.htm
Who would of though eh?
I'd say the same today, if Apple was in a similar fix. Those really were dark days: the product lineup was shabby, the roadmap bleak and the market (rightly) ignoring them.
I remember when the Mac first came out (and I got my hands on one that had been flown over from the US specially), and I was tech ed on MacUser back in the days of the SE/30; in both those periods, there were things you could do with the Mac that you couldn't dream of on other platforms. By 1997, that was no longer true.
If you can find a comment from someone back then where they predicted Apple's resurgence, I'd be extremely impressed...
"Most IT engineering fits well into the cycle of design, implementation, test and fix"
Or, if you're talking about software development, doesn't fit at all into that cycle.
Did when I was doing it.
Admittedly, only if you could tell people bearing down with spec changes and timetable-exploding requests to take their good ideas and turn them into charming papier-mache models...
Sadly the big red button only takes you half-way. The really hard bit is getting the crash dump of the user's brain at the time giving some insight into what they were wanting to do at the time. The user's intention and the system's state typically don't intersect. And it's typically pointless asking the poor creatures as the response will be at the level of "trying to get my job done". After 25 years working with the things my conclusion is that computers are a bad thing made worse when users get their hands on them. (Half-smiley)
Actually I could well imagine a more sophisticated version of Goodwins' idea actually getting to the bottom of the users brain. You could data mine the mouse cursor's position,velocity, button clicks and UI control interactions (particuarly the action of requesting tool tips). You collect data from a single installation of a program over time to see how the a user learns the UI. You could correlate over various programs to find outlier UI's which take users a long time to learn or have strange mouse motions during use.
The system would have to be deeply embedded into a UI API though.
There are some very sophisticated tools to do this already, including devices that track where the user's looking - I can imagine that with the right software, that little webcam in laptop lids could be persuaded to do that. We've looked at doing this sort of thing ourselves - the usability of ZDNet itself is high on our list of things we think about!
All this is fine and potentially very useful, but it produces tons of data that is quite hard to analyse - at least that was the way things were set up last time I looked at tracking software. Integrating usability into the normal software design and evaluation process, in a way that normal software engineers can use without lots of training, is, I think, the missing link.
