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.
"Devoted" by Dean Koontz
For the first time in paperback, from Dean Koontz, the master of suspense, comes an epic thriller about a terrifying killer and the singular compassion it will take to defeat him. | Learn more
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
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.
- Item Weight : 14.3 ounces
- Paperback : 288 pages
- ISBN-10 : 9780672326141
- ISBN-13 : 978-0672326141
- Product Dimensions : 6.1 x 0.85 x 9.15 inches
- Publisher : Sams - Pearson Education; 1st Edition (February 24, 2004)
- Language: : English
- ASIN : 0672326140
- Best Sellers Rank: #383,416 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
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.
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.
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 reviews from other countries
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.