The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity
by Alan Cooper; SAMS, a division of Macmillan, Indianapolis, Indiana, 1999, 261 + xix pages (US$ 25.00)
This is a voice-of-the-customer book that makes the subject come alive. Although focused on software, Cooper makes it abundantly clear in the first half of the book why products—software or not—don’t get designed to suit users. In the second half he offers solutions that can be adapted to fit products well beyond software. The lessons apply to any product that has a user interface, independent of any software or electrical content. It would be of less value for products that are not designed for users, for example military development where one designs to the letter of a government contract, or products of a third-tier OEM supplier, such as microchips, where the user is unaware of the product’s existence. Inmates is aimed at product developers and their managers, as it is the managers who hold the keys to the asylum.
More broadly, the book’s first half would be enlightening to anyone who has ever been frustrated in using Windows, a modern television or telephone, or a computerized library catalog. I take many product development books into restaurants to read while I dine; this is the first one that repeatedly elicited interest from the servers.
In short, Cooper’s point is that products—especially high-tech ones—overwhelm and belittle users, because the products’ developers live in a different world, totally out of touch with the user’s situation. He not only illustrates this with numerous examples, but also digs into the life of a typical Silicon Valley programmer (Cooper lives in Silicon Valley) to show what their world looks like and why it is so far from that of a typical user. His examples of user-unfriendly products seem to go on and on. I was wondering if any positive examples of well-designed software even existed until some showed up relatively late in the book. His examples of needlessly difficult-to-use products span the gamut from airline navigation systems to a simple two-button automobile entry system. Cooper loves his electronic gadgets, but he is equally sensitive to their shortcomings. For instance, he has owned several VCRs over a twenty-year span. After explicitly trying to buy one at any price that was simple to operate, his success rate in recording delayed broadcasts remains at just 40 percent. All of the features added to VCRs by developers over twenty years haven’t made this machine one bit easier to use!
This book causes one to think more deeply about the friendliness of the products we encounter every day. For example, if I go to the ATM at my local (Portland, Oregon) bank, I find it slow and frustrating. However, if I fly halfway around the world, instead of the communication delay I expect due to the distance and language barriers, I am delighted to find that I can withdraw cash from the ATM in the main hall of the Singapore airport in half the time, with fewer than half the keystrokes, and with a much greater sense of dignity than right at my home bank. My USBank ATM always asks me if I prefer Español, even though I always opt for English; it keeps asking me if I want a receipt, ignoring my track record of always answering yes; and it continually asks me if I want to withdraw from checking or savings, when I don’t even have a savings account. Once I hit the savings key by mistake. I received a stem warning that I had screwed up, not that USBank had made a mistake in offering me that option.
Although this is a book about what is normally called “user interface design”—and Cooper’s last book was subtitled The Essentials of User Interface Design—he now prefers to call it “interaction design.” Interface implies that there is a clean break between the inside and the outside of the product, and one can slap an interface on the surface after the core is finished. Such interfaces are invariably poor ones, because genuine usability must be supported by certain features in the core, and these are unlikely to be there unless the user is designed into the core first. Going back to the ATM example in the last paragraph, for the machine to know that I always want a receipt and speak English the core software would have to track my behavior, a fundamental change in the core’s design.
Note that this outside-in design implies a reversal in the normal steps of designing a product. Rather than starting with the core and working outward, one must instead start with the user and design inward. This is the organizational obstacle in Cooper’s approach, as it puts the user in the driver’s seat and takes the customary power away from the programmers to specify the core’s design first. In the words of the book’s title, the inmates will no longer be running the asylum.
Cooper introduces several tools for user-centered design. For me, the most powerful of these is personas. A persona is a description of a user, including a name, a portrait, and illumination of certain idiosyncrasies that render this individual real to the developers. Personas are not just fictional write-ups but instead are built carefully from thorough market research to represent key users according to a product strategy.
For instance, in designing an airline in-flight entertainment system (pp. 138—148), the central persona was Clevis McCloud, a crotchety 65-year-old Texan with a touch of arthritis who had never used a computer. The team was to build the system for Clevis. To ensure that the resulting design didn’t offend others, the team also built three secondary passenger personas, each being an archetype of an identified group:
- Ethan Scott, a 9-year-old whose sole interest is playing games on the screen from takeoff to touchdown
- Chuck Burgermeister, a high-mileage business traveler who is familiar with technology and has little tolerance for cumbersome interfaces
- Marie Dubois, for whom English was a second language; she wants to browse the shopping and entertainment channels.
Personas on the airline side included Amanda Hopper, the flight attendant who has to keep the system running and the passengers happy throughout the trip, and Mel “Hoppy” Hopper, the mechanic who has to troubleshoot and fix the system during the short time that the plane is on the ground.
Note that the persona approach is quite different from the normal one in which a system is built from a list of features driven by competitive offerings. For example, the VCR mentioned above has features galore, but it frustrates nearly everyone who uses it. In contrast, designing for personas concentrates on delighting core users while not annoying others, totally ignoring features unless they fit into this picture.
Cooper provides valuable insights on why products are not developed for appropriate users. Marketers, he suggests, in their quest to satisfy everyone, implicitly design products for beginners. On the other hand, programmers are trained to deal with edge cases—those possible but highly unusual situations that, if not resolved in the code, will cause your computer to crash when you press an inappropriate key. When programmers constantly think in terms of edge cases, they naturally design for expert users. Clearly, this sets up conflict between the marketers and the programmers. More importantly, he observes, both are misguided. Most of us users have advanced beyond the beginner stage but don’t use the product regularly enough or with enough variety to ever become experts: we are perpetual intermediates (pp. 182—185).
I didn’t find many negatives in Inmates. Mr. Cooper is passionate about poorly designed products and what can be done to improve user interaction, so he sometimes sounds strident. Although Inmates is short, for a computer book, it nevertheless reads a bit like a computer book. For instance, chapter titles such as Computer Obliteracy, Cognitive Friction, The Dancing Bear, and Homo Logicus are clever but not very helpful until you have become initiated by reading the book. (Perhaps Cooper forgot to construct a reader persona!)
You may have observed that, following Cooper’s usage, I have consistently referred to users rather than customers. Product developers love to debate who the customer/user really is. We once had a client that developed food packaging used in supermarket bakeries. To them, the customer was clearly the manager of that bakery department. They designed products that displayed the food attractively, were easy to fill but tamper-resistant, and were stackable. To me—the end user—these same products were a nightmare to open, were un-reusable after opening, and created a substantial disposal problem. It only gets more complex when one moves from consumer to industrial products.
Cooper concentrates on the end user. His rationale is clear: It is the end user who will have to live with the product day-in and day-out over its life. If you make this person happy, others back through the distribution chain will eventually be happy too.
Preston G. Smith, CMC
New Product Dynamics
(Reviewed in the Journal of Product Innovation Management, January 2001, pp. 59-61.)
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.