The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
Customers who bought this item also bought
Cooper, who designed Visual Basic (the programming environment Microsoft promotes for the purpose of creating good user interfaces), indulges in too much name-dropping and self-congratulation (Cooper attributes the quote, "How did you do that?" to Microsoft chairman Bill Gates, upon looking at one of Cooper's creations)--but this appears to be de rigueur in books about the software industry. But those asides are minor. More valuable is the discourse about software design and implementation ("[O]bject orientation divides the 1000-brick tower into 10 100-brick towers."). Read this book for an idea of what's wrong with UI design. --David Wall
Topics covered: User interfaces--good ones and bad ones--and where they come from. Also, how to improve the ones you create.
From the Back Cover
Imagine, at a terrifyingly aggressive rate, everything you regularly use is being equipped with computer technology. Think about your phone, cameras, cars-everything-being automated and programmed by people who in their rush to accept the many benefits of the silicon chip, have abdicated their responsibility to make these products easy to use. "The Inmates Are Running the Asylum" argues that the business executives who make the decisions to develop these products are not the ones in control of the technology used to create them. Insightful and entertaining, "The Inmates Are Running the Asylum" uses the author's experiences in corporate America to illustrate how talented people continuously design bad software-based products and why we need technology to work the way average people think. Somewhere out there is a happy medium that makes these types of products both user and bottom-line friendly; this book discusses why we need to quickly find that medium.
There was a problem filtering reviews right now. Please try again later.
Where he goes totally off the rails is when he attacks stereotypes instead of people. He claims that every programmer thinks that he is different and can cross between coding and interaction design -- but none of them can. It turns out that he means that he was the first, and the last, one to be able to do so, because he is God. He claims that graphic designers are there to pretty up an interaction designers designs -- while ignoring the true amount of collaboration that has to be achieved between graphic design, interaction design, and programming to achieve any excellent software. His solution to bad design is to listen to nobody but the designer. (He never mentions the possibility of a subpar interaction designer.)
Finally he spends a lot of time attacking various management structures that are found at Microsoft and companies who mimic Microsoft. Well, I have worked in the NYC tech scene for 20+ years, and nobody here gives a damn about Microsoft's management practices. In the years since the book came out, it has turned out that nobody anywhere cares about Microsoft management practices anymore. It just felt like another rant about something that is relevant to nobody.
But if you wade through the extremist ranting, there really are useful messages and examples throughout the book. It's worth reading if you're in the business of making software.
Good content. Glad I read it. I am appreciative of the work Alan has done.
The messaging could have been better.
I almost didn't complete the book, but I am glad I did.
It was only halfway through I realized Alan Cooper is the guy behind "personas", something that I have been using for quite some time now.
This book is full of useful ideas around design, personas, and lots of useful anecdotes. I think- everyone who is involved in software development would benefit from reading this book.
What I didn't appreciate was-
The whole negativity in the book. I know things suck in software industry, but then where does it not?
Not a very inspiring tone.
At times the book almost had a feel of "wrenching" the control away from developers into "interaction developers" where it really belongs. Very quickly- that became old.
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.
Top international reviews
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 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.
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...
This book show me how wrong I was, and even if my Interactions and Interface wasn't too catastrophic, they weren't as good as they needed to, and that I have to re-learn everything about Interaction Design, because sadly I usually work without Interaction Design team. So I have to learn, to take time (even spare-time if necessary) to design before coding, even if it will be still imperfect, it will always be better than coding first then trying to trick an already created interaction.
This simply isn't true. If it were books like "design for the real world" written by Papanek over 30 years ago would have been unnecessary, Three mile island wouldn't have happened, and no one would ever misdial a telephone.
Sadly Cooper does not present proper evidence for a 'new' problem, preferring an informal and anecdotal style and, in doing so, extrapolating his entire argument from false foundations. He also sees the need to invent a whole unnecessary set of jargon to use, with fairly woolly and subjective definitions.
There are constant inappropriate references and analogies to other forms of engineering (particularly building), their methods and traditions.
"In the industrial age, engineers were able to solve each new problem ... they made bridges, cars, skyscrapers, and moon rockets that worked well and satisfied their human users. .... But unlike the past [computer] things haven't worked so well. "
Is he implying there were no problems before? Tay bridge, Tacoma Narrows, Ford Pinto, Challenger shuttle, Soyuz-1 and Soyuz-11. All suffering from dangerous design flaws (and not isolated) and none of them had anything to do with computers.
By ignoring the reality of past and current failures in (non Software) engineering Cooper quickly leaps to the conclusion that we "... have encountered a problem qualitatively different from any they confronted in the industrial age".
Errr, no. One of the first things we learn in engineering is how much of our wisdom has come from analysing failure and disaster fully, objectively and with academic rigour.
"When engineers invent, they arrive at their solution ... [it] will always be a derivative of the old beginning solution, which is often not good enough. "
Eh? Brunel? Stephenson? Even Santiago Calatrava doesn't shy from the title 'engineer'. Even in our beloved computer field, engineers and scientists abound; John von Neumann, Berners-Lee, Wozniak and Jobs. All brilliant in their day, and derived of what exactly? Not only a questionable assertion but grossly disrespectful and immodest from someone whose claim to fame is prettying up other peoples' work. These were and are the Engineering geniuses, and Cooper clearly doesn't understand engineering enough to see the differences between invention, innovation and merely doing what the budget allows.
In terms of descriptions of what a UI needs to be to qualify as usable, Cooper totally glosses over important concepts such as context. He ignores any Cost-Benefit analysis of designing and building this "no-training, no-maintenance system", blithely asserting that achieving that software (mirage) will reap all rewards. No proof, again, let alone an attempt to prove it would even be feasible.
The problem in programming is not that programmers are ill equipped or unprepared to solve the problems (though some may be), it is that no-one is demanding it of them in a coherent fashion.
Programmers are still being pushed to add 'features' buttons, wizards, gizmos and gadgets of little purpose because marketeers know they need to be able to print it on the box, and that is needed to generate the revenue.
Some programmers have the mindset he characterises, they are hardly very influential. Lack of proper requirements gathering, design, and industry-wide experience of very late, swingeing specification changes cause the problems. Programmers aren't to blame, even anti-social ones, the marketeers aren't, or the pushy ill-informed managers, the customer isn't either, but, at the same time, we all are. What we see is the consequence of nobody really knowing what they want, still less clearly stating, but everyone wanting to stamp their influence on the end product. Nice conspiracy theory Cooper, but it is nonsensical in the real world.
All the evidence sadly refutes Coopers Business Case. Products which demonstrate brilliant consideration of their target users fail miserably to make an impact (or a profit).
Look at the few of case studies of his own consultancy work he is able to offer;
1. A piece of support software for Logitech to bundle with their page scanners. = Logitech got out of the scanner market some time ago, didn't help their sales obviously.
2. Drumbeat web authoring. Well reviewed in its industry journals but scored poorly for ease of use. Elemental Software was bought out by Macromedia, Drumbeat was discontinued shortly after.
3. His in-flight entertainment (IFE) system (Clevis, et al.) for Sony Trans Com. Bought out by a competitor, Rockwell Collins, 2 years ago. Their new IFE will now be run, in their words, "on an industry standard Microsoft windows platform", Coopers system is not their flagship at all.
Now I am not going to say I think Cooper's advise for UI design is poor, or that his design methodologies are wrong. I think he is right in most of what he asserts there. It is just all based on flawed reasoning and syllogisms, and furthermore, most of it is not ground-breaking or even new ... there are plenty of good books out there discussing usability and making recommendations which are far more realistic and thoroughly presented than Cooper's descriptions of how he runs his consultancy. And he still has to demonstrate examples of where applying those principles won't cause you to crash and burn.
Cooper is presenting arguments firmly directed at those who are outside this industry and relying on their ignorance of what goes on. He plays on Technophobia and peddles misinformation. He very cleverly characterises programmers as having something to protect and a reason to be put on the defensive by what he says, in doing so appears to be trying to pre-empt responses and criticisms from technically informed readers. This has (as can be seen from the mudslinging here) unhelpfully stifled debate on his assertions. As Cooper is clearly intelligent and experienced enough to be aware of the flaws I identified, I can only conclude he was having a wry giggle with this book.
The book's populist slant and claim to have "the solution" are very appealing to some, and almost guaranteed its success. Sadly, it contributes little of use to a known and serious set of problems.
I'd suggest Donald Norman's "the design of everyday things" as a much superior book with better solutions, aimed at a wider audience.
Certain points are very good....
The design of the product, and of the way the user may interact with it, as something which MUST be given the proper attention, the right placement in the production lifecycle and which requires sincere domain experts (interaction designers).
Many companies are possibly in a far better situation than in 2006, regarding this topic - others are definitely not.
A great book, easy to read, full of irony, and seminal for new (in 2006) concepts and tools, such as the usage of personas.
There are many better UX/UI books out there.
Les applis informatiques sont à présent partout: depuis nos radios réveil jusqu'aux systèmes de chauffage de nos maison, sans parler de nos environnements de bureau. Or, ces applis ne sont pas conçues AU SERVICE de l'utilisateur ( ou -trice) mais selon la vision de monde des informaticiens, qui elle meme dérive de la façon dont fonctionne un ordinateur. C'est à dire qu'elles demandent à l'utilisatrice de s'adapter au language machine plutot que d'adapter le language machine à l'utilisateur..
Petit souci, qui explique le blocage que beaucoup font face à l'informatique.
L'auteur analyse la façon dont sont développées ces applis pour expliquer pourquoi l'on constate ceci aujourd'hui. Il montre enfin comment développer des applis au service de l'utilisateur final et non des développeurs informatique.
L'ordinateur pense comme une machine, de façon précise et méthodique. L''etre humain pense de façon vague, par généralités, et de façon plus intuitive que méthodique.
Les informaticiens développent en calquant la façon de faire de la machine plutot que de partir de la façon de fonctionner de l'utilisatrice finale.
Il fait la distinction entre l'homo sapiens, l'individu de base, et l'homo logicus, l'informaticien.
L'un adore se simplifier la vie, l'autre adore décortiquer la complexité plus que de se simplifier la vie. Il est plus intéressé par le process intellectuel que par le résultat final censé apporter un bien à l'utilisatrice.
Lisez le, c'est très instructif et essentiel pour développer des bonnes applications pour tous, pas uniquement pour les ' fans de technos '!
San Francisco Consulting
If you are involved in designing systems in any way or are simply interested in the concept, this book is a must have read!
This product is not just an interesting book, it is also a very useful tool.