For various reasons, I’ve been testing & driving several different cars lately, a process I quite enjoy – getting to know the foibles of the car’s cockpit, playing with the various toys and gadgets, as well as actually learning how to drive each one according to its size, performance etc. It’s really pleasing to find a well thought out design in some bit of car UI (Audi’s MMI system is just sweet), but even more frustrating that some companies can spend $100ms developing a car but overlook some really basic functions which will just make the driver crazy (like the clock which looks very smooth and lovely but has no obvious way of adjusting the time… I’m currently driving around in a loan car which is 1 hour adrift of real time because I haven’t figured out how to move the clock forward to Daylight Saving Time, and haven’t yet gotten around to RTFM).
Thinking about all of this reminded me of two great books which, if you’ve any interest in design at all, I’d highly recommend. I’ll do this review in 2 parts, this one being, as it is, part one.
The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity – Alan Cooper
This is a fascinating book which talks about the doom-laden scenario of everything we use being computer controlled (and since the book was written around 10 years ago, shows a fairly decent grasp of the future, some of which has already come to pass), discusses the design of User Interaction, and a model which Cooper has used successfully for a number of years, centred around “Personas”.
Note the use of the term User Interaction as distinct from User Interface (UI)… in this case, we’re talking about the whole way that people interact with a system or device, not just the UI of the software – extending the user interaction model to include only as much information as required, without being stupidly modal (eg the same button doing different things at different times based on what mode a device is in, especially bad when the device doesn’t make it obvious what its mode is).
A great example of good user interaction is the iPod – good UI in software, but it works so much better because the device complements it totally. Bad user interaction design is evident in many remote controls – they have lots of identical buttons with confusing labeling (what *do* all those symbols mean?) and the software they’re controlling on the TV/DVD player etc, is sometimes less than intuitive and not helped at all by having a control that needs the manual to be open in front of the user to make any sense.
There’s one great example of good design that jumped out from reading the book – and that was Cooper’s commission to design an interaction model for a new airline video on demand (AVOD) system. Various attempts were made to get something that could display quite a lot of possible options (since there were many films & TV shows which could be watched at the user’s demand), without having to give any instruction on how to use the thing, even to people who weren’t familiar with what they might expect on modern consumer electronics or computer systems.
After selecting and rejecting various ideas, Cooper settled on a simple UI of a rotary dial positioned directly below and in the centre of the screen, combined with thumbnail views of the film/show. Show someone a rotary dial or knob (suitably designed – maybe one with serrated edges and no obvious way to pull it out) and they’ll instinctively turn it before trying anything else. (This is a topic also covered by the 2nd book in this series: it deals with how a device naturally affords itself to the user – eg if you pick up something with a single, raised button, your first instinct would be to press it rather than try and pull it off – it affords being pressed more than being prised).
If the user turns the dial back and forwards, the list of titles pans that way, and if they turn it more quickly, the list moves quickly. When they find something they want to watch, they press the button. End of user interaction model.
Again, note the distinction between user interaction and UI. As far as the user is concerned, they turn the dial and push it to pick stuff. The UI can later deal with minutae like what to do if the user selects something by mistake… how do they go back? How do they control the volume or screen brightness etc? Maybe other buttons or controls might be required for that… unless they got into some modal system where the dial would control volume… but that could just confuse things more than adding an extra button or two.
Alan also introduces Personas as a key way of focusing designers and developers on how to address the specific needs of a specific type of user; rather than being generic (“the users”, or even saying retired people, or young mothers, or teenagers or tech-savvy twentysomething males, is still vague), the concept means they actually embody a persona with characteristics as if it’s someone they really talked to – here’s John, he works in a small business IT provider, so he knows a good bit about technology but lacks the time to do lots of reading about how to implement it, etc etc.
The Exchange development group in Microsoft was one of the no-doubt many who have adopted personas when it comes to designing software – so the needs of a whole group of disparate people can be met, hopefully, by using more holistic design processes, than simply concentrating on making it look and function well to the people who’re doing the designing.
Adjunct: There’s an amusing article courtesy of SAP, on Golden Rules for Bad User Interfaces – if you’re going to sit down and design a really bad UI, follow these rules and you won’t go wrong…