The Inmates Are Running the Asylum


October 1999

The Inmates Are Running the Asylum

CIDMIconNewsletter Alan Cooper; Macmillan Computer Publishing 1991; ISBN 0-672-31649-8
Review by JoAnn Hackos, Center Director

Alan Cooper’s latest book, The Inmates are Running the Asylum, should be required reading for information-development managers, if you want to understand why the products you are supporting are so unusable, and if you want to influence their usability. Cooper, a well-known expert in what he calls Interaction Design, uses half of the book to tell us what is wrong with software products, and half to suggest a method for doing something about it.

Many of us found Cooper’s first book, About Face: The Essentials of User Interface Design (IDG 1995) to be a terrific treatise on better interface design. We also found his style to be irreverent, challenging, and amusing. He continues the irreverent tradition here. Many programmers will find his portrayal of their work very uncomplimentary. Fortunately, Cooper has the credentials to make even recalcitrant coders pay attention-he was the originator of Visual Basic and has considerable programming experience. He’s learned, however, that good programming skills are not enough to create usable products. In fact, a programming focus is most likely to result in unusable products.

Cooper begins with several examples of why computer-based products fail. He has great stories about cars, banks, and alarm clocks that we can easily relate to. The problem is that these products are designed by people who don’t relate to the way most of us think-they are programmers. Cooper argues that the design of interactive products needs to be done by interaction designers, not software engineers. Interaction design is much more than interface design, which, according to Cooper, refers only to the surface appearance of the software. Interaction design goes much deeper, involving the way people expect a software tool to behave relative to their goals.

The seemingly uncontrollable proliferation of software features takes a direct hit from Cooper. He argues that software has grown in such complexity with continuously added features that it is out of control. Most software introduces so much cognitive friction that it is attractive only to so-called power users who are attracted to the difficulties and enjoy figuring them out. Most of us are survivors. We know something is wrong, but we don’t know what. As a result of an unacceptable level of cognitive friction, most of us decide to use what we can figure out and ignore the rest.

Information-development managers will especially enjoy Cooper’s explanation of the product-development deadlines we have to handle. In Chapter 3: Wasting Money, he analyzes the obsession with “time to market.” You know the argument-It’s better to ship a product on time, even if it doesn’t work and no one can figure out how to use it. Cooper explains what he believes is the source of this arrogance-most managers do not know what a finished product actually looks like. Software, he argues, is never designed at all, just coded. Without a specification, “done” is never defined and, therefore, never reached.

The problem is the lack of a description of how the software will react for the end user. Cooper explains that a shopping list of features is not a description. To construct a building from a list of features will result in a very odd and unusable building, although it will have a staircase, several rooms, a roof, an elevator, some windows, and so on. The feature list of software is just a list, not a design. It results in what Cooper calls Feature List Bargaining. Marketing produces a feature list and a deadline, with only vague definitions of the features. To meet the deadline, the programmers begin to cut out features. “Features are traded for time; time is traded for features” (p. 46). Difficult to code or difficult to understand features descend to the bottom of the list. All the analysis done of the user environment is lost in the trading.

Cooper continues to explain the sources of software failures. He shows that the failures of usability are embedded in the culture of software development and how our companies approach customers.

If we want only a book that is fun to read because it catalogs all the problems that we are experiencing, that would be OK. Luckily, Cooper takes the book to the next level-the solution. He describes in Part IV three aspects of the interaction design process: designing for pleasure, designing for power, and designing for people.

Cooper’s first rule is simple and parallels much of what I have been advocating for years: “develop a precise description of our user and what he wishes to accomplish” (p. 123). Cooper reminds us that we cannot simply ask the users what they want; they are experiencing problems (cognitive friction), not solving them. We study our users and then develop profiles of the users that Cooper calls personas. Then we design software interactions that help these specific and precisely defined personas achieve their goals.

In Chapter 9: Designing for Pleasure, Cooper describes how to use personas to build a cast of characters that focuses the interaction design. He illustrates the process with an example about designing a computer system for an airplane. Technical communicators will find that personas and casts of characters are very close to the information users whom we attempt to understand as we develop usable information. In fact, I believe that technical communicators may be especially skilled in the task of persona development.

In Chapter 10: Designing for Power, Cooper moves from personas to goals, explaining what goal-directed design is about. He points out that tasks are not goals. As I have often pointed out, tasks can change as technology changes, but goals rarely change. Cooper explains that “designing from tasks instead of goals is one of the main causes of frustrating and ineffective interaction” (p. 151). If we don’t understand the users’ real goals, we won’t be able to design something that supports those goals.

Cooper succeeds at defining what good software looks like in his discussion of polite software. He argues convincingly that a lot of software is simply rude to users. In fact, software is usually pretty stupid. Polite software, as Cooper explains, is interested in and deferential to me, it is forthcoming and has common sense, it anticipates my needs. Polite software is responsive, perceptive, well informed, and stays focused on whatever I am trying to accomplish. Polite software gives instant gratification and is trustworthy.

In Chapter 11: Designing for People, Cooper moves from personas and goals to scenarios. A scenario is “a concise description of a persona using a software-based product to achieve a goal” (p. 179). The scenarios provide the context in which the user will act and also introduces to the programming community the language that users use to describe what they are trying to accomplish.

If you do the kind of interaction design that Cooper describes, you will find yourself in a minimalist world. In the best designs, we actually remove buttons and boxes and all the other leftovers produced by a focus on features and tasks. In fact, we even eliminate entire screens full of stuff that gets in the way of usability. It’s a heady process and lots of fun.

I should point out that Cooper doesn’t think highly of usability testing, focus groups, or elaborate graphical interface design. Usability testing is usually too late; focus groups ask customers to become designers; and visual design focuses us on attractiveness rather than effective interaction design. Good software is also not customer-driven. Listening to customers is good, but doing what they say they want will result in disaster.

To design great software that responds to users, Cooper points out that we need design, not just programming. That means that we need planning and we need to create design documents. Design documents answer the critical question, “What does `done’ look like?” We also need good interaction designers. Cooper suggests that good interaction designers come from many parts of a company. They include technical communicators, product managers, usability professionals, marketing managers, and even some of the programmers-people who believe in the end user and understand the goals of interaction design. He advocates building design teams that are insulated from both managers and programmers and that are responsible for building quality software.

Cooper ends by urging us to engage in changing the process. We need to model the process of excellent interaction design and ensure that programmers understand that the design is a “blueprint that must be followed,” not a suggestion. We need management backing, but we also need to convince ourselves that the process can change and that good design is not only possible, it is necessary. CIDMIconNewsletter