The Inmates Are Running The Asylum
Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (1999)
by Alan Cooper (1952-)
This book is about the value of the discipline known as interaction design. The value occurs when the discipline is applied near the beginning of the design process for software-based products.
Cooper heads a firm, Cooper Interaction Design. (He is also known as the ‘Father of Visual Basic’.) The book is very persuasive, and I have already recommended it to a few people. He wrote an earlier book called About Face, which I will also look for.
He opens with a set of riddles: What do you get when you cross a computer with a camera? An alarm clock? A car? A bank? Of course, in every case the answer is the same: A computer! He goes on to describe a series of horror stories about failures of human usability of various products.
The feature that makes software-based products different from traditional mechanical or electronic products is ‘cognitive friction’ – the requirement that people have to think about what is going on in the product in order to use it effectively, and that the rules can change unpredictably. Much of the problem is traced to the different ways that such devices are seen by programmers and by ordinary people – homo logicus vs. homo sapiens. The joke is that design is what the programmers do in the 20 minutes before they start to code. Cooper promotes design that focuses not on what the screen looks like, or how the modules inside are connected, but at how users will interact with the product.
In the absence of a disciplined approach to determining the nature of a product, we get featuritis and whatever appeals to the programmers. Cooper calls this ‘dancing bearware’. It’s not remarkable for the elegance of the moves, but merely that it can dance at all. He describes a list of common faults with bad software:
- Software forgets – every time you use a program, you learn a little bit about it, but it doesn’t learn anything about you: what features you use most, how you work, etc.
- Software is lazy – programs don’t work very hard for their users. They might work very hard at things the programmers want them to do, even if they aren’t important to the user, but those are often unimportant to users.
- Software is parsimonious with information – such as the ATM that doesn’t tell you how much is available in your account before it asks how much you want to try to get out. We often make pencil/paper notes about what a program is doing, because it isn’t putting that information where it would be useful to us.
- Software is inflexible – they act the same when there are hundreds of items in a queue as when there is just one. (Programmers only know three numbers: 0, 1, and infinity.) Programs aren’t fudgable in the way manual processes are.
- Software blames users – problems the programmer didn’t want to deal with are dumped in the user’s lap, via cryptic dialogs, or just crashes.
- Software won’t take responsibility – they excessively ask “Are you sure?” when asked to perform simple tasks like deleting a file, when they really ought to be able to recover from situations where we simply change our minds.
On page 95, he gives a list of programmer characteristics from Steven Covey, and then goes on to show how programmers build software according to their own ideas of what users should want, if only they were more like programmers:
- Programmers trade simplicity for control – homo logicus desires to have control over things that interest them, and the things that interest them are complex, deterministic systems. Look at the Windows “Find File” dialog box; most users have no interest in the options presented, but programmers think everyone desires to have that much control over the search function.
- Programmers exchange success for understanding – most programmers and engineers have disassembled a mechanical clock or similar device to see how it works, but are not too disappointed if they can’t get it working again – as long as they gained some understanding. He repeats a joke:
Three people are scheduled for execution: a priest, an attorney, and an engineer. First the priest steps up to the gallows. The executioner pulls the lever to drop the hatch, but nothing happens. The priest claims divine intervention and demands release, so he is set free. Next, the attorney takes a stand at the gallows. The executioner pulls the lever, but again nothing happens. The attorney claims another attempt would be double jeopardy and demands release, so he is set free. Finally, the engineer steps to the gallows, and begins a careful examination of the scaffold. Before the executioner can pull the lever, he looks up and declares, “Aha, here’s your problem.”
- Programmers focus on what is possible to the exclusion of what is probable – if something might happen, however unlikely or unimportant, it is something the program must be built to handle. And such ‘edge cases’ generally leave their traces in the user interface. Programmers are “generous in their selfishness”: they give us lots of what they want.
- Programmers act like jocks – just as high-school jocks dominated the locker room, the playing fields, and the social world, programmers dominate others by flaunting their ability to understand and manipulate the digital world that so many others depend on. This gives them enormous power to determine what features will or won’t be implemented, and the shape of the resulting interface.
The programmer culture values reuse of code and features (which is why there are APIs), so programs are built with the components they have (every problem looks like it needs a dialog box). Programmers love difficult problems, but don’t value difficulty for its own sake. If they see a non-programmer making decisions that require an unfamiliar and evidently non-useful effort, they will subvert the implementation to avoid it.
Cooper’s approach to interaction design is to discover the types of users, and what they want and need to do with the product. These are described as personas, given names and mini-biographies, and become the focus of the design effort. Usually one or two key personas are recognized as they key types, and the design proceeds by identifying how best to meet their needs.
Design is base don the goals of the key personas. Goals are personal, corporate, practical, or false. Personal goals include: not feel stupid; not make mistakes; get an adequate amount of work done; have fun (or at least not be too bored). Corporate goals include: increase our profit; increase our market value; defeat our competition; hire more people; offer more products or services; go public. Practical goals include: avoid meetings; handle the clients’ demands; record the client’s order; create a numerical model of the business. False goals include: save memory; save keystrokes; run in a browser; be easy to learn; safeguard data integrity; speed up data entry; increase program execution efficiency; use cool technology or features; increase graphic beauty; maintain consistency across platforms. Cooper mentions the concept of hygienic factors and goals, such as keeping a well-lighted workplace. This isn’t a primary goal, but without lights no one could accomplish their real goals.
The personal goals of users are usually emotional rather than rational, but strongly reflect human nature for a very broad cross-section of humanity, unlike the goals of programmers. To meet emotional needs, software should be polite to its users. As he says, “polite software is interested in me; is deferential to me; is forthcoming; has common sense; anticipates my needs; is responsive; is taciturn about its personal problems; is well informed; is perceptive; is self-confident; stays focused; is fudgable; gives instant gratification; is trustworthy.
The design process creates scenarios (use cases) of two kinds: daily use and necessary use. The daily use scenarios are primary drivers of the design. They need the most robust interaction support; must be supported by good, built-in pedagogy; and provide shortcuts as the user gets used to them. Necessary use scenarios need robust pedagogy, but less need for shortcuts, as users won’t encounter them frequently enough to get bored. Other types include edge-case scenarios that can be ignored during the interaction design (deferred to the program design).
He recommends a technique called inflecting the interface. Within any scenario, many features are irrelevant, and can be suppressed in the interface. Thus they won’t intrude on the user, and distract her from the interface features she needs to find and use.
Cooper makes a case for thoroughly documenting the interaction design, leaving no loopholes for the programmers. Surprising to me, he doesn’t mention the practice of using the scenarios to develop acceptance tests. This would give managers some leverage over programmers.
This book should have been more influential in the five years since it was written. I only stumbled across a mention of it by accident. I will probably buy it, and insist that others read it.