Customer Reviews

The Inmates Are Running the Asylum

5 star:		(61)
4 star:		(49)
3 star:		(12)
2 star:		(14)
1 star:		(14)

 

 

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."

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.

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.

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.

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.

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.

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.

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.

The Inmates Are Running The Asylum starts off pretty well. It begins with some very good examples of poor design that lead to a bad user experience, as well as just how downright dysfunctional the software development process can be. There is also the beginnings of a thesis on how to solve these problems. From there however, the quality of The Inmates takes a steep nosedive. The deeper into The Inmates you go, the lower the signal-to-noise ratio becomes. Cooper's message gets buried progressively deeper under a heap of sand-kicking diatribes about software engineers, armchair quarterbacking of the designs of others, and thinly veiled plugs for Cooper's particular brand of interaction design consulting.

There are some good ideas in The Inmates, though nothing truly groundbreaking at this point in time. Cooper champions things such as goal oriented design, personae, and primacy of user friendliness. All of which are good things, but none of which are exactly new concepts in 2008. However, the actual useful information comprises maybe 75 pages of the 250ish pages in the book, and is reduced to little more than nuggets of useful information scattered throughout a sea of whining and self aggrandizement.

Cooper's armchair quarterbacking of certain technologies as 'dancing bearware' is particularly annoying. Cooper continually brings up example after example of software and technology that is breaking new ground, acknowledges the fact that the technology even exists as an amazing achievement, and then turns around and lambasts it for not magically coming equipped with the precise amount of polish and feature sets that he wants. The 20/20 hindsight through which Cooper views many technologies belies the fact that Cooper is just as blinkered when it comes to the 'big picture' issues of software engineering as the managers and programmers that he continually needles.

Cooper tries to keep the tone light, and his unique brand of humor kept me reading even as the tone of the book slid gradually into that of a polemic against all things Alan Cooper doesn't like. This book can be downright dangerous if taken as holy writ. Cooper continually takes shots at programmers, and in fact spends an entire chapter reducing them to a set of stereotypes and providing an 'animal handling' guide for the backwards, egotistical, smelly bullies otherwise known as 'programmers'. Taking Cooper's stereotypes to heart is pretty much guaranteed to cause rifts between design and engineering teams, as Cooper goes to great length to explain exactly how far beneath contempt programmers are, how they are not to be trusted, etc. The Inmates espouses a philosophy of design in which non-designer stakeholders are to be marginalized or even totally cut out of the design process. The concepts of business or technical needs influencing design are constantly sidelined, as business and technical concerns are never legitimate, but rather the result of inept managers or lazy programmers. This book should be subtitled 'How to have your design, business, and engineering teams at each others' throats in 3 easy steps'.

Overall I think that the book has some useful information, but much like Cooper does with his case studies, the reader must cherry-pick it to obtain any useful information. Coopers ideas are good (if dated), but they could have been presented in a far more concise fasion, and could have done without the extra 175 pages of masturbatory ego stroking, ranting, and poorly disguised plugs for his consulting firm.

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.