Rating: 
Summary: A Revelation
Review: Reading this book was a revelation for me. Sometimes the tone is arrogant. Sometimes the tone is patronizing. However, the book presents a scathing critique of the current state of the design of computer usage and some practical techniques to improve the situation.For anyone floundering around trying to start a ground-up UML design of software, this book is an essential read.
Rating: 
Summary: This review is Short and Sweet . . .
Review: In my company, we treat the users of our software as Customers. I see this book as a technical warning, but also as a warning about the level of service we provide. While it may appear on the surface to be a technical book, it is really common-sense about why high-tech design is spiralling out-of-control. It is a guide (or call to action) to simplify the way we design our products. It is a call to provide better Customer service by keeping the human element in our design and instructions instead of "computerizing" our interface with our Customers. We can advance into the computer age, but we don't have to make it so doggoned complicated! This is a great book for any designer/developer who gets too caught up in "gadgets", software "features", and high-tech "computerese". Although we move in high-tech circles, we musn't forget our most important asset, our Customers.
Rating: 
Summary: Useful ideas but infuriatingly arrogant
Review: 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."
Rating:
Summary: Great Ideas, Not Always Well Presented
Review: 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.
Rating:
Summary: Can interaction design really save the software industry?
Review: Alan Cooper wants nothing short of cultural change in the software industry. He wants to get programmers out of the business of deciding how humans will interact with computers. He asserts that interaction design specialists should do that. Interaction designers will create self-evident software to which customers will flock. Hear, hear -- but good luck. As long as software companies continue to be profitable with programmers doing interaction design, it's not likely to stop. Unfortunately, Cooper limits his book to the business case for interaction design. This omits the action step: how to effect that cultural change within a software company.
Rating:
Summary: Great Knowledge - Brilliant Presentation
Review: Being fairly new to the usability business, this book has provided me with some very very powerful methods and ideas for interaction design. Until I read this book, I thought that usability inspection methods constituted the holy grail to developing state-of-the-art software. Alan Cooper, however details my naive picture somewhat by arguing about the importance of interaction design, i.e. the process of creating a detailed software manuscript (just as they do in the movie business) before bringing in the programmes. In addition to explaining his ideas, Mr. Cooper also provides some very specific guidelines for implementing these ideas. The guidelines are backed by real-life examples from the work performed by Mr. Cooper and co-workers. The first part of the book is devoted to an explanation of why software is designed the way it is. The responsibility for software development is largely placed in the hands of the programmers - which in the mind of Mr. Cooper are a breed of highly technical, skilled and devoted persons that in general have no understanding for the problems or needs of the end-user. I like this book for many reasons: Mr. Cooper is witty, the examples are good and informative, everything is well written. But most of all: I really like his message, and this book has been an eye-opener to my narrow sighted vision of usability. Bravo!
Rating: 
Summary: Interesting Concept But...
Review: Poorly written...redundant...not fully developed. I'm always wary of "experts" that utilize dumbing-down as a means for enlightenment. A few bright spots; personas, prototypes vs product, schemas... I particularly enjoyed the chocolate bribery papagraph [Chimey Ale works better]. Check it out and skim-it from the library--Not worth owning.
Rating:
Summary: Enlightening Approach to UI Design
Review: This book is such an enjoyable, enlightening read, and prompts you to think about how you use (software) products and how to design them so that they are usable. The concept of personas presented here seems like an excellent way to ensure that the software and user interfaces that we develop actually help thoses that they are intended for. This is the theory behind "About Face". Probably the most useful user interface book I have read.
Rating:
Summary: Blame it on Cognitive Friction
Review: 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.
Rating:
Summary: Retaking the Asylum
Review: Anyone who has "chips" in their lives can appreciate Alan Cooper's The Inmates Are Running the Asylum. Cooper, a former programmer and inventor of Visual Basic, has written an interesting study of the frustration that many people in today's technological world are feeling. He articulates these frustrations in what he calls "cognitive friction" or the lack of intuitiveness that seems to be designed into many of the products that we all are using on a daily basis. He speaks to the issue of who is designing the products that we use. It is not the end-user but the software/hardware engineers who rarely, if ever, get the opportunity to interact with those who have to make these products function in every day life. He also addresses the concept of interaction design rather than interface design. As the technology becomes increasingly complex, users will expect that rather than having to conform to the program in order to interface with a product they will want software and hardware that they can interact with instead. For an interesting look into why software has turned out the way it has I would recommend reading The Inmates Are Running the Asylum.
| 
