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

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.

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.

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.

The media could not be loaded.  I’m annoyed I paid full price for a damaged book.

This book provides a wealth of knowledge if you can stick with it through the generalisations and attacks on the group of people who need this book the most.Something Mr Cooper talks about is people not knowing their customers, but falls into this trap himself. While the book may have been written with managers and project leaders in mind, many developers will read it as a means of improving themselves.With this in mind, writing a book that often hints at poor interface design being a deliberate attack on users, and in some places implies that software is hard to use because programmers are getting back at people because they were picked on in high school might be a little silly. This kind of hyperbole is not helpful in getting the message across, and will not help business people further understand their staff.Helping business people understand that different people have different skills and getting the right person for the job will deliver better results than forcing someone to do a job they are not suited for would have been a better result. As it is, I can see how some PHBs would come away from this book believing that they produce bad software because their developers hate them, rather than because they have poor processes and do not invest enough time and money in the right places.

I love this book, I think everyone doing anything do to with digital products should read it, very funny too, but so true!

This is a highly readable and entertaining rant directed against the inadequate development practices of software engineers over the years.I am one of the geeks that Cooper targets, but I think I'm sufficiently self aware to know that his point is entirely justified. Building workable, usable applications on time and on budget is a fiendishly difficult problem. Pretty well all of the effort in improving our working practices has focussed on getting our job done more efficiently and predictably so that customers get their applications in reasonable time and at a reasonable cost. We've always been pretty clueless about the human side, making sure that the applications can be used easily and efficiently. That, of course, has great practical and financial consequences, but the cost is often hidden from the developers who have moved on to screw up elsewhere.Cooper sometimes overdoes his argument, and minimises the real, practical problems involved in applying his techniques. His insistence on calling all developers as "programmers" is a bit irritating, but I can accept that as a stylistic quirk rather than evidence of ignorance of software engineering.I'd strongly recommend this to software developers who are starting to have doubts about whether they're really delivering what users need. Of course, the ones who have no doubts are the ones who really need to read this book, but I suspect they wouldn't even pick it up, and they's throw it aside after the first few pages if they did give it a go. Pity.

Skim parts I-III it's a diatribe on what's wrong.Read Part IV several times and take notes as it gives solutions to the identified problems and is actually really good.Skim the rest...For a man promoting that less is more he could do with applying his own advice to the new edition of this book...