countdown boutiques-francophones Learn more vpcflyout Pets All-New Kindle Music Deals Store sports Tools

Customer Reviews

3.9 out of 5 stars
3.9 out of 5 stars
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on February 20, 2003
I like Alan Cooper. He is entertaining, thoughtful and has numerous amusing anecdotes and analogies. He is a "voice sounding in the wilderness" in the software community about usability. Unfortunately, I think his point is lost somewhat in the marketing message and sensationalism of this book. Who is the book written for - the software developer or the frustrated user? The first chapter sounds like a Luddite rebellion against computers. It is hard to imagine the person writing that chapter as a computer professional. Using the analogy of a secretary who doesn't know how to save files to a folder as an example of poor design is blaming the programmer for poor training. True, software is often developed by programmers who barely get real requirements, develop in a vacuum and then force feed the end result to the user. And ironically, Alan Cooper invented Visual Basic, which ushered in Rapid Application Development (RAD) programming (good!) but adds the tendency for quick prototype demos to get shipped as "Version 1.0" because the CEO or CIO says,"hey it works now" (bad!).
These shortcomings are not solved by adding a layer of another design person partially disconnected from the user, or making the screen prettier. It is by adapting the Extreme Programming/Agile programming methods of including the user in everything from design to testing, so the software reflects how the user does business.
I still liked the book, just not clear on the message.
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 8, 2002
From the first page this book shows itself to be the product of a lot of anger and not much thought or fact. The example of the American Airlines crash is glib and incorrect - 'pilot error' has not been given as a reason for a crash in many years. Similar problems occur thoughout the book - developers are lying when they say that something is technically difficult, using a knob rather than buttons is the answer to everything, design without regard to cost is the only way to do it. There are some ideas there but anything by Donald Norman is better. Like Clifford Stoll in "High tech Heretic" the author mistakes opinion for fact, and generalises with abandon. Yes, products are often poorly designed but all products are designed within constraints and ignoring them does not negate them.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on June 23, 2004
I found myself really getting into Cooper's book as I read it. He's an easy writer to read. He keeps things interesting with all sorts of anecdotes and experiences, and he describes them with tongue planted firmly in cheek.

That's not to say that he isn't serious about what he has to say... clearly, he is very serious. In describing the difference between a Designer and a Developer, and even in more detail when contrasting a Visual Designer and an Interaction Designer, he makes clear just how important this subject is, and how the differences he is talking about can determine the process by which a piece of software or application comes together, and the success of the final product. His obvious frustrations with the roadblocks to effective user-focused design should be understood by anyone involved in the design process.

The pinnacle of the book, for me, came in the middle. At the end of Part 3 ("Eating Soup with a Fork" -- great title), he discusses the relationship between humans and technology. He says something so simple that it should have been obvious, but it's really a fairly major shift in perception from what many people think. He talks about the assumption that technology is dehumanizing here:

"It doesn't require sophisticated tools to dehumanize your fellow humans -- a glance or a kick does it as well. It is not technology that is dehumanizing. It is the technologists, or the processes that technologists use, that create dehumanizing products."

This is important to what Cooper is trying to say in "Inmates" in so many ways. The theme of the book throughout seemed to be that interaction design is only as friendly, or as UN-friendly, as people make it. Technology only does what we tell it to, as we design and implement its specific functions.

The real revolution that this implies is the possibility that technology can be made to interact successfully with humans, and that it doesn't have to frustrate or debase the people who try to use it. In fact, as a human creation, technology is as human as we want to make it. As Cooper said in chapter 6, "For users to be happy and effective with software, it must be written in harmony with the demands of human nature."

But like anything, to make software effectively intereact with humans (i.e. more helpful, more usable, etc.) takes more work... one of the roadblocks. Cooper talks, also, about the established culture of programmers. He defines them as almost a seperate breed of humans, at least as far as their thought process and rationale... "Homo Logicus" as opposed to "Homo Sapiens." He talks about the rift that often appears between them, largely because of the cultural perception (mostly an obsolete view) that software is a solitary occupation, that programmers work in a vacuum and are the sole authors of their work.

The book makes it clear that the software design process can no longer be one which belongs to a solitary person. The creation of software works better as a collaborative effort than it does as a single-author process. Product planners, interaction designers, usability experts, testers, and yes, programmers all have their part to play, and when it comes together, it can yield great results.

Cooper's conclusion seems to be that the most fundamental changes to the software industry need to be made to the process. The people who make the software are, by and large, talented at what they do, and willing to change for the better if they can. It is when they are asked to do more than they should be that problems arise. A change to the process will ensure that better, more usable products can be made.

It seems that most of the people who do the work of making the software in question are willing to change the way they do things, but only need permission to do so. Cooper's take on it, which I agree with, is that it has become not only advisable to move on from the obsolete programming culture we have relied on in the past. If we want to make a change towards more usable products that end-users feel comfortable interacting with, then a change to the process of software creation to a more collaborative effort of interaction design and development becomes an imperative, at the very least.

Recommended to anyone involved in the software design process. Record it on tape and play it for project managers while they sleep.
0Comment|Was this review helpful to you?YesNoReport abuse
on January 30, 2004
It's worth reading this book -- even despite the painful tone he often takes -- just to pick up on the ideas of creating concrete personas and how you use them to develop your product. We do that today at Microsoft (at least in Developer Tools), and it's a highly successful way of not only building a good product, but also in helping hundreds of developers understand why a feature is 'in' or 'out', no matter how much they might like it personally.
It's also mentioned quickly, but the idea of how much work customers are willing to do for an amount of benefit can affect your designs for the better as well. Fundamentally, you should add value with no documentation and no setup -- if somebody paid money, they should feel rewarded as soon as they start to use your application. Then, after they want to do new things, you can require more work of them to do it. However, it should never be more work than the benefit that they derive! This is an important lesson that, say, most media player application writers would be advised to learn...
Of course, as many other reviewers have pointed out, it might have been nice if he had created some personas for who his readers were. I doubt that any of them would have had a goal of being preached to.
0Comment|Was this review helpful to you?YesNoReport abuse
on September 25, 2003
This book is written for two audiences. The frustrated computer user will enjoy the early chapters with its anecdotes about computers failing to meet human needs. The rest of the book is for software managers and professionals who want to be change agents in the industry.
The problem, says Cooper, is that users and programmers think very differently. Users just want to accomplish a task, and have no interest in understanding how the computer works. Programmers want and need to understand the computer on a deep level, and find it hard to design software to meet the needs of people who don't.
Cooper says we need to abandon the idea that there are "power users" and "naive users". Most users are in fact very smart people who just don't think like computers. Cooper's solution is to use 'personas', made up users intended to represent real users with very specific goals, and to design software to meet only those specific users' goals. Design must occur before any code is written, otherwise it is too late.
This isn't a manual on how to use Cooper's goal oriented design methods, but after reading this book it is hard not to be convinced that such methods, or equally radical ones, are needed. Cooper may not have all the answers, but he surely has part of the answer, and is asking all the right questions.
0Comment|Was this review helpful to you?YesNoReport abuse
on May 29, 2003
I kept thinking "we think alike"; not about interaction design per se - the topic of this book - but an evangelistic passion and the desire to somehow convey the deep understanding, the gestalt, of ..... - in this case software interaction design. As a software developer I too am passionate about certain issues of software development - and I find myself often not telling my development team "do this, do that", rather trying to convey the 'why.'
I think the book's title and sub-title lean more toward an eye to marketing than to describing the content, but don't let that and other reviews read here make you think the author is orating from his high horse. He is explaining his view of software development (and what to do about it) from his perspective as an interaction designer (not to be confused with an interface designer). Analogy, anticdote, and brief example work well here. Maybe because my experience causes me to agree with so much of what he says that I very much liked the book and how he said it.
I came away not with the knowledge for hanging out a "Interaction Design - the doctor is in" shingle but rather a sense that this guy knows what he's talking about and his points have validity. Then I went and bought his latest, "About face" version 2.
0Comment|Was this review helpful to you?YesNoReport abuse
on July 30, 2002
This is a book about Interaction Design. I feel I need to say that right off the bat since the title, "The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity," as wordy as it is, doesn't say that. In the preface Cooper explains that the purpose of the book is to make a business case for Interaction Design. Therefore he wrote a book for managers. It's full of wacky metaphors not only in the title, but throughout the book. (Add this to the list of oddly-titled business and management book titles: Who Moved My Cheese? Crossing the Chasm, Swim With the Sharks, and so forth.)
I'm not a manager, so I can't say whether this book succeeds in making a persuasive business case for Interaction Design. It was heartening to see validation for my area of expertise in black and white. This is not a book for software engineers to read, though, as Cooper seems to have a real problem with programmers. Where Don Norman blamed bad design on designers in The Psychology of Everyday Things, here Cooper places the blame for bad software products directly on programmers.
An Interaction Design book written for Interaction Designers would have included more details about how to create and use Personas and Scenarios (two of Cooper's design techniques), and perhaps some advice on how to gain control and respect on interactive projects. But we don't get that.
This isn't quite the book about Interaction Design that Interaction Designers need. It does introduce important ideas and techniques, and does describe, in some detail, the problem of programmer-driven products. But I didn't feel that the solutions were covered well enough.
0Comment|Was this review helpful to you?YesNoReport abuse
on July 23, 2002
I am a software development professional and have recently managed a project where I used a dedicated design team to define the way the software would interact with its users.
Cooper has a valid thesis - that we need dedicated design professionals to design software that works the way it's varied users (AKA personas) need it to. Unfortunately, Cooper spends an inordinate amount of time making the point that "Software that is hard to use is all the fault of those evil programmers who have too much power that they are unwilling to give up."
If you can get past the annoyance of the simplistic explanations and broad generalizations (there are many), Cooper has a number of good points:
1) That designers who specialize in software interaction design should be the people responsible for software's interaction with its users
2) You need to design for particular types of users (personas as he calls them - I've also seen the expression "role" or "user role" to describe similar concepts)
3) Time spent designing software is time well spent
I would have like Cooper to reveal more about the methodology and particular deliverables that he uses when creating the design (making it easier to apply what he is advocating without hiring Cooper himself). Clearly, this book was written to increase the credibility and sales of Cooper's firm.
0Comment|Was this review helpful to you?YesNoReport abuse
on May 2, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on April 1, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse