The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity Reviews

• A very dangerous guide for any organization

  
  By on 2004-02-18
  I work for a large computer company that makes software. This book was instrumental in creating and organizing our human interface engineering department.

  I don't think you can put a price tag on the amount of damage this book and the attitude it promotes has cost us.

  On the one hand, the examples presented are insightful and on target; on the other hand, Mr. Cooper is a usability consultant, and his goal is to convince you that you need a usability consultant. My company drank the kool-aid, and has even paid for training services based on his work.

  Part of convincing you that you need a usability consultant is convincing you that your programmers will be congenitally incapable of doing good UI without one.

  Now, of course, human interface engineering departments eat that up, since it justifies their existence. Human interface engineering departments are a Good Thing. Having two teams (which must collaborate on producing a product that the market will want) at each others throats, waging political wars and each casually making the assumption that the other is incompetent does not lead to an effective organization. But it is the organization that Mr. Cooper's advice can easily lead to.

  I can say categorically that our product's user interface is *worse*, not better, as a result of the attitudes Mr. Cooper promotes - not due to inattention, but due to the fact that in many cases were everyone agreed improvement was needed, the mutual animosity between the HIE department and the Development department was so great that the decision ended in a stalemate and nothing was done. We are only now pulling away from that era.

  Read it warily, if you are thinking about how to set up your organization, and remember that it is written with an agenda that may not be set up to benefit you.
  
  

• Extremely poor

  
  By AHWT9C2H8SK46 on 2001-06-21
  I have been passionately interested in usability issues and ways to improve them for a quarter century. I read all that I can on the subject to gain insight into how to make things better. This book, however, fails miserably.

  It is about 50% personal exorcism, projected onto others, of his own former self. It is about 50% advertisement for the kind of consultant he now stylizes himself as. It is 100% the kind of book on usability you would expect the "Father of Visual Basic" to produce.

  There is some good information in this book, which would normally merit a rating of two or three stars. However, by its polemical tone, it diverts attention away from really good books by such authors as Donald Norman and Jef Raskin, and, for that matter, Cooper's own _About Face_, which is quite good.

  If you hate unusable products and are looking for nice, easy scapegoats to be angry about, this will be an enjoyable read. If, however, you are interested in the actual reasons that products are poorly usable or are interested in how to improve the world, this book is worse than useless.

  One histrionic account describes how he cannot buy a VCR that lets him record shows by setting time with a knob. This would be excusable except for the fact that, the year this book was published, a remote control was being sold that did exactly that, and it recieved saturation advertising on television. The problem is that nobody bought it. Demand was so poor that it isn't made any more, and no sales staff I have spoken with has remembered anyone ever asking for such a device.

  Yes, there are reasons that devices are not very usable, but in order to understand them one has to look beyond the simple, adversarial, supply-side approach that Cooper and the majority of usability gurus seem to be stuck in. Unfortunately, the field has become so dominated by this kind of ressentiment thinking, that it is unlikely that the real issues can even be published, let alone addressed.

  Failing that, however, there are still books that can inspire or help build a more usable world. _Asylum_ is simply not one of them, that's all.
  
  

• Great content, but leave the ego behind!

  
  By A1U441Q60DRZKR on 2002-04-01
  Had I written this review after the first 125 pages of the book, I would have easily given it five stars. Alan Cooper is well spoken, well written, and he has the knowledge, the innovation, and the experience to enlighten and entertain.

  Alan's interaction design philosophy makes a lot of sense. I've since redesigned a system that had just left the design phase, so I could follow the guidelines in this book. And they helped a great deal--I'm much more comfortable with the product.

  The book fell apart in the last 100 pages, however. 100 pages of text could have easily been condensed to 20, and the pages there were fueled by ego and a business agenda. Who can blame him? "Let he who is without sin. . ." Too much anecdotal evidence of past consulting assignments where the clients were unenlightened, arrogant, simple, pompous, blah, blah. We've all had those experiences, but the book was used as Alan's last word, in a classic passive aggressive maneuver that he admonishes in his very text. I suspect that this book is given to prospective clients to help break down sales barriers.

  That being said--read the book! I have a new design technique, and a head full of fantastic sound bites I can spit out at will. Definitely worth the price of admission.
  
  

• Great design approach, but arrogance and repitition hurt

  
  By A1XAR9ESZ5Q6CV on 2004-01-31
  It's worth reading this book -- even despite the painful tone he often takes -- just to pick up on the ideas of creating concrete personas and how you use them to develop your product. We do that today at Microsoft (at least in Developer Tools), and it's a highly successful way of not only building a good product, but also in helping hundreds of developers understand why a feature is 'in' or 'out', no matter how much they might like it personally.

  It's also mentioned quickly, but the idea of how much work customers are willing to do for an amount of benefit can affect your designs for the better as well. Fundamentally, you should add value with no documentation and no setup -- if somebody paid money, they should feel rewarded as soon as they start to use your application. Then, after they want to do new things, you can require more work of them to do it. However, it should never be more work than the benefit that they derive! This is an important lesson that, say, most media player application writers would be advised to learn...

  Of course, as many other reviewers have pointed out, it might have been nice if he had created some personas for who his readers were. I doubt that any of them would have had a goal of being preached to.
  
  

• Great Ideas, Not Always Well Presented

  
  By A2CDWCWJF201R7 on 2000-07-03
  The culture of software development is changing, but grudgingly. The short-sighted notion "It's better to be first with something bad than second with something perfect" has been discredited after too long a reign as the New Paradigm of the Information Age ("It's brilliant because it's counter-intuitive!"), and instead has been exposed for what it is: bad business and a lousy way to treat customers. Alan Cooper's book helps make sense of things as software developers, after decades of coding for each other, are forced to begin acknowledging the cold and strange outside world of Real Life Users.

  Cooper's writing is generally clear and easy to follow. He documents his points well and uses numerous true-to-life examples to illustrate the concepts. The ATM analysis, for example, is both effective and memorabl: Why DOES the ATM list account types you don't have, permitting an invalid selection? Why can't you return to a previous screen to correct mistakes, instead of starting over from scratch? Why doesn't the system give you an error message that helps you understand the problem, rather than "Unable to complete transaction"? No one even bothers to ask these questions, Cooper points out, because we've accepted the default structure of ATM screens--which were created for the convenience of coders and system engineers, rather than users.

  Cooper also performs a valuable service in demolishing that old standby programmers' excuse: "We don't call any of the shots-it's all management's fault!" Bull. Half the managers in the computer industry are former coders themselves (and laboring under an outmoded and faulty mental model of how software development must occur, by the way). The other half are so non-technical that they're at the mercy of the coders, who are free to decide which features are most important, which will take too long, and ultimately, which will or won't make the cut for the next release. Coders ARE driving this bus, if occasionally from the back seat, and they need to take responsibility for what they produce-and be humble enough to admit that an indispensable part of the development process (interface/interaction design) is beyond their abilities.

  That said, Cooper's writing style itself is less than perfect. He presents many compelling case histories, but at times he seems to lean too heavily on insider stories, as if showing off his contacts and expertise in the industry. And, of course, Cooper is far too much in love with his "dancing bear" metaphor; long before you've reached the halfway point, you'll be muttering, "One page...just ONE page without a `dancing bearware' reference, PLEASE! That's all I ask!"

  But the messages and lessons in this book are too important to ignore. As Cooper tries to remind us, it is everyday users-not the power users, not even the "computer literate"-who are the core audience. They're the ones you have to design for: a successful interaction design, rather than a burgeoning list of clever features, is what will determine your product's success or failure.
  
  

• Useful ideas but infuriatingly arrogant
  By A3J8QBBRL46I3G on 2000-07-15
  The Inmates are Running the Asylum makes the business case for interaction designers playing a central role in the development of technology products. It starts by providing examples of technology that is difficult, frustrating, humiliating, and even dangerous to use. Cooper argues that, although people have gotten used to being humiliated by technology, it doesn't have to be this way. His claim is that most technology, especially software, is designed by engineers who think differently than non-technical people: they enjoy being challenged by difficult problems and they are trained to think in terms of "edge cases" rather than on the common case. Thus when engineers design software, they tend to create products with far too many neat features that clutter the interface and make it difficult to do the simpler tasks. In the second part of the book, Cooper describes an approach that he and his design firm uses to simplify products and keep them focused on the users' needs, eliminating or hiding more complex features that few people use. He gives some specific and compelling examples of how they took a different approach to an interesting design problem and keep the product simple while still being powerful. He makes the case that you can grab a market with powerful, feature-rich, complex software that is frustrating to use, but you don't build customer loyalty that way; as soon as a well-designed version of that product comes along, your customers will defect. If you delight the user with your products, on the other hand, you will engender deep loyalty that will help see you through some poor business decisions. His primary example of this is the fanatical loyalty that Apple garners from its users, compared with the rage that Windows users feel toward Microsoft. Apple has weathered some horrendous business decisions and still survives, whereas Microsoft users are more than happy to defect when a better product comes along, and in fact revel in the defection.

  I also don't think he makes it clear enough that he's not proposing doing *fewer* features to make products simpler and easier to use, he's talking about doing *different* features. For example, he argues that software should not be so lazy; it should stop making the user do work that the computer is better suited to doing (e.g. remembering where they put files), and it should stop making users go through the same steps over and over again, as if it were the first time they had ever met this user. He argues that "Do you really mean it?" popups are evil (and I couldn't agree more - as most of my coworkers know), and instead it should be easy to undo anything, so it's not so catastrophic to do something you didn't meant to do. I agree with all that, but of course building a reasonable "undo" mechanism is a very complex feature. To cure the "How could you possibly want to quit my ever-so-important application?" popup syndrome, it would be much better to make the software very fast to start up, and to have it come back in exactly the state you left it in, so that quitting when you didn't mean to is not a problem. All of this is well worth doing, but it is lots of engineering work; it's another feature. I'm all for shifting engineer resources to these features instead of the "but somebody *might* want to do this obscure thing" features, but it should be clear that this is not doing fewer features, it's doing different ones, ones that help smooth the user's interaction with the software. Cooper seems to imply that engineers are so lazy that they don't want to do these features, but most engineers work very hard and care about their product. The key is to make it clear why doing this feature right will make such a big difference to the product. My experience has been that the more you understand the work involved in doing a feature, the better you can work with engineers. Not only can you better trade off engineering effort for user benefit, but engineers respect you for understanding what you're asking.

  Having said all that, I can't deny that I finished this book with some very specific ideas about improving my own designs, and a renewed sense of the importance of what I do. I just wish Cooper could have articulated the case without putting interaction designers "on a throne."
  
  

• Important book, though Cooper's not as smart as he thinks
  By A2MPKE7P1DFYTK on 2001-07-30
  The central thesis of this book is that software should be designed for the user's ease first and the programmer's ease second. Cooper's points are generally excellent, although I fear that the vast majority of ears his message falls on are irredeemably deaf; most programmers care not a whit for the hapless users of their software.

  If anything, this book doesn't go far enough. The fact that Cooper is the creator of Microsoft Visual BASIC - a tool that encourages the creation of the worst kind of sloppy, ill-thought-out, user-hostile software - ought to tell you something about his position in the field of human-computer interaction. It's sad but true that just about anyone studying HCI is inherently radical (since most technical people want nothing to do with the end user) but Cooper is as conservative as they come within that spectrum. Despite the provocative title, he seems to view the changes that must be made for computers to be truly usable by the average human as evolutionary ones, not revolutionary ones.

  The best example of Cooper's conservatism is, I think, his skepticism about the usability of hierarchical filesystems. Cooper says that systems of nested directories or folders are, for non-programmers, one of the most confusing features of modern computers; he gives a couple of anecdotal examples in which average users save files, then lose them forever. While this seems to be a revolutionary attack on a cornerstone of modern OS design, it really isn't.

  While Cooper is correct in citing the presentation of a hierarchical filesystem to the application user as an example of interface-design-ignorant programmers allowing implementation structure to dictate interface structure (a policy which he rightly decries), such presentation is not a good example of what not to do: there is nothing intrinsically wrong with a hierarchical filesystem from many, perhaps most, users' point of view. Anecdotal evidence is not proof, but I know many non-techies who understand (and, more important, take advantage of) the Windows filesystem. Hierarchies of categories within categories are in fact all around us, because an appreciation and understanding of them is (I believe) hardwired into the human brain. Consider the Library of Congress card catalog system, or the Linnaean taxonomy of life.

  There are two things wrong with the hierarchical filesystem of Windows and the MacOS from the user's point of view (neither being its sheer existence). First, its structure is obscure. Both Windows and the MacOS, in the standard dialog boxes that they present when the user is saving a file, show only the files in the current directory, with no context. Both OSs will display on demand an abbreviated tree showing the structure above the current directory, but this option is hidden in a non-obvious popup menu; and even if it were more obvious, the display would not be very helpful, because it doesn't show the tree structure of the entire filesystem - just the parents, grandparents, and so on of the current directory. If not just the local context, but a more general context (the entire filesystem) were displayed at all times when the user was trying to choose a directory, the first problem with computer filesystems would be solved.

  The second problem with the Windows and MacOS filesystems is that they mix user documents and everything else together. Microsoft tried (in its usual half-baked way) to address this issue by creating the "My Documents" folder in Windows 95. But *documents* shouldn't be segregated into a single folder. *Applications, system files, and related data should be* - or ideally, they should be in some sense *not there at all*, from the user's point of view. Most users don't know or care that executables, libraries, configuration files, and the like are stored in the same way on the disk as their own documents. In fact, they don't care about applications at all - *only* about documents.

  The original GUI model developed at Xerox PARC (by which Windows and the MacOS were inspired) was a document-centric one, involving no explicit applications. Document-centric computing has never taken off for two reasons - because it's different, and because nobody's figured out how to make money from it. (How will we sell applications if there are no applications? goes the conventional wisdom.) Yet, sadly, there is no mention at all of this fundamentally superior HCI paradigm in The Inmates Are Running the Asylum. In his fundamental conservatism, Alan Cooper is way behind some of his cohort, like Donald Norman (author of The Design of Everyday Things), or Jef Raskin (the least technical, and thus most important, member of the original Macintosh design team) - both of whom have come out strongly in favor of document-centric computing.
  
  

• You will like this book if you hate the world around you
  By A3TFUWBY8E7UBN on 2003-10-11
  This book actually starts out nicely up until the point where it turns into a high-pitched whine about everything that the author hates. The content is highly subjective, full of cliches such as "what do you get when you cross a computer and an alarm clock" or constant reptitious nags about why engineers are incompetent when it comes to things that matter. It is laughable to think that an engineer-turn-interaction-designer would come to hate so much what he used to be. On the positive side, the book can be considered a slight improvement from some of the things we had seen from this author in the past (Visual Basic being one i.e. a programming language for minimalists -- almost never used for serious projects in the software industry and to most people utterly useless)

  Just as the arugument used in the book to say that bad user interaction design stems from letting the engineers (or according to the book's confusing terminology "apologists" or non-solution-oriented people) control dedcision making processes, the same can be said of the overly simplistic often vague interpretations of the world given by the people highly praised in the book (referred to as "survivors"). As can be seen from the first few chapters in the book, the book speculates about things and provides no real facts or knowledge. Perhaps some research notes or real life cases would help.

  I would suggest looking for a more authorative source of what constitutes a good user design if you are looking to learn more on this subject. Find an author with more academic and industry backing.
  
  

• What a waste
  By A2L61S1I0TXMVB on 2000-10-12
  The book has a fantastic title and that's where it stops. Alan Cooper takes an entire book to tell us that software needs to be designed - a shock from someone who created a language that allows programmers to avoid design altogether, Visual Basic. He spends half the book knocking software engineers and the other half plugging his own company. Sprinkled in between are a few good ideas, but by the time you get around the author's arrogant style you no longer enjoy the insights he may offer.

  It's a pity that a book with such a great title is wasted on uninteresting and repetitious dreariness. It really goes to show that you can't judge a book by its cover.
  
  

• Blame it on Cognitive Friction
  By A3PDH70625KHBX on 2000-03-27
  Alan Cooper makes the case for goal-directed interactive software design in his provocative book, The Inmates are Running the Asylum. He argues that though it would seem common sense, few software-based computer products are designed with the end-user in mind prior to their construction. Instead, they are all too often feature-laden "dancing bearware" that may impress the inexperienced, but infuriate them as well. Cooper suggests that software engineers are to blame for this phenomenon, identifies several examples of ill-conceived software engineering, and offers design specifications to ameliorate the problem.

  The real culprits in Cooper's book are the programmers and engineers who design products to work their way as opposed to the best way. Cooper argues that the approach that companies take in creating technological products is backward. They do not consider what customers want first. Rather, they consider what programmers can produce (what's capable) and what business people can sell (what's viable), rather than what customers want and need (what's desirable).

  Examples abound throughout the book illustrating the frustrating results of such backward engineering. These vary from the tragic to the mundane. The first page of the book details a fatal plane crash which could have been prevented had the pilot's computer been programmed to account for human error in navigational commands. Later in the book, Cooper proposes simplified VCR design that would eliminate universal frustration with programming one's VCR, not to mention eliminate the ubiquitous flashing 12:00!

  Clearly airplane accidents, if not VCR ineffectuality, concern most people. How can computer manufacturers design the most desirable products to avoid such public danger or distress? Cooper outlines specifications that require goal-directed design and end-user orientation. Software engineers typically design programs to accomplish tasks, e.g. the aforementioned navigational computer was programmed to direct the plane where the pilot commanded it. That was its task.

  Unfortunately, the pilot commanded it to fly into a granite mountain. Had the computer been goal-directed designed, i.e. programmed to direct the plane where the pilot commands it, given that such directions do not result in a collision, tragedy would have been avoided. The latter case illustrates end-user orientation, for it allows for pilot fatigue, emotion, latitudinal unfamiliarity, or oversight, any of which may occur on a given flight.

  Cooper's call for goal-directed design and end-user orientation of software-based computer products is compelling and seemingly common sense. Overall the book is well written and includes memorable examples and convincing arguments. One less cogent claim, however, is Cooper's suggestion that technology apologists will play an important part in affecting change toward goal-directed interactive software design. I assert that change must come from within the programming and engineering ranks. Apologists, by definition, are not cohesive or likely to take a stand against that which they're apologizing for. This is like asking an enabler to seek help for an alcoholic. It is not going to happen. The software engineers must lay down their addiction to bells and whistles, tasks and tortuous interfaces, and see through the eyes of the end-user: you, me, and the other 98% of the world with flashing 12:00s on our VCRs.
  
  

• Change the world! But I'm not going to tell you how.
  By on 2002-09-28
  I found this book to be an excellent review of design problems but it left me asking HOW HOW HOW? The author would tell me what NOT to do, but then shy away from telling me what TO do. He would outline a problem very eloquently, but then not tell me exactly how to solve it. "We must design for the users!" Um... yeah. HOW?

  If you have no clue about the problems that Interaction Designers face, read this book. If you are already an Interaction Designer, don't bother. I really hope there's a sequel in the works entitled "The Interaction Designers are Running the Design Process: How To Solve Your Design Problems" with lots of concrete examples and positive, rather than negative, design rules. Frustrating.
  
  

• Where is the reality check?
  By A22WETZXI2ZTSZ on 2000-02-24
  Good read, just be cautious of the one sided slant to this book!

  According to this book, the inmates are everywhere and as is the main premise of this book, they are in charge of not only shaping the asylum known as software design, but also our world. Cooper uses various anecdotal examples throughout the book to illustrate his ideas and views on technological design. Focusing entirely on how it has run amuck. Many of the examples are painfully obvious and basic.

  While points are well made and key to adding to ones thought process about designing software and better ways to bring product to market. Cooper misses the boat with regards to some of the realities of business. I found Cooper's ideas a little too idealistic with little suggestion in terms of comprimise or strategic change.

  Methodology also seems to be off as book is all general impression based on observation and personal experience.

  Finally, If you are looking for a reminder about good common sense and a prompt on how to make your customer king, you'll find this a helpful read.
  
  

• Better treatments exist elsewhere
  By on 1999-09-29
  Cooper's book is old news. Check out Don Norman's Psychology of Everday Things for a more general, and more original treatment. The topic of user-centered design has been floating around in the area of human factors psychology for years, with many successful applications. Simply put, there isn't much new in this book.

  And the assertion that engineers lie at the root of the problem is naive. The true problem in devising usable systems that are also commercially viable and are delivered on time and within budget lies in a team approach, with users, developers, engineers, marketers, - ALL STAKEHOLDERS - involved in the process.
  
  

• Great fiction
  By AMRQMB7WMZEX3 on 2004-10-05
  In one of the opening sentences, Cooper uses Albert Einstein's quote "You can't solve a problem with the same thinking that created it" as a supporting claim for why it would be desirable for the tech industry to adopt his goal-directed design method. The method relies on visualizing hypothetical, but very specific users (like Joe Black who works at McDonald, likes his coffee black, wears black underwear and cannot stand the sound of the cash register in the morning) and thinking in terms of how these "personas" would accomplish their goals with the application you are designing. Having worked in the industry for many years, I can sort of see how this method can supplement some of the more rigorous design methodologies that you'd see in companies today, but contrary to the hype, I don't think it will shift your development into high gear or make any significant impact on your production. For one, the main design problem he is solving seems to merely exists in his book (which incidentally makes the Albert Einstein quote more relevant).
  
  Slightly exaggerated, the book almost reads like this: "There exists badly written software in the world... engineers are to blame...don't trust marketing... random fictitious thoughts ... use goal-directed design method because it will save you money..." I doubt that any competent manager would ever consider investing into a design methodology that is guaranteed to cause hostility between engineering, marketing and interaction design team.
  
  The simple language and somewhat unique humor definitely make this book an easy read (passes the cognitive friction test -- shouldn't take you more than few hours to go through) but be cautious of the parts where Cooper attempts to make universally true points. One of the many things that threw me off was the part where he suggests that the designer should abandon his sense of logic. For example, page 68, "It is all so logical, yet it is all so wrong", Cooper tries to explain that illogical approach yields the right design in some cases. These types of statements make it somewhat hard to follow the reasoning in the book. Another worrisome thing is the number of inconsistencies throughout the book. For example, in one part he advocates the idea that humans generally don't make decisions in the same way that computers do as a way of arguing that software should respect the user's decision and therefore not prompt him with a confirmation dialog (huh?). In other part of the book, he complains about a system that didn't warn a user. Similarly, in one instance, he argues that "specificity" of personas (imaginary characters) is the active ingredient without which the value is lost. On the other hand when he talks about a case study where they had to create personas he says "Each of the four passenger personas was an archetype in its own way, representing a broad segment of users."
  
  Shortly after you get into the book, you realize that Cooper is simply following his own formula to sell his gumbo. He clearly identified a very specific persona as the audience (wouldn't be surprised if he called him Alan, -- oh.. but it's forbidden to use "real" people when creating personas.. see chapter 9). Using his model, all we'd need is a single imaginary person who has the need and desirability for the book. Having found this person, the viability or the product is almost given. (I can't believe the humans have been so mindless not to think of this before!)
  
  The only way to save money from this book is by not buying it.
  
  
  
• You're either part of the problem or part of the solution
  By AVB1BHAHK1YH0 on 2003-12-24
  Cooper gets it. He understands that computers and electronics are designed by engineeers, for engineers. But what if you want to design something for the masses? Not just something they will use, but something they will enjoy?

  Cooper has the idea. If you want to design for "normal" people, you need to put yourself in their shoes. In this bible of high-tech product design, Cooper gives you tools that helps you design products for your target customers. This isn't just a bunch of recipes for GUIs and wizards, but a way to think about how people actually use your tools.

  I know Cooper's techniques work. I have adopted them across my software development team, and the difference is astounding. Bottom line: If you're involved in high-tech development, design, or marketing, you need this book.
  
  

• The Inmates Are Running The Asylum : A Review
  By A1AWHWWHI3LZHI on 2000-03-05
  Alan Cooper, author, is a veteran software designer. He is focusing his current practice in an area he calls "interaction design". His book, "The Inmates Are Running the Asylum", describes his belief in the need for the inclusion of "interaction design" in the software development process. Cooper campaigns for interaction design to be adopted by software development companies as a way of creating customer satisfaction in software based products.

  This book is presented in five parts. Parts I and II, "Computer Obliteracy" and "It costs You Big Time" describe the difficulties encountered by the average consumer when using software driven devices. Several creative terms are introduced that are developed throughout the book. These terms include "cognitive friction", "apologists", and "survivors". Part III, "Eating Soup With a Fork", describes the current process of software development. Cooper characterizes most software companies as having hierarchical structure and control. Despite company architecture, Cooper alleges that these companies are ultimately controlled by programmers who code the software. Hence the title, "The Inmates (programmers) Are Running The Asylum". Part IV, "Interaction Design Is Good Business", describes "interaction design". This rather new discipline is put forth by Cooper as the way to save the U.S. software industry dominance. Later in Part V, "Getting Back Into The Driver's Seat", the role of the interaction designer is more fully described throughout the stages of the software development process.

  Cooper acknowledges that incorporating "interaction design" in the software development process will necessitate significant changes in the software companies. "Interaction design" inserts a design phase at the beginning of the development process long before programmers begin their coding. The design team works with all of the stakeholders who are involved in the project. Stakeholders include marketing, consumers, programmers, and executives. The designer takes the ultimate responsibility for the quality of the projects and acts as a "go between" among the stakeholder groups. The design team is given credibility and decision-making authority by the corporate executives. Success using this process is enhanced when all stakeholders have a common vision for the project. The corporate culture is changed when interaction designers are given responsibility for everything that comes in contact with the consumer. Cooper validates his beliefs by showing how "interaction design" as a part of the process of creating software will save a company time and money while developing products that will be friendly to the consumers.

  As a novice in the area of software design, I enjoyed hearing an insiders point of view of this specialized business. The interaction designer is presented as the consumers voice in a process of product development. I agree with Cooper that this voice is needed since most products that we use have digital coding somehow embedded in their operation.
  
  

• Worth the time and money
  By A2YHXVJ3LIGBFL on 1999-05-03
  Cooper has done a good job of pointing out common problems in software design. The book is well written, with interesting examples and anecdotes to illustrate the author's points. While most of the book focuses on "off the shelf" products, I think the author's arguments are even more relevant to custom software development. If you already believe that software is poorly designed, this book is unlikely to be a revalation to you. It will, however, give you some ammunition to use in discussions with "apologists".

  I agree with the earlier reviewer, who said that the people most needing to read it probably won't. This would seem to be a great book for development managers and purchasers of software, but I think the only people likely to read the whole thing are professional developers.

  I have two criticisms of the book (for which I give it 4 out of 5 stars): too often it comes across as an advertisement for the author's company; and I would have appreciated more "how-to" information. To this latter point, the author himself says in his preface that he had intended to write a "how-to" book, but was talked into writing a "business case" book instead. I hope that he will soon follow up this effort with the planned "how-to" book.

  A final question -- what is with these 1 star reviews? I've read a few of them now, for different books, and I have to question whether the reviewer has even read the book. If so, they seem to have completely missed the point. At the very least, if giving a 1 star review, please provide some detailed criticisms so I can decide whether I am likely to share your opinion.
  
  

• Mostly a rant
  By A2M45VVKR334F on 2002-07-09
  From the first page this book shows itself to be the product of a lot of anger and not much thought or fact. The example of the American Airlines crash is glib and incorrect - 'pilot error' has not been given as a reason for a crash in many years. Similar problems occur thoughout the book - developers are lying when they say that something is technically difficult, using a knob rather than buttons is the answer to everything, design without regard to cost is the only way to do it. There are some ideas there but anything by Donald Norman is better. Like Clifford Stoll in "High tech Heretic" the author mistakes opinion for fact, and generalises with abandon. Yes, products are often poorly designed but all products are designed within constraints and ignoring them does not negate them.
  
  
• Groundbreaking, paradigm shifting book
  By A2HF1LHFH66L0K on 2005-10-04
  Every once in a while you'll read a book or part of a book that completely shifts your thinking. This is one of those books. Alan Cooper (father of Visual Basic) presents for us a litany of horrific examples of interface design, and lays out the case for why spending time and money up front on usability and interaction design will produce the greatest returns of all the steps in software development. But the paradigm shift occurs in Chapters 9 and 10, "Designing for Pleasure", "Designing for Power", where Cooper hits home the power of the user-centered design process and illustrates the inherent mistakes which almost all software developers make during development. Here's a hint: if you start with requirements specifications, you're already screwed.
  
  
• this book changed my life
  By ATZAG6VL7DKDS on 2007-02-21
  I was a well-paid systems administrator/help desk guy until I read this book. This book really did inspire me to change careers!
  
  The book basically outlines why engineers (and people who think like engineers) are INCAPABLE of designing effective interfaces. It delves into specifics and supplies some great examples.
  
  I am amused by some of the reviewers here who display the same sort of arrogant contempt that the book outlines. OF COURSE programming a VCR is easy for YOU--you're a person with an "engineer mind". My mom can't program a VCR at all, and that's not because she didn't try hard enough or read the instructions. She can't use it because everything about it's interface is counter-intuitive to someone who does not understand machine/code logic.
  
  Just because it's easy for you doesn't mean it doesn't stink. Just because it makes sense to you doesn't mean it can't be made better--to work intuitively for "regular" people. Buy this book. Read it. Demand more from your products. It's time to end the insanity.
  
  
• Lot's of folks in high-tech need to take this book to heart.
  By ATI8VRJBGOMFW on 1999-12-13
  After reading this book, my eyes have been opened to a different perspective.

  This book is an excellent Business Case for why design is important with high-tech products. Too often, the importance of design is ignored. Despite what some seem to think, this industry is not a playground for boys with toys. Unless you work in research, your purpose is not to play with the latest cool technology. Your purpose is to facilitate the operation of the business. Period!

  This is a business. Our goal in business is to make money, and hopefully improve some part of our lives in the process. We do this by shipping good products. Mr. Cooper's ideas benefit anyone with these goals. Anyone who does not see this has their head in the sand. You are the apologists that he speaks of in his book. The truth hurts. Sorry...

  My advice: Read this book with an open mind. Take the ideas that are good and apply them to your own career. Our industry will be better for it.
  
  

• An eye-opener on how to develop usable software
  By AL86NUDC1VFZD on 1999-11-18
  While he may be a bit redundant at times (actually, people retain information when it's repeated to them so it may not be all that bad) and it may appear to "blame" the programmers, I think this book is an eye-opener and should be required reading for everybody involved in the software development process. I just wish that there were more interaction designers available.

  I'm the CTO of a small software company, and we're going to use interaction design principles in the next versions of products that we develop - because we do want to deliver not only power but pleasure to our customers!
  
  

• Paging Doctor Software
  By A41PZ0A81QTQG on 1999-12-17
  One mouse click to order a book from Amazon, but three mouse clicks to attach a return receipt to an Outlook email! Why has coming to work and firing up the PC ended up for so many people like wearing one of those hospital gowns that refuses to close? It's nice to find a Silicon Valley insider who is willing to acknowledge that there's something gravely wrong here in the patient service department -- and provide a vision of the solution.

  This is a book that should be absolutely mandatory for every MIS/IT staffer who has to hold down a help desk, train a new user, design a web page, or otherwise hand out the tools to plain folks who just want to get their work done out on the shop floor (whether that floor is in a hospital, a law firm, a government office, or wherever). Those of us at the other end of the cable, meanwhile, will find it a comfort to know that we aren't witless curmudgeons of the Selectric age whose time has come and gone.

  Cooper has it right: if our cars worked like this, we'd all be riding bikes. The book crosses the line from general interest to inside interest somewhere beyond the halfway point, and the illustrations are discomfortingly precious, but this book gives the hapless user a vocabulary for commuting his/her frustrations, while telling the techie something about his/her client that might not have been covered in the computer science curriculum.

  Dozens if not hundreds of books have been written and movies made about doctors' inability to relate to their patients. This is the one the computer "doctors" should be reading before they get their licenses to practice, and the "patients" should be reading to keep their sanity. Bravo!
  
  

• Escaped Inmate Reviews the System
  By A317FL7LR8B024 on 2000-01-22
  Author Alan Cooper, "Father of Visual Basic" is- or was- an "inmate" himself. Thus he is able to provide both an insider's and an outsider's perspective on what the inmates do well and what- in order to bring some semblance of sanity back to our computerized existence- they need help with. The inmates here are software engineers- or as they often self-describe, "software designers". But that is exactly the point of this book- that software engineers, because of what they know, how they think, and who they are, are not and can not be "interaction designers".

  And an interaction designer is exactly what Cooper is now that he's been "sprung". Yet one of the beauties of this work is that Cooper doesn't take an inmate-bashing approach. He understands that "the creation of software is so intellectually demanding, so all-consuming, that programmers must completely immerse themselves" (16). And therein lies the dilemma- the programmer wants the construction process to be smooth and easy, and the user wants the interaction with the program to be smooth and easy. Yet, as Cooper observes, these two objectives "almost never result in the same program" (16). Cooper reveals the programmer as "caught in a conflict of interest between serving the user's needs and making their programming job easier" (81) when they indeed do try to design. Furthermore, he informs the reader that "anyone untrained in interaction design methods tends towards self-referential design" (87). Thus, if the inmates are as different from the bulk of users as Cooper implies, programmers' design attempts are not only constrained by their deep understanding of the needs of the program, but also by their own points of reference as users.

  The solution Cooper proposes here is of an integrated development process that involves an interaction designer from the get go, a model which is distinctly different from that of a designer adding an interface to the product once it is completed. We can illustrate this difference in home-ownership terms.Interface design- what we all are most familiar with- entails moving the furniture around to make the house more accommodating to inhabitants once the house is built and all the furniture already purchased- and it's a house that someone else designed and furniture your family and friends have given you as gifts. Interactive design, on the other hand, is the involvement of an architect and a future homeowner in the development of house plans that truly meet the homeowner's needs. It's a process where each party takes and cedes the lead as they work together to understand each others' perspectives, restrictions, needs, etc., and as a result, the finished product doesn't require add-ons or remodeling to be functional.

  With an exploration of "cognitive dissonance", this book speaks to an "older" generation- one (or ones) that were not born into the electronic age, but that have had to adapt into it. I can't imagine that anyone from these generations who reads The Inmates Are Running the Asylum will ever respond the same way to the frustrations they experience as they strive to function with new interactions between themselves and machines. On the other hand, I wonder whether many of the electronic age readers of this book will be able to relate to cognitive dissonance in this context.
  
  

• Bells and whistles come from marketing, not developers.
  By on 1999-12-25
  "Inmates" makes some very good points. I disagree with laying the blame (or credit) for bells and whistles on developers, however. I work in a small but growing software firm, and the push to add extraneous features almost always comes from the sales and marketing folks. The developers who actually write the code would much rather keep squeezing the bugs out of features we already have, so they can point to "bulletproof" code they've written.

  Historically, marketing's drive for media attention and management's quest for investor dollars has overridden them, so that I have seen several poorly-thought-out features added to our products solely for the purpose of issuing a press release. We're beginning to change that now, making both our developers and our customers much happier.
  
  

• How To Restore The Sanity
  By A3MAN5CBRX1KEV on 2005-01-30
  The high-tech industry has inadvertently put programmers and engineers in charge, so their hard-to-use engineering culture dominates. In our rush to accept the many benefits of the silicon chip, we have abdicated our responsibilities. We have let the inmates run the asylum. When the inmates run the asylum, it is hard for them to see clearly the nature of the problems that bedevil them. When you look in the mirror, it is all too easy to single out your best features and overlook the warts. When the creators of the software-based products examine their handiwork, they overlook how bad it is. Instead they see its awesome power and flexibility. Programming is such a difficult and absorbing task, that it dominates all other considerations, including the concerns of the users. Programmers aren't evil. They work hard to make their software easy to use. Unfortunately, their frame of reference is themselves, so they only make it easy to use for other software engineers, not for normal human beings. Why high tech products drive us crazy and how to restore the sanity? This is what this book is about.
  
  Because it is far cheaper for manufacturers to use computers to control the internal functioning of devices than it is to use older, mechanical methods, it is economically inevitable that computers will insinuate themselves into every product and service in our lives. This means that the behaviour of all of our products will soon be the same as most obnoxious computers, unless we try something different. The incredible power of computers means that few people can afford to ignore them. Even if you don't have a desktop computer, you probably own a VCR and an ATM card, which are software-based products. It is unrealistic to simply say you "won't use computers". They aren't just getting cheaper; they are getting ridiculously cheaper, to the point of ubiquity and disposability. Many familiar products that we imagine as mechanical (or electronic) are no longer made without computers. Cars, washing machines, televisions, vacuum cleaners, thermostats and elevators are all good examples.
  
  This book is written with humour, liveliness, and amusement, it has a lot of funny illustrations. Yet it reveals the problems of software industry which were left attention for decades. One of the problem is "elastic user", such a user which must bend and stretch and adapt to the needs of the moment. When a company speaks about the software it develops, every party involved (management, programmers, testers, sales) include different meaning into the word "user". In "Goal-Directed design", the participants never refer to "the user". Instead, they refer to a very specific individual: "a persona". To create a product that must satisfy a broad audience of users, logic will tell you to make it as broad in its functionality as possible to accommodate the most people. Logic is wrong. You will have far greater success by designing for one single person. Imagine that you were designing an automobile to please a wide spectrum of people. You could easily identify at least three subgroups: the soccer mom, the carpenter, and the junior executive. Mom wants a safe, stable vehicle with lots of space and big doors for hauling the kids, dogs, groceries and other stuff. The carpenter wants a rugged vehicle with all-wheel drive and abundant room for ladders, lumber, bags of cement, and tools. The young executive wants a sporty car with a powerful engine, stiff suspension, convertible top and only enough room for too. If we make such a combination vehicle, what a goofy, impossible car will appear! Making three different products in software is lot easier than making them in steel, too. Another problem which the author points to is "the customer-driven death spiral", where "conceptual integrity" is the only solution.
  
  The author declares that the key to solving the problems is interaction design, and exposes the Goal-Directed design method that provides manufacturers of high tech products with an insightful understanding of their users and a practical blueprint for a superior result. Alan Cooper, the author of the book, and his company, have designed a wide range of products ranging from clean, simple kiosk systems to complex scientific applications, controls for consumer-oriented computer peripherals, conceptual designs for entire product lines, eCommerce sites. The list of companies that adopted the Goal-Directed design includes many industry leaders, large and small, such as 3M, Proctor & Gamble, Dolby Labs, Fujitsu, HP, Informatica, Logitech, SAP, Charles Schwab, St. Jude Medical, and Varian. The description of Goal-Directed design in this book is very reader-friendly and is targeted to the broad audience. Alan Cooper gives the further explanation of this method in his following book "About Face 2.0", aimed mostly to the engineers. Although these two books are still not enough to deploy this method in your organisation, they show how vital this technique is for a successful product.
  
  
• Uh...how do I program this VCR?
  By A3VEZCMHHKK80R on 2000-02-14
  In The Inmates are Running the Asylum, Cooper has given us a vehicle to articulate our frustration with today's technology. He does so in a humorous, down-to-earth fashion that puts us at ease with our confusion with today's feature-happy electronic devices and software. He offers an empathetic stance, leading the charge against all the new features we have grown to hate or ignore, thrust on us by overzealous engineers (the inmates) ignoring the pleas of designers and consumers alike. This is quite an admirable task considering he is a guru in the field of technology and one of it's prime developers. He gains his authenticity from his experience within the computer industry. If ever there was someone who should be savvy about technology, it should be Alan Cooper, but he is right there as frustrated as we are with products which require manuals bigger than most dictionaries.

  In this book, Cooper offers us an insider view of the world of product design and software programming. The world of computers and everyday appliances are merging and, Cooper contends, the merger is not necessarily in the best interest of consumers. He offers some sound advice to designers, engineers and programmers on how to improve the design of products. Although I did not agree with all of his solutions, I still highly recommend this book to anyone who has ever wanted to throw a VCR out a window or designed a product somebody else wanted to throw out a window.
  
  

• "Painting the Corpse"
  By ANO3KSOXDYG2X on 2000-02-14
  Cooper is right on the money with many of his descriptions regarding the grafting of computers into various facets of our lives. Throughout the book he addresses the daily issues "apologists" (whether they are willing admit it or not) and "survivors" alike struggle with and put up with, such as Microsoft* software, (need I say more). The section of the book that really struck a chord, as I work with engineers to create product training, was the reference to the use of "bribery by chocolate" and how it resulted in cutting overtime of a Technical Writer by more than half. This not only showed the human side of the programmers/engineers that many of us don't get to see, but it validated my methods. Bravo!

  Cooper also has a clear process flow for creating successful technology-enabled products, which he compares to that of the filmmaking industry. Design first, program second, user test and bug test third, and finally tweak. In order to keep the vision and goals clear in this process Cooper creates personas to clarify and better target the product's user. When the design and programming team is able to keep this in mind with a constant visual of the pre-determined persona(s), the product plan is in control and the product will be a success.
  
  

• one of the funniest books I've read in ages
  By AVQPY4RTQT93I on 2000-12-22
  Cooper explains that he hates VB; it was meant to be a makeshift until someone could do the job right, but no one ever did- they used the kludge instead! He procedes to skewer most of modern-day software design, quite deservedly in my opinion. I spend a certain amount of my time telling my students that "In Excel, the format category Accounting refers to currency symbols, and the format category Currency refers to accounting conventions," and "The phrase Range_Lookup means 'do you want an exact match?' and if the answer is Yes, you have to type in FALSE." So I am quite alert to how little attention programmers pay to the end users of software. I wish all programmers would read this book! For the rest of us- the end users, the teachers, the people who have to mediate between computers and the not-yet-computer-literate, this book is a great way to at least laugh about it, and to reassure yourselves that it's NOT YOUR FAULT that software seems so illogical!
  
  
• More mud slinging than a US presidential campaign!
  By A1R9QOPV6HVEKF on 2001-06-19
  Do you hate programmers and engineers? Do you like to read page after page about how evil they are? Would you like to read a book that seems to be written by this very same "Homo Logicus" (programmer) personality?

  If you answered yes to any of these questions, make use of Amazon's patented "One Click" technology right now!

  The title, "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity" is catchy, and as a recent study found, 25% of computer users actually attacked their computers. There is plenty of bad design, and frustration to go around. The opportunity exists for somebody to write a really insightful book identifying the problems and potential solutions to this dilemma. The author COULD have done it.

  The author makes some headway in pursuit of this goal, and does in fact present a few innovative approaches and solutions to fixing and preventing problems associated with the design process of technology products and software. These nuggets of gold, are littered few and far between the relentless attack on programmers and engineers.

  We are desperately in need of a change in the focus and design of software and other technologically enhanced products. This book gets a second star, because it provides some valuable insight....it could have been a great book:( There is however, no need to torture yourself reading this book. Keep looking, that is, unless you answered yes to one of the three questions above.
  
  

• About Face 3: The Essentials of Interaction Design
• The Design of Everyday Things
• Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition
• Sketching User Experiences: Getting the Design Right and the Right Design (Interactive Technologies)
• Designing Interfaces: Patterns for Effective Interaction Design