Rating: 
Summary: Save your money, don't waste it on this book.
Review: My best advice for you regarding this book is to avoid it like the plague. The worst thing about it is the anti-developer attitude the authors take and the tone of their writing. They are highly critical of developers in general and seem to think that all the shortcomings with modern day software have been intentionally placed there. Also, the authors feel the need to pepper the user with "big words" in what appears to be an attempt to make themselves sound smarter. Look at one of the other reviews where the reviewer actually documents some of these usages. The reader is advised to have a dictionary handy when reading this book. Another problem I have with this book is that the authors like to talk about software usability problems yet in many cases offer no solutions or ideas on how to fix them. What's the point in bringing up a negative if you can't offer up a solution? If all the author is going to do is complain about something, why would anyone buy the book? What is really unfortunate about this book, aside from the fact that I wasted $25 on it, is that the authors do raise some valid points but these are lost amidst all the wordy blather that is so prevalent. One thing for sure is that in the future, I will think long and hard before I purchase any book authored by Cooper and/or Reimann.
Rating: 
Summary: The Definitive Work on User Interaction
Review: One valuable lesson on every single page. Required reading for designers, engineers, information architects and technical managers. Buy yourself a copy and another one for your boss.
Rating: 
Summary: Immediate benefits to my software product
Review: Out of reading this book, I was inspired to make many changes to my software interface that resulted in dramatic improvements to quality and usability. There are times when I wish it had more out-of-the-box solutions and concrete examples of how to design, and there are times when it devolves to ranting. But there is real help here for me as a software designer.
Rating: 
Summary: Good techniques on design, but sometimes a bit preachy
Review: Personas and goal-directed design are great techniques for putting together a quality product and really making sure that you're building the right things for your users. In particular, this book provides a process for doing design that would help most teams do a better job of being more customer-focused. Unfortunately, this book has a few bones to pick with the current ways that users work. In many cases, while I may agree with statements such as that the File menu is not strictly necessary, users of many programs already understand how things work under the hood and want to know about it directly. He sometimes preaches design as if all customers of software are and should be ignorant of the system they're working on. I write software for other developers, so a lot of the tips and advice he gives are actually things that would cause my customer to become quite angry -- they understand the system, want to work in terms of it, and want to be able to to understand how your program deals with it. There are a number of commercial software tool failures to prove the mistakes of those who've tried to force a model the designers thought was superior on developers who knew better (ever used Visual Age Java?). There's also a lot of material duplicated from his earlier book, _The Inmates Are Running the Asylum_. If you're only going to read one of the two, I'd advise reading that one, and skipping this one.
Rating:
Summary: Enough fluff for a king size pillow...
Review: Some people have given this book a high rating and bashed others who are just stating their own opinion. ( I'm not that petty or immature ) The authors make some decent points, but their ideas are not original and their writing style is that of someone trying to impress rather than convey information. This book appears to be more of a platform for developer and software bashing rather than the helpful user interface design text that I had envisioned. After chapters of repetitive whines about software developers, I was becoming irritated. That's not what I got the book for. Usability folks will no doubt love this book because it will confirm to them that everything is the developer's fault. Developers will no doubt hate the book because it states that everything is the developer's fault. I don't like the book because it doesn't give me any good information on UI design, which is what I wanted it for.
Rating:
Summary: Worth ten times the purchase price
Review: The ideas contained in this book are golden. It is irrelevant if Alan Cooper sometimes repackages and presents excellent ideas from others. I found this book to be very informative and an entertaining read. I study this text from time to time to freshen up on some of the ideas. If you are serious about developing quality software, you should read this book
Rating: 
Summary: A Usability Engineer should reengineer this book.
Review: The main goal of usability engineering is creating the right interface for the right audience. The target field (cf. the users) of this book are developers, every programmer should have a copy, is not?
A software package, which is unfriendly, laughing and bashing to its user, such a package would be considered as a computer program with a bad design. The user would not like to use it. Now, I'm wondering why the so self-declared software design god of the modern times is bashing, laughing and unfriendly against the users of his product. Mister Alan Cooper does not have a clue how a company works and what the background of a developer is all about. He is bashing the wrong people. Bad software interfaces are not the fault of the developer but the management and the methodologies that are used in most companies. Developers are trained in schools and universities to produce code and to design the internal architecture. Few of them receive cognitive psychology courses, which is needed to create five star interfaces.
The average management in a company, small or big just allows that developers do the graphical interface design, a task for which they were not prepared. The outcome is indeed bad software but don't shoot the pianist, instead turn the spotlight on the choirmaster. The content-worth of the book is average. It is heavily focusing on one aspect of creating better software interfaces: design guidelines. While these guidelines are important, it is not enough to create excellent interfaces. The risk is that a developer, after finishing reading the book will think he or she knows everything about the job and this is not his or her fault but the author. No words are spoiled by instance on User Profiles, Contextual Task Analysis and so many other aspects of user interface designing. The design guidelines itself are mostly not new, I have read them long ago in other works and with some research you find them for free on the internet. Some guidelines-laws described in the book are even examples of bad designs, which is dangerous, at least in a way. I can imagine that for an average programmer the book is still revealing, but he or she should know that other grasslands are much greener. Best case, you have a design guideline book, nothing more, nothing less. I do not know I am allowed to do this, but if you want a real step-by-step guide for creating better software you should try "The Usability Engineering Lifecycle" by Deborah. J. Mayhew, also available on Amazon.
Rating:
Summary: Worst than a waste of time
Review: The tone of the book is very negative, I was often distracted by the authors' strange wording choices, confused by the way their "rules" would flip flop, and insulted by their insinuations that *I* am the problem. This book took a tremendous amount of effort to read and definitely was not worth it.
Rating:
Summary: Some good ideas poorly delivered to unclear target audience
Review: There seems to be some misunderstanding among previous reviewers of who this book is for, and I have to say I'm confused as well. I see the term "developer" used all over the place, but what exactly does it mean? Part of the problem is that according to Cooper (and just about anyone with basic reasoning skills)developers should be writing code and interaction designers should work on the interfaces. So, it would be reasonable to conclude that this book is targeted towards interaction designers. Then why bother mentioning developers as the source of all evil over and over again? Who is this book for, anyway? When the author says "requirements" is he talking about project requirements in general or specific interface-related requirements? When he says "design" does he mean software design or interface design? If you have read anything about software engineering in general, I'm sure you will have lots of questions like these. Although it is a book about interface design issues, it's a big disappointment that the author somehow forgets about the bigger picture and makes it seem like the product is the interface and the design of the product is the design of its interaction with the user. The author also makes some arguable points. For instance, he claims that there is no such thig as computer literacy - we only have to talk about computer literacy because software is obscure and overly complicated to use. Somehow it was no surprise to learn that the author also happens to be "the father of VB" :)
Rating:
Summary: SOME good ideas from an arrogant wordy narcissist
Review: This book had several very good ideas inside it. The vast majority of them are common sense in hindsight. Some ideas are radical and would require massive time and money to implement. Unfortunately, his ideas tend to fall on deaf ears due to the author's use of a writing style more suited to (bad) poetry than technical persuasion, a condescending attitude towards developers, and failing to provide sufficient application examples of his ideas.
Reading this was a departmental exercise for our (software) company. I got a lot out of it, but others did not. This is unfortunate, because if the author took his own advice and removed "excise" and the smugness, the rest of the team would have been more receptive. Apparently Cooper wanted to be a poet and certainly not a technical writer. The first rule of technical writing is to get your point across. He goes on for pages without actually saying anything. He too frequently uses words that many people have never heard of. You don't change people's mind when they have to focus on the words instead of their message (doesn't he say something similar about software). Here's a sampling of his poor word choices. Kafkaesque p440
simulacrum p265
conflated p 465
prolix p469
tessellation p324
interstice p292
appellations p331
proselytizing p334
adjudged p354
bifurcation p367
execrably p453
concomitant p478: While there's nothing wrong with those words, he uses them when other more-recognizable words are available or he uses them when no word is needed at all! It could be removed from the sentence entirely.
All this emphasizes that he's more interesting in sounded like a pompous Lit major than trying to persuade readers. He gives the feel of someone wanting to write a college book and thus makes it intentionally sound technical. Gee, didn't his book say us developers do that with software too often? Can't take his own advice. As a developer who gets paid by customers who buy our product, my goal is help the user as much as possible. Cooper gives the impression that ALL developers are rude, lazy, and hate the user. He calls us lazy because he assumes we always take the easiest (and less intuitive) way out - totally ignoring that we have schedules and our bosses often dictate our features based on time. He imbues us with evil traits as if we're a bunch of maniacal human-haters: "Mwa ha ha! I'll put yet another error message in my program. That should make my users feel stupid and they'll kill themselves and I'll rule the world." Most of us would love to create some of the intelligent interfaces he mentions (but gives few examples). Lack of time is the main reason why we don't. This should be obvious to even beggars on the street corner. Since developers must be persuaded to make these changes, it hardly makes sense to alienate them so. If you're not part of the solution, you're part of the problem. In the extreme majority of his issues with current software, Cooper provides no suggestions for how to solve it. At that point, you're just complaining. The book has some good information and some very interesting ideas. However, its presentation is awful. If you feel developers hate users and intentionally make software complicated (so they in turn will lose business and thus lose their jobs), but you seldom want examples of how to fix this problem, you'll love this book!
| 
