The Inmates Are Running the Asylum

This article appears in slightly different form in the September/October 2000 issue of IEEE Micro © 2000 IEEE.

Interaction Design

This time I look at a thin book by a certified software visionary who wants to restore sanity to the way we develop computer-based products.

The Inmates Are Running the Asylum -- Why High-Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper (Sams, Indianapolis, 1999, 278pp, ISBN 0672316498, www.samspublishing.com, $25.00)

The jacket of my copy of this book identifies Alan Cooper as the father of Visual Basic and recipient of Microsoft's "Windows Pioneer" and "Software Visionary" awards. What impresses me more than these awards, however, is Cooper's story of how he became the father of Visual Basic. 

In 1988 Cooper made a deal with Bill Gates to develop a programming language that combined Microsoft's QuickBasic with Cooper's Ruby. Cooper's prototype of Ruby had impressed Bill Gates, but after they signed the deal, Cooper threw away the prototype and started from scratch. He kept "nothing but the wisdom and experience," a decision that shocked and outraged the product manager he worked with at Microsoft. To illustrate the results of this decision, he contrasts today's Visual Basic, a highly successful product, with Microsoft Windows, which is "notoriously handicapped [by] its profuse quantities of vestigial prototype code."

This story shows the depth of Cooper's commitment to investing the time to build a solid foundation at the beginning of a project. It also gives a hint of the sometimes strident tone that makes parts of his book sound a little sophomoric. Cooper has seen and accepted a few simple basic truths, and he often shows his frustration with the programmers and project managers -- the vast majority -- who seem neither to see nor to accept those truths.

Cooper's basic thesis begins with the fact that business executives are not in control of the high-tech industry. This is not a new idea. Reading this assertion sent me back to my copy of The New Industrial State by John Kenneth Galbraith (Houghton Mifflin, 1967). When that book came out, I was designing and programming turnkey systems -- computer based systems that bundle the hardware and software necessary to implement specific applications. We designed and built systems for clinical laboratory specimen handling, data acquisition, and reporting. My boss recommended Galbraith's book because Galbraith understood how decision making in technology-based businesses was passing from the executives at the top to the teams at the bottom who do the work.  

Now, a third of a century later, Cooper believes programmers and engineers are firmly in charge. According to Cooper, this situation leads to products and processes that waste huge amounts of money, squander customer loyalty, and erode competitive advantage. This is what Cooper means when he says the inmates are running the asylum. 

Computers are hard to use, and everyday objects are becoming more like computers. Cooper begins his book by asking riddles: What do you get when you cross a computer with an airplane, a camera, an alarm clock, a car, a bank, a warship? In each case, the answer is "a computer." That is, the same opaque, unforgiving interfaces that plague computer users are displacing the much more humane interfaces that many devices once had. Cooper has made it his personal mission to reverse this trend.

In 1992 Cooper gave up programming to devote himself to making products easier to use. The first fruit of this effort is his highly regarded book, About Face: The Essentials of User Interface Design (IDG, 1995). If you have anything to do with producing software for people to use, you should read About Face. 

While the design principles in About Face are right, Cooper now believes the audience is wrong. The book starts from the premise that programmers, by default, do most user interface design. As a result, Cooper talks primarily to them, trying to help them design good interfaces. Unfortunately, however, even though programmers would like to design good interfaces, they don't have the time, and often don't have the skills to do so. Moreover, programmers face an overwhelming conflict of interest. 

Programming is hard. For as long as I can remember, competitive demands have forced programmers to push their systems and their tools beyond their limits. In order to survive, programmers must simplify the development process in every way they can. Making programs easy to use can conflict with making development easy. When programmers must choose between a hard-to-develop interface that mirrors the user's view of the task and an easy-to-develop interface that mirrors the program's inner workings, they invariably choose the latter. Programmers understand the interfaces that result, so they don't see why those interfaces confuse and frustrate users.

The facts that programmers are in control and that programmers can't design good interfaces leads Cooper to his main point: we must throw out the current development model and replace it with one that requires us to design the product before we build it.

This bald statement is a slap in the face to the multitude of software firms that have well documented product development processes. Such processes invariably start with a written document that makes the marketing case for the product or feature. The programmers then prepare, and circulate for approval, written documents that say what the proposed product does. Next they prepare detailed specifications of the product's inner workings. The programmers produce all of these documents before they write a single line of code.

Cooper points out that even when companies follow such a process to the letter, they rarely analyze user goals, and they never specify the interactions that the program must provide to satisfy those goals efficiently. Neither the marketing needs statement nor the functional specification identifies users clearly enough to enable programmers to make decisions as they go along. Instead, programmers try to put themselves into the user's shoes. But without clear mental pictures of actual users, they create target users who look and act like programmers. They create interactions that make sense only to other programmers.

Because he started his career as a programmer and because he has worked with many development teams as an outside consultant, Cooper knows what he is talking about here. He offers many insights into how current development practices lead to bad design and how the environment in most high-tech companies works to keep things as they are. He peppers his work with colorful phrases like cognitive friction, apologists vs survivors, the dancing bear syndrome, Homo Logicus, and conceptual integrity is a core competency. They mean little out of context, but they make the concepts easier to grasp and remember.

Cooper wants to create a new field, interaction design. He wants interaction designers to design user interactions before programmers get anywhere near the project. And he wants programmers to regard these designs the way they regard the target hardware -- as constraints, not as suggestions from which they can pick and choose.

Having envisioned the central role of interaction design, Cooper wanted to write a book about how to do it. He quickly saw, though, that there is a bigger problem: overcoming the huge inertia of the current system. He wrote this book, therefore, to make the business case for a product design methodology that starts from interaction design. Presumably he will write a how-to book about interaction design next. I look forward to reading it.

The business case for interaction design is simple. Cooper tells executives:

• Your products are too hard to use.
• This costs you money, because customers buy only what they absolutely need, and unhappy customers are not loyal customers.
• There is a better way to do it (here Cooper gives a glimpse of the book he hopes to write).
• You can make it happen if you take programmers off the hook for product quality and put that burden on the interaction design team.

While this is the business case book, not the how-to book, Cooper tantalizes us with interesting ideas and marvelous case studies. User profiles called personas are an important part of his methodology. He gives examples of actual products and shows how personas helped him simplify and focus the way people interact with those products.

There is a great deal of insight and good advice in this thin book. I strongly recommend it to anybody who has anything to do with designing computer-based products. If you're an executive in a high-tech firm, it can help you take control of a central part of your business. If you're a programmer, read it and take it to heart. It can help you understand and thrive in the coming design revolution.