The strength of this book its clear and easy-to-read writing. Cooper's examples are instructive and the theory of why design-centric business approaches are the most powerful. It's supposed to be a business-case book but I'm quite sure all programmers and even designers would find the read very worthwhile.

My only wish for the book would be that Chapter 10 onwards seemed to be the really exciting stuff, detailing the how more than the why of design-centric approaches. This part feels like a rushed summary in comparison the the attention paid to the why aspect in the rest of the book. You may want to consider Cooper's newly revised "how" book although it is mainly a designer's handbook: About Face 3: The Essentials of Interaction Design

I'm not done with that About Face 3: The Essentials of Interaction Design but I'm starting to worry it's going to leave me wishing it had more specific methodologies as opposed to theories. Of course, it has much more methodological attention than The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition) and there's no fault in what is written, only in what is omitted.

If you're really looking for the ultimate how-to, you might want to consider attending the four-day "Cooper U". Case in point: I had the chance to ask Alan Cooper where I could learn more about how to create the design documents he writes about in the last part of The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition) and he really couldn't say what books would be able to instruct that (including his own) and that it would be covered in his course.

I was a well-paid systems administrator/help desk guy until I read this book. This book really did inspire me to change careers!

The book basically outlines why engineers (and people who think like engineers) are INCAPABLE of designing effective interfaces. It delves into specifics and supplies some great examples.

I am amused by some of the reviewers here who display the same sort of arrogant contempt that the book outlines. OF COURSE programming a VCR is easy for YOU--you're a person with an "engineer mind". My mom can't program a VCR at all, and that's not because she didn't try hard enough or read the instructions. She can't use it because everything about it's interface is counter-intuitive to someone who does not understand machine/code logic.

Just because it's easy for you doesn't mean it doesn't stink. Just because it makes sense to you doesn't mean it can't be made better--to work intuitively for "regular" people. Buy this book. Read it. Demand more from your products. It's time to end the insanity.

It's true that some products have poor interfaces, but in my experience this "problem" is blown way out of proportion with reality. The only people I know who couldn't figure out how to program their VCRs were people who did not try for more than 5 minutes. Read the instructions, both in the book and onscreen, and VCR programming is a snap, from the earliest models to today.

I think the real question should be: Why are so many users so lazy? This is more of a social problem than a technological one. Some think that if any effort is required to learn how to use a new device then it's poorly designed. Poppycock!

I've been a programmer for over 25 years, and I think programmers (including me) should read more books like this. Too often, we're driven by our knowledge of what we can do with our languages, data structures, libraries, frameworks, dialog boxes, fonts, colors, etc. We write what's immediately doable given the tools, and lose sight of what would be most desireable. The results are often useful, but unintuitive, inelegant and painful to use. This is why people complain so much about the interfaces of computers, cell phones, PDAs, VCRs, cars, planes, themostats etc.

Alan Cooper argues that the cause of the problem is the culture that creates the products. Programmers are designing today's user interfaces. They naturally design interfaces that they like, so the interfaces are too technical. Cooper suggests a psychological basis for the underlying problem: programmers tend to be interverts that like complexity, so they like complex interfaces. Most programmers are predisposed to expect the human to adjust to the interface. Humans that can't or won't are considered stupid, so they don't really matter. This is many computer interfaces make us feel stupid. Ew're part of the problem, because when an interface fails, we often blame ourselves.

Cooper goes on to describe how to address the problem. One strategy resonated with me: instead of allowing programmers to think in terms of "the user", make them think in terms of several specific, defined, named "personas". This encourages programmers to imagine real interaction between users and an interface, which improves the thinking about the little details that distinguish a useable, boring, frustrating interface from a pleasant, intuitive, helpful interface.

Af course, Alan Cooper does a much better job describing this than I have. I recommend this book highly.

Haven't ever read a book that tackles this issue so well before, and in such an easy to read fashion

I found this book witty, insightful, and usefully applicable to real situations. Cooper writes about the importance of spending time up front to build good software, even if that means throwing away prototypes in favor of rebuilding and fixing the mistakes.

If everyone in the software industry read and understood this book, I think we'd eventually have (1) a lot less software (because junk products wouldn't even make it out the door) and (2) software that works a lot better than what we have now.

I'm sorry to report that Alan Cooper appears to be years out of touch with the software industry. He lobbies for a new 'interaction design' class of professionals working toward designing how the user sees the system - but the industry started doing these things a good 15-20 years ago. Also, he assertions that "in software, typically nothing is visible until it is done" is just plain wrong today; 20 years ago that was true but the software industry today uses storyboards, paper usability reviews, UI mockups, prototypes, etc all with the intent of designing a user friendly interface before the first line of code is written. He starts off with flawed assumptions and ignorance and goes downhill from there.

For simple entertainment value and getting to vent frustration about bad systems I give the book 1 star, but if you're actually serious about understanding and improving software development, you're much better off reading any of a handful of books about "use case analysis".

Cooper's observations are right on. Many books on interaction design deal mainly with design examples and methods. "Inmates" has some of that, but the best part focuses on IT business culture, and the obstacles it poses for creating usable and desirable software and websites. It's a passionate, eloquent, 'non-sugar coated' manifesto for software that doesn't make people feel stupid, and what's needed to make that happen.

Out of the many interaction design related books I've read, this is the one I'd recommend for anyone involved in creating software or websites in a corporate setting.

From the book: "Managers know that software development follows Parkinson's Law: Work will expand to fill the time alloted to it." This is such an outdated idea and method for managers to deal with software engineers the rest of the book was tainted for me by his obvious distain for software engineers. Only the worst kind of un-trusting manager would assume that his engineers will naturally drag their feet if the schedule allows it.

Another example of his contempt for programmers: "All of the analysis and careful thinking done by high-powered and high-priced executives is made moot by the unilateral cherry picking of a programmer following his own muse or defending his turf."

Sorry but the white button down shirt wearing, schedule dictating, programmer dis-trusting manager has no place in software development nor writing books telling me how to manage my software engineers.

Every once in a while you'll read a book or part of a book that completely shifts your thinking. This is one of those books. Alan Cooper (father of Visual Basic) presents for us a litany of horrific examples of interface design, and lays out the case for why spending time and money up front on usability and interaction design will produce the greatest returns of all the steps in software development. But the paradigm shift occurs in Chapters 9 and 10, "Designing for Pleasure", "Designing for Power", where Cooper hits home the power of the user-centered design process and illustrates the inherent mistakes which almost all software developers make during development. Here's a hint: if you start with requirements specifications, you're already screwed.

I thank God that people like Alan take the time to write their wisdom in an easy to grasp book. We are talking years of hard won experience and true expertise in the field, and it's all put down in 220 pages.
Reading this book is like doing time-travel. You spend 3 days and you gain 20 years.

This is really an excellent argument (because that's what it is) about the need for a trained set of fols to do "user experience design" instead of just code. He's absolutely right. The trouble is that most folks that call themselves "user experience" are actually just coders with a fancy label.

An excellent read and very well written. Alan walks you eloquently through the issues that plague the industry and defines common sense practice for good interaction design. Valuable lessens seep from each page. Unfortunately, 6 years after the release the industry is still suffering from those with too much skin in the game and resist the light of change. The book is a wake up call for the industry to practice more K.I.S.S. development and adds clarity to the reason why Software companies are fueling their Tech Support bonfires with poor design implementation.

The high-tech industry has inadvertently put programmers and engineers in charge, so their hard-to-use engineering culture dominates. In our rush to accept the many benefits of the silicon chip, we have abdicated our responsibilities. We have let the inmates run the asylum. When the inmates run the asylum, it is hard for them to see clearly the nature of the problems that bedevil them. When you look in the mirror, it is all too easy to single out your best features and overlook the warts. When the creators of the software-based products examine their handiwork, they overlook how bad it is. Instead they see its awesome power and flexibility. Programming is such a difficult and absorbing task, that it dominates all other considerations, including the concerns of the users. Programmers aren't evil. They work hard to make their software easy to use. Unfortunately, their frame of reference is themselves, so they only make it easy to use for other software engineers, not for normal human beings. Why high tech products drive us crazy and how to restore the sanity? This is what this book is about.

Because it is far cheaper for manufacturers to use computers to control the internal functioning of devices than it is to use older, mechanical methods, it is economically inevitable that computers will insinuate themselves into every product and service in our lives. This means that the behaviour of all of our products will soon be the same as most obnoxious computers, unless we try something different. The incredible power of computers means that few people can afford to ignore them. Even if you don't have a desktop computer, you probably own a VCR and an ATM card, which are software-based products. It is unrealistic to simply say you "won't use computers". They aren't just getting cheaper; they are getting ridiculously cheaper, to the point of ubiquity and disposability. Many familiar products that we imagine as mechanical (or electronic) are no longer made without computers. Cars, washing machines, televisions, vacuum cleaners, thermostats and elevators are all good examples.

This book is written with humour, liveliness, and amusement, it has a lot of funny illustrations. Yet it reveals the problems of software industry which were left attention for decades. One of the problem is "elastic user", such a user which must bend and stretch and adapt to the needs of the moment. When a company speaks about the software it develops, every party involved (management, programmers, testers, sales) include different meaning into the word "user". In "Goal-Directed design", the participants never refer to "the user". Instead, they refer to a very specific individual: "a persona". To create a product that must satisfy a broad audience of users, logic will tell you to make it as broad in its functionality as possible to accommodate the most people. Logic is wrong. You will have far greater success by designing for one single person. Imagine that you were designing an automobile to please a wide spectrum of people. You could easily identify at least three subgroups: the soccer mom, the carpenter, and the junior executive. Mom wants a safe, stable vehicle with lots of space and big doors for hauling the kids, dogs, groceries and other stuff. The carpenter wants a rugged vehicle with all-wheel drive and abundant room for ladders, lumber, bags of cement, and tools. The young executive wants a sporty car with a powerful engine, stiff suspension, convertible top and only enough room for too. If we make such a combination vehicle, what a goofy, impossible car will appear! Making three different products in software is lot easier than making them in steel, too. Another problem which the author points to is "the customer-driven death spiral", where "conceptual integrity" is the only solution.

The author declares that the key to solving the problems is interaction design, and exposes the Goal-Directed design method that provides manufacturers of high tech products with an insightful understanding of their users and a practical blueprint for a superior result. Alan Cooper, the author of the book, and his company, have designed a wide range of products ranging from clean, simple kiosk systems to complex scientific applications, controls for consumer-oriented computer peripherals, conceptual designs for entire product lines, eCommerce sites. The list of companies that adopted the Goal-Directed design includes many industry leaders, large and small, such as 3M, Proctor & Gamble, Dolby Labs, Fujitsu, HP, Informatica, Logitech, SAP, Charles Schwab, St. Jude Medical, and Varian. The description of Goal-Directed design in this book is very reader-friendly and is targeted to the broad audience. Alan Cooper gives the further explanation of this method in his following book "About Face 2.0", aimed mostly to the engineers. Although these two books are still not enough to deploy this method in your organisation, they show how vital this technique is for a successful product.

I enjoyed this book a great deal. It has a wonderful mix of humor, information and just good book structure. It is a must read for everyone that is, works with programmers, or uses the final products of programmers. Essentially, anyone who could be reading this review.

Where some UI authors drone on about why everything is bad and they're so smart but give little proof of that, Cooper makes you laugh at what is wrong and then offers multiple solutions to the problems. It's entertaining and refreshingly current without throwing out the past, bloating his ego or boring you with page after page of going-to-get-to-my-point-any-second-now writing. His insights into the various situations that plague the computer industry are quite good and his solutions are sound. It's high time companies start re-structuring, since bad program design is getting into nearly everything that is controlled with electricity.

Other good things about the book are the care at which the sections are thought out and the brevity of each section. In most chapters he knows when to shut up and get on to the next point. And the next point is most often a nice progression from the previous, and so on. The flow is very good and the points are well made.

It isn't without its troubles but when for instance he repeats himself, it isn't as bad as many authors.. It is often to recap, reference back, say just in case the reader has not read the previous telling, or for the effect of restating so obviously.

Also for me personally, it made me realize some of the things that I've done in my work are better practices than I'd thought.. and things that I've felt iffy about are confirmed bad by his experience and opinion. Altogether, helpful.

It takes a lot of nerve to be the man behind Visual Basic and still claim to know how to "fix" computer programming (what virus threat?)

Inmates is a funny book to read (as the title indicates), but it is also likely to offend a few people (as seen by the mixed reviews). It is NOT a "how to do things differently" book - but a WHY should we do things differently book. As such it is naturally biased for his point of view: computers are popping up more and more places, becoming faster and faster, yet it still takes the average person more time to do his tasks.

This book is not the only way to improve your products, Extreme Programming is another "mindset" that brings a new approach to involving users and their need in the development. It is still a useful input, if management is unable/unwilling to understand that TTT (things take time) - and should be planned accordingly.

The main take-away: have the guts to think, plan and design BEFORE someone starts building (as one quoted programmer says: Hey, you don't want to control me - you want to give me a huge and interesting challenge!!!)

In one of the opening sentences, Cooper uses Albert Einstein's quote "You can't solve a problem with the same thinking that created it" as a supporting claim for why it would be desirable for the tech industry to adopt his goal-directed design method. The method relies on visualizing hypothetical, but very specific users (like Joe Black who works at McDonald, likes his coffee black, wears black underwear and cannot stand the sound of the cash register in the morning) and thinking in terms of how these "personas" would accomplish their goals with the application you are designing. Having worked in the industry for many years, I can sort of see how this method can supplement some of the more rigorous design methodologies that you'd see in companies today, but contrary to the hype, I don't think it will shift your development into high gear or make any significant impact on your production. For one, the main design problem he is solving seems to merely exists in his book (which incidentally makes the Albert Einstein quote more relevant).

Slightly exaggerated, the book almost reads like this: "There exists badly written software in the world... engineers are to blame...don't trust marketing... random fictitious thoughts ... use goal-directed design method because it will save you money..." I doubt that any competent manager would ever consider investing into a design methodology that is guaranteed to cause hostility between engineering, marketing and interaction design team.

The simple language and somewhat unique humor definitely make this book an easy read (passes the cognitive friction test -- shouldn't take you more than few hours to go through) but be cautious of the parts where Cooper attempts to make universally true points. One of the many things that threw me off was the part where he suggests that the designer should abandon his sense of logic. For example, page 68, "It is all so logical, yet it is all so wrong", Cooper tries to explain that illogical approach yields the right design in some cases. These types of statements make it somewhat hard to follow the reasoning in the book. Another worrisome thing is the number of inconsistencies throughout the book. For example, in one part he advocates the idea that humans generally don't make decisions in the same way that computers do as a way of arguing that software should respect the user's decision and therefore not prompt him with a confirmation dialog (huh?). In other part of the book, he complains about a system that didn't warn a user. Similarly, in one instance, he argues that "specificity" of personas (imaginary characters) is the active ingredient without which the value is lost. On the other hand when he talks about a case study where they had to create personas he says "Each of the four passenger personas was an archetype in its own way, representing a broad segment of users."

Shortly after you get into the book, you realize that Cooper is simply following his own formula to sell his gumbo. He clearly identified a very specific persona as the audience (wouldn't be surprised if he called him Alan, -- oh.. but it's forbidden to use "real" people when creating personas.. see chapter 9). Using his model, all we'd need is a single imaginary person who has the need and desirability for the book. Having found this person, the viability or the product is almost given. (I can't believe the humans have been so mindless not to think of this before!)

The only way to save money from this book is by not buying it.

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.

I work for a large computer company that makes software. This book was instrumental in creating and organizing our human interface engineering department.

I don't think you can put a price tag on the amount of damage this book and the attitude it promotes has cost us.

On the one hand, the examples presented are insightful and on target; on the other hand, Mr. Cooper is a usability consultant, and his goal is to convince you that you need a usability consultant. My company drank the kool-aid, and has even paid for training services based on his work.

Part of convincing you that you need a usability consultant is convincing you that your programmers will be congenitally incapable of doing good UI without one.

Now, of course, human interface engineering departments eat that up, since it justifies their existence. Human interface engineering departments are a Good Thing. Having two teams (which must collaborate on producing a product that the market will want) at each others throats, waging political wars and each casually making the assumption that the other is incompetent does not lead to an effective organization. But it is the organization that Mr. Cooper's advice can easily lead to.

I can say categorically that our product's user interface is *worse*, not better, as a result of the attitudes Mr. Cooper promotes - not due to inattention, but due to the fact that in many cases were everyone agreed improvement was needed, the mutual animosity between the HIE department and the Development department was so great that the decision ended in a stalemate and nothing was done. We are only now pulling away from that era.

Read it warily, if you are thinking about how to set up your organization, and remember that it is written with an agenda that may not be set up to benefit you.

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.

Cooper gets it. He understands that computers and electronics are designed by engineeers, for engineers. But what if you want to design something for the masses? Not just something they will use, but something they will enjoy?

Cooper has the idea. If you want to design for "normal" people, you need to put yourself in their shoes. In this bible of high-tech product design, Cooper gives you tools that helps you design products for your target customers. This isn't just a bunch of recipes for GUIs and wizards, but a way to think about how people actually use your tools.

I know Cooper's techniques work. I have adopted them across my software development team, and the difference is astounding. Bottom line: If you're involved in high-tech development, design, or marketing, you need this book.

This book actually starts out nicely up until the point where it turns into a high-pitched whine about everything that the author hates. The content is highly subjective, full of cliches such as "what do you get when you cross a computer and an alarm clock" or constant reptitious nags about why engineers are incompetent when it comes to things that matter. It is laughable to think that an engineer-turn-interaction-designer would come to hate so much what he used to be. On the positive side, the book can be considered a slight improvement from some of the things we had seen from this author in the past (Visual Basic being one i.e. a programming language for minimalists -- almost never used for serious projects in the software industry and to most people utterly useless)

Just as the arugument used in the book to say that bad user interaction design stems from letting the engineers (or according to the book's confusing terminology "apologists" or non-solution-oriented people) control dedcision making processes, the same can be said of the overly simplistic often vague interpretations of the world given by the people highly praised in the book (referred to as "survivors"). As can be seen from the first few chapters in the book, the book speculates about things and provides no real facts or knowledge. Perhaps some research notes or real life cases would help.

I would suggest looking for a more authorative source of what constitutes a good user design if you are looking to learn more on this subject. Find an author with more academic and industry backing.

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.

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.

Super book. I've been involved on the business side of web, portal and content management software projects for many years; this is the best argument on the market for bringing designers in early and streamlining your approach to developing software features, understanding user requirements, and keeping the dev team and customers all on the same page. Don't build another application without it!

I found I really had to force myself to finish reading this book. The core concepts are covered in the first half of the book, albeit in a rather drawn out fashion, and the rest is simply reiteration and self-congratulatory rambling about the author's own successes and consulting business, masquerading under a thin guise of case studies.

If the essence of this book could be distilled down into a 50 pager you'd have a winner.

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.

This is a good book that i read last month. I wanted to write it but thanks that Alan did it. so i think this is a common problem felt by all usability engineers. Everything he has said is a fact. We hope that someday usability becomes a part of software process and a required department like QA, Engineering, etc. ...

Alan Cooper has some great points about how difficult high-tech products can be and particularly how they don't need to be that way. As a tech head, I see myself getting caught up in the mode of cooler and more challenging. Alan made the point about programmer's being just like elite mountain climbers tackling a new mountain. They do it for the sport. It isn't about making it easier. It is about tackling a HARD problem. I've chuckled to myself at work several times when I see this happening now.

Another of my favorite points he makes is about how we never give our users instant satisfaction. They have to invest a great deal into using our products. This locks out so many people and is unnecessary most of the time.

Now, just as a caution, I know many folks that will be offended by Alan's tone at times. Read this for its many great points; ignore what sometimes tends towards fanaticism -- he's just passionate about his topic.

I found this book to be an excellent review of design problems but it left me asking HOW HOW HOW? The author would tell me what NOT to do, but then shy away from telling me what TO do. He would outline a problem very eloquently, but then not tell me exactly how to solve it. "We must design for the users!" Um... yeah. HOW?

If you have no clue about the problems that Interaction Designers face, read this book. If you are already an Interaction Designer, don't bother. I really hope there's a sequel in the works entitled "The Interaction Designers are Running the Design Process: How To Solve Your Design Problems" with lots of concrete examples and positive, rather than negative, design rules. Frustrating.

And why not? As the Web matures it's becoming clear that it's a software platform not just a "new medium." Cooper's fundamental philosophy -- Goal Oriented, Task Based, Personas, Scenarios, etc. -- is easily translated for the creation, programming and deployment of Web-based applications and Web sites; including extended Internet developments that reach far beyond the wired Web.

If more Web shops had adopted Cooper's philosophy and design principles, well there'd be more Web shops. Ha!

This book rocks! It should be read by everyone involved in the cycle of software-based products. From managers to marketing people and of course, us developers. It states clearly that a software should make user's life easier and not vice-versa. It's a must! It also says how to accomplish that, which is very important and is hard to find in other books for software design. I'm about to read the other book that was also written by Cooper 'About Face'.

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.

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.

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.