Skip to:

Classic computing titles: The Inmates are running the Asylum

Whatever they teach you on a computing degree, it doesn’t seem to be sufficient to create an effective web site. One of the paradoxes of the modern world is that we are surrounded by IT, and yet those who have studied IT formally seem often incapable of creating software that genuinely meets our needs – a glance at a few developer-led websites is often sufficient to demonstrate that. Alan Cooper’s book, The Inmates are Running the Asylum, although published some fifteen years ago, provides an idea why that might be. The author himself has a highly respectable track record as a developer – he was responsible for Visual Basic, so he can claim some understanding of the programming process, and of the programming mentality. So if he says that programming alone is not sufficient, then you are right to take notice. Everyone with an involvement in IT, whether as a user, or as an information professional as a sponsor and influencer could benefit from his assessment of how programmers think.

 

Cooper is worth reading because he doesn’t simply adhere to the fashions of the day about condemning the dominant IT companies of his day (which when he was writing meant it was fashionable to see Microsoft as the enemy). Nor does he unthinkingly accept the notion (new for 1999, universal today) of “customer right, developer wrong”. His view is considerably more subtle than that, and even if I have some reservations about his solutions, I agree with his diagnosis of the problem. For, as he points out, customer-led design can lead all too frequently to feature overload, to designing for nobody in particular, but for everyone in part.

For Cooper, the zapper to your TV is symptomatic of the problem. It represents “cognitive friction abandonment” when you encounter a problem where the parameters seem to change while you are dealing with it, so that in the end you simply give up. How many software programs do we abandon after a few minutes because we can’t be bothered to learn what appear to be unnecessary details? According to Cooper, programmers design for expert users, while marketeers design wizards for beginners; yet most of us are neither beginners nor experts but in the “perpetual intermediate” stage. We know a bit about IT, but not that much, and we can’t be bothered to learn more. By way of analogy, when we get on an aeroplane our instinct is to turn right, into the welcoming (and instrument-free) cabin, while programmers would instinctively turn left, where there is a plethora of dials and controls. The solution is not to wish that we knew more, but to create programs that mean we don’t have to know any more than we do. Programmers see things differently. For programmers, the world does not know as much as it should about how programs work. The author recalls asking a classroom of programmers how many of them had taken a clock or mechanical device to pieces when they were younger – most put their hands up. And how many of them, continued Cooper, had managed to put it back together again? Almost none of them. In other words, he explains, programmers willingly trade failure for understanding. What does it matter if the program doesn’t quite work if I know understand what it does? Given such a mind-set, it’s hardly surprising that software works so poorly. Incidentally, I’m no programmer, but I have vivid memories of taking things to pieces and failing to put them together again. I’m not sure if it taught me how they worked, either, but that’s another matter.

A further insight into software development is “negative feedback”. For most of history, adding more features to a product has cost time and money. So you don’t add more features to something unless there is a clear and ongoing demand for it. But to add extra features to software is more or less free, once the development is done – it adds no cost to the product, and if the product now does more, surely this is a benefit? Of course, the opposite is true. Two commands are almost always worse than one, and it usually takes more design to remove controls than to add them. Cooper points out how Microsoft, with the biggest budget of any software company to get its products right, nonetheless loads them with little-used and unnecessary features - unnecessary, that is, for most of us. In all releases of Office up to 2003, minor features and core features would be placed next to each other on drop-down menus, thereby making the selection of any feature more difficult. There must be a better way than this, cries Cooper, and of course he provides the answer. “Interaction design” is his term for a rigorous design process that takes place before a line of code is written, much like a Hollywood film spends months in preproduction before the cameras roll – it is cheaper, and more effective, that way. Of course, today we would look to an agile-based approach, but that doesn’t detract from the author’s incisive recognition of the problem.

Cooper is most famous as one of the creators of the “persona”, the target user for whom the software is developed. This book contains one of the most powerful justifications for personas, those imaginary actors whose preferences, identity, and even favourite audio tracks are so beloved of modern design teams. Intriguingly, Cooper demands we should have at most three personas, and in fact implies we should ideally reduce that to one. That’s a tough challenge indeed! In fact he slightly disproves his own recommendation with the first case study he gives, a project for in-flight entertainment. Passengers want to choose their movie, and this program provides that choice, at the back of every seat on the plane. The solution they came up with satisfied two groups of users. For the technically innocent, who had no knowledge of selecting from menus, they simply lined up all the film posters in one long horizontal band. All you did was turn the button until you reached a film you wanted, and that was it. Perhaps today we might want something slightly more sophisticated. But Cooper describes how the more discerning users were catered for by providing a horizontal bar at the bottom of the screen with additional search and selection options. Personas are still very much with us, although some of the author’s other recommendations look decidedly risky. Is it really possible to design for a single persona? And can you really have a successful car that has been rejected by 80% of the focus groups? Cooper’s example is to design a car that meets no one user’s needs perfectly, but all needs fairly well – the family user, the single person with shopping, and so on. The risk is that by meeting everyone’s need partly, the car will never be perfect for anybody.

Some of this book’s insights are so fundamental, you wish they could be engraved on every computer screen. Why is it, asks the author, that computers are so stupid? They throw away information that is given to them by the user, such as preferences, ways of working, favourite programs, yet even when the computer has only a single user in its entire lifetime, it still doesn’t know anything about you. Perhaps with the semantic web things might change, but the desktop PC remains in many ways a very dumb animal. If you want to know how programmers think, then this is the book for you. In a hundred years, when the terms Microsoft and Apple are like hieroglyphics carved in stone and only understood by archaeologists, the insights about programmers in this book will survive. Like many of these revolutionary guides to software, this book is better at describing the disaster than solving it. Cooper’s vision where companies abandon deadlines and give full control to the interaction designers who can work in a team without developers or outside interference to create a product design is optimistic, and based to some extent on the classic consultant’s cry “trust me – I can solve it”. I don’t think even designers have all the answers to the problems we expect software to solve. But for a guide to pointing out the worst excesses of developer-led IT, this book has no equal.