Rating: 
Summary: Put this in the category of pattern recognition
Review: If you are in the business making technical products, selling, marketing or supporting them, this book is a must read. Some have quibbled about the author's biased writing style or the simplistic, fuzzy nature of the message, and I agree. Nominally, these things affect the overall crispness of "Inmates." That said, the book provides a basic and well-formed way of thinking about customer workflow, and advocates a methodology for building products accordingly. Yeah, it should obvious, but we all know that the reality is different. So you use the tools of persuasion where you can find them, and this is one of them.
Rating:
Summary: Good design book, harsh treatment of developers
Review: Cooper brings a lot of insight and practical ideas to software design in "The Inmates are Running the Asylum." He provides strong arguments for investing time and effort into good design. Unfortunately, his style isolates one of the primary groups who should read this book -- software developers.As with so many designers, Cooper starts by bashing existing software and design. Part one points out that bad design of software can cause lots of things to fail. I can't agree with his thesis that adding a computer to anything makes it fail, but adding bad design certainly can cause failure. Software developers won't appreciate being to fall guy. This antagonism muddies the message. Many readers will miss the premise and value of the book's message because of his insistence on placing blame. He very nearly comes across as "software would be so much better if we didn't have those pesky developers!" It's easier to hear criticism from a colleague. Unfortunately, Cooper fails to provide his bona fides (he has been in software developer for many years) before bashing, so a lot of technical readers will put down the book -- figuring he's some design crackpot who's never shipped a product -- and never pick it up again. That's a shame. Cooper is a skillful guy, and he's got important things to say. His points on design are spot on, and he identifies the root cause of design problems well, and what keeps them around. He provides a much larger perspective than other books that focus on user interface design exclusively. Part 2 explains why bad design cost businesses money, good will, and time. However, the supporting evidence is composed of qualitative examples, rather than more quantitative, financial evidence that some business readers might find more compelling. Although he claims that his goal for the book is to make this business case, it's only 40 pages - less than 1/6th of the book's complete text. Part 3 goes back to laying the blame at the feet of developers. The points he makes are valid, and his explanations of how we got to where we are well founded. His concept of "homo-logicus," though derisive, is insightful. However, the left-brainers out there will have to wear their thick skin to get full value out of this discussion. Finally, in part 4, Cooper throws us a bone. We get some of the stuff that Cooper is really expert at: design. He describes several powerful techniques that people can use to address their real-world design problems. In part 5, Cooper integrates design back into the product development process. He advocates roles and responsibilities for designer in this process. It would be interesting to see his reaction and placement of the role of designer in one of the new agile methodologies. This book is worth reading. Software engineers who can look past the tone will learn a lot. Unfortunately, there are few alternatives that contain such a valuable content, with a better tone. You can go back and read "Programming as if People Mattered", but picking the valuable insights out of that 1991 text is difficult. Other alternatives are Joel Spolsky's "User Interface Design for Programmers," but this text tends to focus on the nitty-gritty of user interface design rather than design as a whole. I look forward to his next book. Maybe he'll make developers a primary persona, and not the villain.
Rating:
Summary: Great content, but leave the ego behind!
Review: 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.
Rating: 
Summary: Careful; this book will change the way you view your world
Review: After years of watching smart people feel stupid while struggling with computers, I knew there had to be a better way. There is. This book helped to launch me on my career as an interaction designer/interface developer/usability specialist. (No one seems to have adequately captured a title for this position yet.) Cooper spends the first half of the book waking us up to the problem, and the second half showing us what can be done about it. After using his methodology on a number of projects over the past few years, I can say with all confidence -- IT WORKS. Beautifully. Using Cooper's approach, we've created software applications that don't require training, that users love, that users have even demanded to use rather than their old tools. And the majority of the programmers with whom I've worked have become converts to this process. Many are finally relieved to stop worrying about business requirements and users and interfaces, and are all too pleased to leave those demands in the hands of an interaction designer. I've primarily used his methodology in an XP programming environment, for those of you who are wondering if the two approaches are compatible. They are, wonderfully, with a few tweaks. But maybe that's another book.
Rating:
Summary: A Design Methodology That Everyone Benefits From
Review: Alan Cooper has come up with a design methodology for software-based products that all can benefit from. Cooper's "Goal-Directed Interaction Design" would reduce the friction that programmers have with their constituents as well as benefit the users with easy to use software that does what they want it to do. It occurs to me that everyone stands to gain from this methodology, the users, the designers, and the programmers and one those three groups benefit the company as a whole will benefit. I'd urge anyone involved in software development to READ THIS BOOK, UNDERSTAND THIS BOOK, AND DO WHAT THIS BOOK SAYS. And, for what it's worth, I am a Software Engineer.
Rating:
Summary: Cooper scores points with programmers too
Review: I just finished reading Cooper's book, and I loved it. Not only did I love it, but I think Cooper deserves high praise because I'm a programmer (or will be when I finish school) and he even convinced me that goal-directed design is the way to go. I have to admit, I didn't like the book at first. More to the point, for the first half of it or so, I thought it was absurd. I thought he was overstating the problem, I thought he was stating the wrong problem, I thought he was being overly alarmist about technology in general, etc. I even considered dropping the book and not finishing it. However, I often like reading views I don't agree with, so I continued. It wasn't until he started describing your solution that I saw the bigger picture. I thought he were being unreasonable and blindly attacking tech culture, but he wasn't. Cooper actually has a solid, insightful, and thorough solution to a problem I wasn't even aware existed. I haven't really considered design in any of the programs I've written, and granted, I've only worked on one consumer product before (the rest were behind-the-scenes plumbing). But I definitely will now. "Inmates" is a great read, and I can't wait for his next book!
Rating:
Summary: Everyone in High-Tech Should Read This Book.
Review: Cooper exposes what is wrong with the software development process that we are so familiar with. He does it while being entertaining and easy to read.
Everyone involved in any project that has software in it should read this book, especially the managers.
OK, he's arrogant, but I still found the book fun to read.
Rating:
Summary: Why does anything plus a computer equal a computer?
Review: I read this book with a pad of post-it notes to mark the pages that made an impact. By the time I finished the book, I had gone through one plus another. Cooper draws a line between the geeks and normal people. He strives to push that line back towards the normal, observing correctly, that the world of machines greated by geeks is getting more and more complicated. Why? Because geeks are designing for themselves, and if you're not smart enough, it's your fault! This is incredible hubris and arrogance. Why are they getting away with it? Because false goals like "people need to be computer literate" are getting in the way. Also, the computer industry currently has a business culture, which is driving with the theme "We have to put the next product out fast!" instead of "We have to create quality products which will help our customers to achieve their goals." It was exactly that set of attitudes which made the American car industry so vulnerable. Would you buy crappy software because it was "American Made"? This book gives a lot of examples which make it very easy to identify with Coopers viewpoint, that of a software developer turned "interaction designer". What is more difficult is figuring out how to apply the solution he proposes. His explanation is less clear, and tends to lean too strongly on self promotion. It's boils down to "design first." Who is going to get the most value out of this book? If you are a manager or founder of a small software company, I suggest this book when you are forming your core vision and mission for that company. The value "design MUST come first" is a cultural value, even though the temptation to "tack on design" is very seductive. He aludes to a process of making an organization adopt that value, and the key idea for that seems to be the introduction of the concept of "Persona", a specific description of a fictional user of the software. Developers should be thinking, "What does Wally want?" instead of "the user", since the user can become anything. This books is worth buying just to discover the concept of Persona in full. One last insight. He offers a design for a VCR with two knobs. One to set the time to record the movie. The other to record the length of time to record. Why don't geeks build it? Because it has no "meta" function. The meta function is some magical button which changes the device with computer control into something better, with more qualities (features). The reason that geeks are facinated with the meta function, is because it changes the utilitarian world of tools, into a fantasy world where items are more than the appear. The transformation of the mundane into the magical. In the magical world, the geeks rule. In the mundane world, the customer rules, and until the geeks learn to live in that world, the customer will always be always leave, feeling that they've been tricked somehow.
Rating:
Summary: Technical writers: must read this book
Review: Technical writers should read this book to understand how they can (and why they have an obligation to) influence design, and consequently write less documentation. If they do write documentation, they then can spend time on more substantive issues for users. If you are a writer today and have not read this book, you are missing out on a gem. This book is timeless and universal.
Rating: 
Summary: Important book, though Cooper's not as smart as he thinks
Review: The central thesis of this book is that software should be designed for the user's ease first and the programmer's ease second. Cooper's points are generally excellent, although I fear that the vast majority of ears his message falls on are irredeemably deaf; most programmers care not a whit for the hapless users of their software. If anything, this book doesn't go far enough. The fact that Cooper is the creator of Microsoft Visual BASIC - a tool that encourages the creation of the worst kind of sloppy, ill-thought-out, user-hostile software - ought to tell you something about his position in the field of human-computer interaction. It's sad but true that just about anyone studying HCI is inherently radical (since most technical people want nothing to do with the end user) but Cooper is as conservative as they come within that spectrum. Despite the provocative title, he seems to view the changes that must be made for computers to be truly usable by the average human as evolutionary ones, not revolutionary ones. The best example of Cooper's conservatism is, I think, his skepticism about the usability of hierarchical filesystems. Cooper says that systems of nested directories or folders are, for non-programmers, one of the most confusing features of modern computers; he gives a couple of anecdotal examples in which average users save files, then lose them forever. While this seems to be a revolutionary attack on a cornerstone of modern OS design, it really isn't. While Cooper is correct in citing the presentation of a hierarchical filesystem to the application user as an example of interface-design-ignorant programmers allowing implementation structure to dictate interface structure (a policy which he rightly decries), such presentation is not a good example of what not to do: there is nothing intrinsically wrong with a hierarchical filesystem from many, perhaps most, users' point of view. Anecdotal evidence is not proof, but I know many non-techies who understand (and, more important, take advantage of) the Windows filesystem. Hierarchies of categories within categories are in fact all around us, because an appreciation and understanding of them is (I believe) hardwired into the human brain. Consider the Library of Congress card catalog system, or the Linnaean taxonomy of life. There are two things wrong with the hierarchical filesystem of Windows and the MacOS from the user's point of view (neither being its sheer existence). First, its structure is obscure. Both Windows and the MacOS, in the standard dialog boxes that they present when the user is saving a file, show only the files in the current directory, with no context. Both OSs will display on demand an abbreviated tree showing the structure above the current directory, but this option is hidden in a non-obvious popup menu; and even if it were more obvious, the display would not be very helpful, because it doesn't show the tree structure of the entire filesystem - just the parents, grandparents, and so on of the current directory. If not just the local context, but a more general context (the entire filesystem) were displayed at all times when the user was trying to choose a directory, the first problem with computer filesystems would be solved. The second problem with the Windows and MacOS filesystems is that they mix user documents and everything else together. Microsoft tried (in its usual half-baked way) to address this issue by creating the "My Documents" folder in Windows 95. But *documents* shouldn't be segregated into a single folder. *Applications, system files, and related data should be* - or ideally, they should be in some sense *not there at all*, from the user's point of view. Most users don't know or care that executables, libraries, configuration files, and the like are stored in the same way on the disk as their own documents. In fact, they don't care about applications at all - *only* about documents. The original GUI model developed at Xerox PARC (by which Windows and the MacOS were inspired) was a document-centric one, involving no explicit applications. Document-centric computing has never taken off for two reasons - because it's different, and because nobody's figured out how to make money from it. (How will we sell applications if there are no applications? goes the conventional wisdom.) Yet, sadly, there is no mention at all of this fundamentally superior HCI paradigm in The Inmates Are Running the Asylum. In his fundamental conservatism, Alan Cooper is way behind some of his cohort, like Donald Norman (author of The Design of Everyday Things), or Jef Raskin (the least technical, and thus most important, member of the original Macintosh design team) - both of whom have come out strongly in favor of document-centric computing.
| 
