What do you think?
Rate this book
The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
In this book about the darker side of technology's impact on our lives, Alan Cooper begins by explaining that unlike other devices throughout history, computers have a "meta function": an unwanted, unforeseen option that users may accidentally invoke with what they thought was a normal keystroke. Cooper details many of these meta functions to explain his central thesis: programmers need to seriously re-evaluate the many user-hostile concepts deeply embedded within the software development process.
Rather than provide users with a straightforward set of options, programmers often pile on the bells and whistles and ignore or de-prioritise lingering bugs. For the average user, increased functionality is a great burden, adding to the recurrent chorus that plays: "computers are hard, mysterious, unwieldy things." (An average user, Cooper asserts, who doesn't think that way or who has memorised all the esoteric commands and now lords it over others, has simply been desensitised by too many years of badly designed software.)
Cooper's writing style is often overblown, with a pantheon of cutesy terminology (i.e. "dancing bearware") and insider back-patting. (When presenting software to Bill Gates, he reports that Gates replied: "How did you do that?" to which he writes: "I love stumping Bill!") More seriously, he is also unable to see beyond software development's importance--a sin he accuses programmers of throughout the book.
Even with that in mind, the central questions Cooper asks are too important to ignore: Are we making users happier? Are we improving the process by which they get work done? Are we making their work hours more effective? Cooper looks to programmers, business managers and what he calls "interaction designers" to question current assumptions and mindsets. Plainly, he asserts that the goal of computer usage should be "not to make anyone feel stupid." Our distance from that goal reinforces the need to rethink entrenched priorities in software planning. -- Jennifer Buckendorff, Amazon.com
255 pages, Paperback
First published March 23, 1999
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 196 reviews
June 27, 2010
As a software developer, this book's thesis -- that software should be designed before it's written, by people other than the people writing it -- was a revelation. It's such an obvious observation in hindsight that you might be surprised to learn that software development isn't done this way. It's not, and it's because the inmates (software developers) are allowed to drive the product development process. Cooper makes an impassioned plea to the business world to bring software development under the same standards and practices that have been forever used in physical design, manufacturing, architecture, construction, civil engineering, and every other discipline where a team of individuals creates something.
Before I began reading, I was afraid that Cooper was a Luddite, or that he just distrusted programming in general. Nothing could be further from the truth: Cooper was a programmer himself for a few decades before becoming so fed up with the bad user interactions he was creating that he decided to confront the problem head on. When he talks about the lack of design, he means "user interaction design" -- he has a lot of respect for the difficult and separate problem of software design. It's precisely because writing software is so difficult, and so poorly understood by most business people, that software developers have such a disproportionate role in current user-interaction design (to the extent that it exists). That it's usually done as an afterthought, by people in no way representative of a normal computer user, is the chief reason that human-computer interaction is so woefully bad in most consumer software. It's even worse in business-internal software, when users are literally paid to put up with the aggravation.
I don't know if this would resonate as strongly with a non-programmer audience, but if you want to understand why you hate using your computer, why it makes you feel stupid, why it won't just do what you want, you should read this book.
Before I began reading, I was afraid that Cooper was a Luddite, or that he just distrusted programming in general. Nothing could be further from the truth: Cooper was a programmer himself for a few decades before becoming so fed up with the bad user interactions he was creating that he decided to confront the problem head on. When he talks about the lack of design, he means "user interaction design" -- he has a lot of respect for the difficult and separate problem of software design. It's precisely because writing software is so difficult, and so poorly understood by most business people, that software developers have such a disproportionate role in current user-interaction design (to the extent that it exists). That it's usually done as an afterthought, by people in no way representative of a normal computer user, is the chief reason that human-computer interaction is so woefully bad in most consumer software. It's even worse in business-internal software, when users are literally paid to put up with the aggravation.
I don't know if this would resonate as strongly with a non-programmer audience, but if you want to understand why you hate using your computer, why it makes you feel stupid, why it won't just do what you want, you should read this book.
July 1, 2013
Inmates is all about design. Bad design is rife in the computer technology arena according to Cooper. That’s true, especially when the book was published in 2004 (for those who don’t realize, this is before the iPhone, the Kindle, YouTube, and Gmail. Everyone was on Windows XP, and iTunes was one year old). Cooper hates bad computer design. I mean REALLY HATES bad computer design. He has so much nerdrage against programmers that he calls them at various points in the book “sadistic”, “unreasonable”, “ridiculous”, and non- human (though that last one is supposed to be ironic). I found this off-putting. You can hate bad UI all you like, but if you are so focused on disliking it you will alienate your audience. I felt like I was reading YouTube comments.
In spite of Cooper’s venomous speech, he did have some good ideas near the end of the book. These were my takeaways from the book:
1. Design needs to be goal-oriented rather than task-oriented. That is, what a user trying to accomplish rather than what process used should be the focus.
2. Be specific about who you are programming for. If you try to please everybody you will please nobody, so please a specific type of person.
3. Ease of use should trump features. Adding features that are hard to use is not adding value, it is adding frustration.
In spite of Cooper’s venomous speech, he did have some good ideas near the end of the book. These were my takeaways from the book:
1. Design needs to be goal-oriented rather than task-oriented. That is, what a user trying to accomplish rather than what process used should be the focus.
2. Be specific about who you are programming for. If you try to please everybody you will please nobody, so please a specific type of person.
3. Ease of use should trump features. Adding features that are hard to use is not adding value, it is adding frustration.
January 23, 2015
I found this book frustrating. It's has a number of great design insights, but they are mixed with some truly awful advice on what programmers are like and how to build software, that I would hesitate to recommend it to any "business" person (the audience identified in the preface), as the advice in this book may cause more problems than it solves.
Pros:
* Good discussion of how programming is not like manufacturing or building physical goods.
* Love the ideas behind where software design goes wrong. E.g. the needs of a computer and a user are very different, and that trying to satisfy both as a programmer inherently creates conflict; physical device has one concrete use for every part, but software may have different "modes" for each part; physical products have inherent limits on the number of "features", whereas software doesn't; treating the interface as something you slap on later is a recipe for failure.
* The ideas behind using personas, scenarios, and building software to accomplish goals (not tasks) are very powerful.
* I'm a big fan of the concept that software should be "polite" and the examples that go with it.
Cons:
* Treats software as the sole exemplar of bad design. In reality, there is bad design everywhere. Only reason some mechanical systems are better designed is a) they've had way more time to develop those design practices and b) most mechanical devices are much simpler than software systems.
* Claims that computer literacy shouldn't be a requirement of using computers. That's like saying knowing how to read shouldn't be a requirement of using books.
* The author is WAY too dismissive of iterative development and "ship early and often". He claims that a) no good design has ever come from being iterative, b) 1 year release cycles are too fast for meaningful design, and b) software should be built like movies, with a massive "pre-production" phase where you do a huge, detailed, up front design. This is completely counter to everything we've learned about software development in the last 20 years and should be largely ignored. Every single good design is the result of enormous amounts of iteration and every good piece of software has evolved from something much smaller and simpler.
* Repetitive. The first 9 chapters (more than half the book) are about all the things that are wrong with design today. That's a bit too much.
* Very disrespectful of programmers, especially in part 3 of the book. Describes programmers almost as a different species, using lots of stereotypes. In fact, at points, the book seems to use the word "programmer" as a synonym for "someone who is a terrible designer." Even makes the absurd claim that bad UI is just the way nerds are getting revenge against jocks. Seriously?
Overall: skim quickly for the excellent design advice, and ignore all the horrible parts on how to run software projects or what programmers are like.
Good quotes from the book:
Reducing the cost of programming is not the same as reducing the cost of manufacturing. It's more like giving cheap tools to your workers than it is like giving the workers smaller paychecks. The companies that are shipping programming jobs overseas in order to pay reduced salaries are missing the point entirely.
Ironically, the best way to increase profitability in the information age is to spend more.
Treating any aspect of software design and construction as if it were a manufacturing process courts failure.
In all other construction disciplines, engineers plan a construction strategy that craftsmen execute. Engineers don't build bridges; ironworkers do. Only in software is the engineer tasked with actually building the product. Only in software is the “ironworker” tasked with determining how the product will be constructed. Only in software are these two tasks performed concurrently instead of sequentially. But companies that build software seem totally unaware of the anomaly.
I believe that there are two kinds of executives: those who are engineers, and those who are terrified of engineers.
Communications can be precise and exacting while still being tragically wrong.
To be a good programmer, one must be sympathetic to the nature and needs of the computer. But the nature and needs of the computer are utterly alien from the nature and needs of the human being who will eventually use it. The creation of software is so intellectually demanding, so all-consuming, that programmers must completely immerse themselves in an equally alien thought process. In the programmer's mind, the demands of the programming process not only supersede any demands from the outside world of users, but the very languages of the two worlds are at odds with each other.
The process of programming subverts the process of making easy-to-use products for the simple reason that the goals of the programmer and the goals of the user are dramatically different. The programmer wants the construction process to be smooth and easy. The user wants the interaction with the program to be smooth and easy. These two objectives almost never result in the same program.
Playing a violin is extremely difficult but low in cognitive friction because—although a violinist manipulates it in very complex and sophisticated ways—the violin never enters a “meta” state in which various inputs make it sound like a tuba or a bell. The violin's behavior is always predictable—though complex—and obeys physical laws, even while being quite difficult to control. In contrast, a microwave oven has a lot of cognitive friction, because the 10 number keys on the control panel can be put into one of two contexts, or modes. In one mode they control the intensity of the radiation, and in the other they control the duration. This dramatic change, along with the lack of sensory feedback about the oven's changed state, results in high cognitive friction.
I prefer the term interaction design to the term interface design because “interface” suggests that you have code over here, people over there, and an interface in between that passes messages between them. It implies that only the interface is answerable to the users' needs. The consequence of isolating design at the interface level is that it licenses programmers to reason like this: “I can code as I please because an 'interface' will be slapped on after I'm done.” It postpones design until after programming, when it is too late.
Like putting an Armani suit on Attila the Hun, interface design only tells how to dress up an existing behavior.
The number-one goal of all computer users is to not feel stupid
The prodigious gifts of silicon are so overwhelming that we find it easy to ignore the collateral costs. If you are stranded on a deserted island, you don't care much that your rescue ship is a leaky, rat-infested hulk. The difference between having a software solution for your problem and not having any solution is so great that we accept any hardship or difficulty that the solution might force on us.
Most software vendors don't know how to make their programs easy to use, but they sure know how to add features, so that is what they do.
Physical objects, such as my Swiss Army knife, are subject to a natural brake on the proliferation of marginal features. Each new blade or accessory costs money for the manufacturer to build into the knife. The maker of the knife knows this, and each proposed new feature must pass a gauntlet of justification before it makes it into a shipping product. In engineering terms, this is called a _negative feedback loop_, in which intrinsic forces trend toward stability and equilibrium.
Software architect Scott McGregor points out that Gresham's Law—that bad currency drives out good—is also relevant here. If there are two currencies, people will hoard the good one and try to spend the bad one. Eventually, only the bad currency circulates. Similarly, bad schedule estimates drive out good ones. If everybody makes bogus but rosy predictions, the one manager giving realistic but longer estimates will appear to be a heel-dragger and will be pressured to revise his estimates downward.
Most product managers that I have worked with would rather ship a failure on time than risk going late.
It has been said that the way Stalin cleared a minefield was to march a regiment through it. Effective? Yes. Efficient, humanitarian, viable, desirable? No.
I am not saying that you cannot learn from trial and error, but those trials should be informed by something more than random chance and should begin from a well-thought-out solution, not an overnight hack. Otherwise, it's just giving lazy or ignorant businesspeople license to abuse consumers.
It is more costly in the long run to have programmers write the wrong thing than to write nothing at all. This truth is so counterintuitive that most managers balk at the very idea. After code is written, it is very difficult to throw it out. Like writers in love with their prose, programmers tend to have emotional attachments to their algorithms. Altering programs in midstride upsets the development process and wounds the code, too. It's hard on the manager to discard code because she is the one who paid dearly for it, and she knows she will have to spend even more to replace it.
Develop a precise description of our user and what he wishes to accomplish.
The broader a target you aim for, the more certainty you have of missing the bull's-eye. If you want to achieve a product-satisfaction level of 50%, you cannot do it by making a large population 50% happy with your product. You can only accomplish it by singling out 50% of the people and striving to make them 100% happy. It goes further than that. You can create an even bigger success by targeting 10% of your market and working to make them 100% _ecstatic_. It might seem counterintuitive, but designing for a _single user_ is the most effective way to satisfy a broad population.
Giving the persona a name is one of the most important parts of successfully defining one. _A persona without a name is simply not useful_. Without a name, a persona will never be a concrete individual in anyone's mind.
There is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable. For example, to travel from St. Louis to San Francisco, my goals are speed, comfort, and safety. Heading for the California gold fields in 1850, I would have made the journey in my new, high-tech Conestoga wagon. In the interest of safety, I would have brought my Winchester rifle. Heading from St. Louis to the Silicon Valley in 1999, I would make the journey in a new, high-tech Boeing 777.
Designing from tasks instead of goals is one of the main causes of frustrating and ineffective interaction.
One important implication of the research is remarkably profound: If we want users to like our software, we should design it to behave like a likeable person. If we want users to be productive with our software, we should design it to behave like a good human work mate. Simple, huh?
The program just doesn't care about me and treats me like a stranger even though I'm the only human it knows.
Although the _code_ may succeed or fail in its ability to handle edge cases, the _product_ will succeed or fail in its ability to handle daily use and necessary cases.
From an interaction designer's point of view, the divisions between hardware and software are inconsequential because they are inconsequential to a user. The user doesn't care which is more expensive to build.
In programming, there is always an infinite variety of ways to solve any given problem. Experienced programmers, as they explore their options searching for the optimum solution, occasionally stumble on a technique that allows them to throw out hundreds—or even thousands—of lines of code. This only happens when the programmer has made a valuable conceptual leap forward. When she can toss out lots of code, her program is getting better. Less code means less complexity, fewer bugs, fewer opportunities for invalid interactions, and easier maintainability. Interaction designers share this sensation. As they explore their options, they discover places where they can dispense with entire screens or discard large and complex dialog boxes. The designer knows that each element of the user interface is a burden on the user. Each button and icon is one more thing that the user must know about, and must work around, to get to what she really wants. Doing more with less is always better.
There is a big difference between _listening to_ and _following_ your customers. Listening is good. It means applying your own filter to what you have heard. Following is bad. It means merely doing what your customers tell you to do.
The customer might have money, but it lacks two vital things: It doesn't have your best, long-term interests at heart, and it doesn't know how to design your product.
Pros:
* Good discussion of how programming is not like manufacturing or building physical goods.
* Love the ideas behind where software design goes wrong. E.g. the needs of a computer and a user are very different, and that trying to satisfy both as a programmer inherently creates conflict; physical device has one concrete use for every part, but software may have different "modes" for each part; physical products have inherent limits on the number of "features", whereas software doesn't; treating the interface as something you slap on later is a recipe for failure.
* The ideas behind using personas, scenarios, and building software to accomplish goals (not tasks) are very powerful.
* I'm a big fan of the concept that software should be "polite" and the examples that go with it.
Cons:
* Treats software as the sole exemplar of bad design. In reality, there is bad design everywhere. Only reason some mechanical systems are better designed is a) they've had way more time to develop those design practices and b) most mechanical devices are much simpler than software systems.
* Claims that computer literacy shouldn't be a requirement of using computers. That's like saying knowing how to read shouldn't be a requirement of using books.
* The author is WAY too dismissive of iterative development and "ship early and often". He claims that a) no good design has ever come from being iterative, b) 1 year release cycles are too fast for meaningful design, and b) software should be built like movies, with a massive "pre-production" phase where you do a huge, detailed, up front design. This is completely counter to everything we've learned about software development in the last 20 years and should be largely ignored. Every single good design is the result of enormous amounts of iteration and every good piece of software has evolved from something much smaller and simpler.
* Repetitive. The first 9 chapters (more than half the book) are about all the things that are wrong with design today. That's a bit too much.
* Very disrespectful of programmers, especially in part 3 of the book. Describes programmers almost as a different species, using lots of stereotypes. In fact, at points, the book seems to use the word "programmer" as a synonym for "someone who is a terrible designer." Even makes the absurd claim that bad UI is just the way nerds are getting revenge against jocks. Seriously?
Overall: skim quickly for the excellent design advice, and ignore all the horrible parts on how to run software projects or what programmers are like.
Good quotes from the book:
Reducing the cost of programming is not the same as reducing the cost of manufacturing. It's more like giving cheap tools to your workers than it is like giving the workers smaller paychecks. The companies that are shipping programming jobs overseas in order to pay reduced salaries are missing the point entirely.
Ironically, the best way to increase profitability in the information age is to spend more.
Treating any aspect of software design and construction as if it were a manufacturing process courts failure.
In all other construction disciplines, engineers plan a construction strategy that craftsmen execute. Engineers don't build bridges; ironworkers do. Only in software is the engineer tasked with actually building the product. Only in software is the “ironworker” tasked with determining how the product will be constructed. Only in software are these two tasks performed concurrently instead of sequentially. But companies that build software seem totally unaware of the anomaly.
I believe that there are two kinds of executives: those who are engineers, and those who are terrified of engineers.
Communications can be precise and exacting while still being tragically wrong.
To be a good programmer, one must be sympathetic to the nature and needs of the computer. But the nature and needs of the computer are utterly alien from the nature and needs of the human being who will eventually use it. The creation of software is so intellectually demanding, so all-consuming, that programmers must completely immerse themselves in an equally alien thought process. In the programmer's mind, the demands of the programming process not only supersede any demands from the outside world of users, but the very languages of the two worlds are at odds with each other.
The process of programming subverts the process of making easy-to-use products for the simple reason that the goals of the programmer and the goals of the user are dramatically different. The programmer wants the construction process to be smooth and easy. The user wants the interaction with the program to be smooth and easy. These two objectives almost never result in the same program.
Playing a violin is extremely difficult but low in cognitive friction because—although a violinist manipulates it in very complex and sophisticated ways—the violin never enters a “meta” state in which various inputs make it sound like a tuba or a bell. The violin's behavior is always predictable—though complex—and obeys physical laws, even while being quite difficult to control. In contrast, a microwave oven has a lot of cognitive friction, because the 10 number keys on the control panel can be put into one of two contexts, or modes. In one mode they control the intensity of the radiation, and in the other they control the duration. This dramatic change, along with the lack of sensory feedback about the oven's changed state, results in high cognitive friction.
I prefer the term interaction design to the term interface design because “interface” suggests that you have code over here, people over there, and an interface in between that passes messages between them. It implies that only the interface is answerable to the users' needs. The consequence of isolating design at the interface level is that it licenses programmers to reason like this: “I can code as I please because an 'interface' will be slapped on after I'm done.” It postpones design until after programming, when it is too late.
Like putting an Armani suit on Attila the Hun, interface design only tells how to dress up an existing behavior.
The number-one goal of all computer users is to not feel stupid
The prodigious gifts of silicon are so overwhelming that we find it easy to ignore the collateral costs. If you are stranded on a deserted island, you don't care much that your rescue ship is a leaky, rat-infested hulk. The difference between having a software solution for your problem and not having any solution is so great that we accept any hardship or difficulty that the solution might force on us.
Most software vendors don't know how to make their programs easy to use, but they sure know how to add features, so that is what they do.
Physical objects, such as my Swiss Army knife, are subject to a natural brake on the proliferation of marginal features. Each new blade or accessory costs money for the manufacturer to build into the knife. The maker of the knife knows this, and each proposed new feature must pass a gauntlet of justification before it makes it into a shipping product. In engineering terms, this is called a _negative feedback loop_, in which intrinsic forces trend toward stability and equilibrium.
Software architect Scott McGregor points out that Gresham's Law—that bad currency drives out good—is also relevant here. If there are two currencies, people will hoard the good one and try to spend the bad one. Eventually, only the bad currency circulates. Similarly, bad schedule estimates drive out good ones. If everybody makes bogus but rosy predictions, the one manager giving realistic but longer estimates will appear to be a heel-dragger and will be pressured to revise his estimates downward.
Most product managers that I have worked with would rather ship a failure on time than risk going late.
It has been said that the way Stalin cleared a minefield was to march a regiment through it. Effective? Yes. Efficient, humanitarian, viable, desirable? No.
I am not saying that you cannot learn from trial and error, but those trials should be informed by something more than random chance and should begin from a well-thought-out solution, not an overnight hack. Otherwise, it's just giving lazy or ignorant businesspeople license to abuse consumers.
It is more costly in the long run to have programmers write the wrong thing than to write nothing at all. This truth is so counterintuitive that most managers balk at the very idea. After code is written, it is very difficult to throw it out. Like writers in love with their prose, programmers tend to have emotional attachments to their algorithms. Altering programs in midstride upsets the development process and wounds the code, too. It's hard on the manager to discard code because she is the one who paid dearly for it, and she knows she will have to spend even more to replace it.
Develop a precise description of our user and what he wishes to accomplish.
The broader a target you aim for, the more certainty you have of missing the bull's-eye. If you want to achieve a product-satisfaction level of 50%, you cannot do it by making a large population 50% happy with your product. You can only accomplish it by singling out 50% of the people and striving to make them 100% happy. It goes further than that. You can create an even bigger success by targeting 10% of your market and working to make them 100% _ecstatic_. It might seem counterintuitive, but designing for a _single user_ is the most effective way to satisfy a broad population.
Giving the persona a name is one of the most important parts of successfully defining one. _A persona without a name is simply not useful_. Without a name, a persona will never be a concrete individual in anyone's mind.
There is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable. For example, to travel from St. Louis to San Francisco, my goals are speed, comfort, and safety. Heading for the California gold fields in 1850, I would have made the journey in my new, high-tech Conestoga wagon. In the interest of safety, I would have brought my Winchester rifle. Heading from St. Louis to the Silicon Valley in 1999, I would make the journey in a new, high-tech Boeing 777.
Designing from tasks instead of goals is one of the main causes of frustrating and ineffective interaction.
One important implication of the research is remarkably profound: If we want users to like our software, we should design it to behave like a likeable person. If we want users to be productive with our software, we should design it to behave like a good human work mate. Simple, huh?
The program just doesn't care about me and treats me like a stranger even though I'm the only human it knows.
Although the _code_ may succeed or fail in its ability to handle edge cases, the _product_ will succeed or fail in its ability to handle daily use and necessary cases.
From an interaction designer's point of view, the divisions between hardware and software are inconsequential because they are inconsequential to a user. The user doesn't care which is more expensive to build.
In programming, there is always an infinite variety of ways to solve any given problem. Experienced programmers, as they explore their options searching for the optimum solution, occasionally stumble on a technique that allows them to throw out hundreds—or even thousands—of lines of code. This only happens when the programmer has made a valuable conceptual leap forward. When she can toss out lots of code, her program is getting better. Less code means less complexity, fewer bugs, fewer opportunities for invalid interactions, and easier maintainability. Interaction designers share this sensation. As they explore their options, they discover places where they can dispense with entire screens or discard large and complex dialog boxes. The designer knows that each element of the user interface is a burden on the user. Each button and icon is one more thing that the user must know about, and must work around, to get to what she really wants. Doing more with less is always better.
There is a big difference between _listening to_ and _following_ your customers. Listening is good. It means applying your own filter to what you have heard. Following is bad. It means merely doing what your customers tell you to do.
The customer might have money, but it lacks two vital things: It doesn't have your best, long-term interests at heart, and it doesn't know how to design your product.
November 24, 2012
It is not bad book. Many parts are really useful for all programmers. But I think that some parts is unnecessary. The author said CEO and Senior managers can resolve all programming problems. It is a good idea, although may be I think that because I am a developer.
Developers like their work, but unfortunately they can not design any UI. I am sure it is true. Alan provided many efficient tools for creating very qualitative software prototypes. Say more.. The author described a new software development process where UI designers have the major role.
Obviously this process will take a lead position in the future development. Now, we can look as Apple company applies these ideas in its software development process. And it is the right way.
Alan Cooper hopes that as much as possible software companies will use the same methods and ideas. Certainly it is a difficult way. As result good to know that more and more companies are really moving to that aim.
Developers like their work, but unfortunately they can not design any UI. I am sure it is true. Alan provided many efficient tools for creating very qualitative software prototypes. Say more.. The author described a new software development process where UI designers have the major role.
Obviously this process will take a lead position in the future development. Now, we can look as Apple company applies these ideas in its software development process. And it is the right way.
Alan Cooper hopes that as much as possible software companies will use the same methods and ideas. Certainly it is a difficult way. As result good to know that more and more companies are really moving to that aim.
October 2, 2008
This is THE thing that essentially put me on the career path I am on now. Well written, has some funny points, but you don't need a degree in engineering or computer science to understand it. In fact if you want an explanation as to why computers and software can irritate anyone, here is the answer.
September 12, 2020
I wasn’t writing Goodreads reviews back in 2008 when I read this, but I found an email I wrote to a colleague at the time, and I think it qualifies as a review, so I’ll post it here now for the record.
Note that this was years before I went on to get a masters degree in HCI, and yes, I realize the book is recognized as a classic of UX design. My opinion may come across as a bit harsh, but I’ll largely stand by it, with the possible exception of my criticism of personas.
————————————————————————
First, here’s what I agree with Cooper about: Software developers don’t know what users want. This being the case, they shouldn’t try to design the user interface according to the way they would want it if they were the users. Likewise, they shouldn’t try to design it according to “common sense” since my common sense is different from yours, which is different from one customer’s, which is different from another customer’s. So this much we agree on. There should be a solid design done up front, based firmly on customer input, and written down as clear requirements (not suggestions) to the programmers as to how the product must behave.
What I have a problem with is that Cooper thinks that he _does_ know what users want. He seems to think that they want exactly what he personally wants. In every example he uses in the book in which he says “the software should...” do whatever, it’s only his opinion – I don’t see any data suggesting that all, or even most, users would agree with him. A few examples in particular:
The keyless car entry system (p. 25): he doesn’t like the panic button because it makes him feel stupid. Am I supposed to feel bad about that? Sorry, but I don’t. We all make mistakes. You hit the wrong button, okay, you’re embarrassed, because it was your fault, after all. Big deal. I’ve never accidentally hit my panic button in ten years, but it could happen – I’m not laughing at him for making a mistake. I cannot imagine why anyone would care about his next “better” idea for a button: Lock the car but don’t set the alarm? Why? Either you want the car to be broken into or you don’t. As for his final idea, to prevent other people’s keyless entry systems from unlocking his car... okay, I agree that would be bad, except that I have never had this happen in ten years either. Sounds like an edge case to me.
The storage of emails as “threads” rather than individual mails (p. 61): Again, not at all clear that users (other than Cooper) want this. Gmail does this, and Yahoo groups sort of does it now – I don’t like either one. If you want threads, you are talking about a forum with individual topics, not an email program.
The ATM “problem” (p. 68): he wants the words “Withdraw” and “Checking” to be printed on the screen throughout his transaction because he’s confused and has forgotten what he intended to do by the time the machine asks for his confirmation? I guess I’m making it sound silly, but it does even the way that he wrote it.
The “polite” bank balance query (p. 162): If a program recognizes that it might take a long time to give an accurate answer, he wants it to give a _wrong_ answer (“about $500”) first and then give the user the option to wait for the right answer or not. Is he serious? I’ve asked for my balance, and he wants me to click a button to confirm that I really do want to know the actual balance ($503.47) and not just an estimate? This is exactly the kind of software he argues _against_ elsewhere in the book.
The scanner (p. 191): he doesn’t want to have to worry about where the scanner is storing the scanned images, so he wants the software to take care of that for him. He proposes that the scanner software hide the location of the file. The only way to locate it would be to run the scanner software again. What a terrible idea!
There are plenty of other examples where he presumes to know what users want, when in fact it’s just what one user (Cooper) wants. This is the problem with the whole persona idea. He and his “interaction designers” make up these fictional users. Then they presume to know what these characters would want when they use the software. Well, okay, I admit that no one else knows better than the people who actually invented the characters! So where are they getting this information - from actual users? No – from their own personal ideas of how software should work, of course!
Cooper endlessly repeats the term “dancing bearware” for software that he doesn’t like. By this he means that software does its job poorly, but users are impressed that it does its job at all, and thus will forgive its failings. Okay, with this in mind, let’s look at his example of “World Class Cropping” (p. 193). He designed a system where an image has four individual crop handles, one for each side, and this is supposed to be a good thing. But surely one of the most common, if not the absolute most common cropping operation is to crop all four sides at once. With a typical graphics program, this would be done with a single operation, using the dragging rectangle paradigm that he doesn’t like. With his program, it requires four separate steps. Hmm. Oh well, at least the bear is dancing.
And then there’s Cooper’s stereotype of programmers: it becomes tiresome pretty early in the book. His contention seems to be that since we enjoy figuring things out, we purposely make things hard for non-programmers to figure out. Well, I have news for him: Humans are adapted to figuring things out. It’s an instinctive thing that we do. Like all of our behaviors, there’s a wide range among humans, some of us are better at it than others. What we don’t instinctively do is blame the developer when we can’t figure something out. Pre-technology, when humans had trouble climbing a tree or crossing a river, they couldn’t claim that the tree or the river was poorly designed just because they couldn’t figure it out. If it isn’t worth the trouble, fine – give up. I’m a programmer, but I don’t bother recording shows with my VCR because it’s just not that important to me. If it’s truly important to climb the tree or cross the river, there are humans throughout history who have found the right way to accomplish it.
Cooper says that we programmers find it embarrassing to look too closely at personal goals, but he’s the one who’s obsessed with embarrassment, and with the idea that users don’t want to feel that they’re stupid. He anticipates that users might have trouble figuring things out, so he proposes designing software that _under_estimates the intelligence of the users. If that doesn’t make them feel stupid, it might be because they’re too stupid to realize what he’s done!
Finally, regarding his suggestions for how companies should alter their development process - he spends a lot of time trying to convince us that we should do it, but doesn’t explain in practical terms how companies are expected to implement his ideas. He talks about hiring (or designating) interaction designers and not short-changing the up-front design process. So far so good, but he anticipates that we may say that we don’t have time in the schedule to do it, and he’s right – so what’s his solution to this? I suppose we have to hire his consulting firm to find out.
In summary, I’d give the book two stars (out of ten). There are some things I agree with, but most of his methods I don’t, and even for the things I do agree with, he presents them in such an arrogant, presumptuous manner that it wouldn’t be a convincing argument if I didn’t already agree.
Note that this was years before I went on to get a masters degree in HCI, and yes, I realize the book is recognized as a classic of UX design. My opinion may come across as a bit harsh, but I’ll largely stand by it, with the possible exception of my criticism of personas.
————————————————————————
First, here’s what I agree with Cooper about: Software developers don’t know what users want. This being the case, they shouldn’t try to design the user interface according to the way they would want it if they were the users. Likewise, they shouldn’t try to design it according to “common sense” since my common sense is different from yours, which is different from one customer’s, which is different from another customer’s. So this much we agree on. There should be a solid design done up front, based firmly on customer input, and written down as clear requirements (not suggestions) to the programmers as to how the product must behave.
What I have a problem with is that Cooper thinks that he _does_ know what users want. He seems to think that they want exactly what he personally wants. In every example he uses in the book in which he says “the software should...” do whatever, it’s only his opinion – I don’t see any data suggesting that all, or even most, users would agree with him. A few examples in particular:
The keyless car entry system (p. 25): he doesn’t like the panic button because it makes him feel stupid. Am I supposed to feel bad about that? Sorry, but I don’t. We all make mistakes. You hit the wrong button, okay, you’re embarrassed, because it was your fault, after all. Big deal. I’ve never accidentally hit my panic button in ten years, but it could happen – I’m not laughing at him for making a mistake. I cannot imagine why anyone would care about his next “better” idea for a button: Lock the car but don’t set the alarm? Why? Either you want the car to be broken into or you don’t. As for his final idea, to prevent other people’s keyless entry systems from unlocking his car... okay, I agree that would be bad, except that I have never had this happen in ten years either. Sounds like an edge case to me.
The storage of emails as “threads” rather than individual mails (p. 61): Again, not at all clear that users (other than Cooper) want this. Gmail does this, and Yahoo groups sort of does it now – I don’t like either one. If you want threads, you are talking about a forum with individual topics, not an email program.
The ATM “problem” (p. 68): he wants the words “Withdraw” and “Checking” to be printed on the screen throughout his transaction because he’s confused and has forgotten what he intended to do by the time the machine asks for his confirmation? I guess I’m making it sound silly, but it does even the way that he wrote it.
The “polite” bank balance query (p. 162): If a program recognizes that it might take a long time to give an accurate answer, he wants it to give a _wrong_ answer (“about $500”) first and then give the user the option to wait for the right answer or not. Is he serious? I’ve asked for my balance, and he wants me to click a button to confirm that I really do want to know the actual balance ($503.47) and not just an estimate? This is exactly the kind of software he argues _against_ elsewhere in the book.
The scanner (p. 191): he doesn’t want to have to worry about where the scanner is storing the scanned images, so he wants the software to take care of that for him. He proposes that the scanner software hide the location of the file. The only way to locate it would be to run the scanner software again. What a terrible idea!
There are plenty of other examples where he presumes to know what users want, when in fact it’s just what one user (Cooper) wants. This is the problem with the whole persona idea. He and his “interaction designers” make up these fictional users. Then they presume to know what these characters would want when they use the software. Well, okay, I admit that no one else knows better than the people who actually invented the characters! So where are they getting this information - from actual users? No – from their own personal ideas of how software should work, of course!
Cooper endlessly repeats the term “dancing bearware” for software that he doesn’t like. By this he means that software does its job poorly, but users are impressed that it does its job at all, and thus will forgive its failings. Okay, with this in mind, let’s look at his example of “World Class Cropping” (p. 193). He designed a system where an image has four individual crop handles, one for each side, and this is supposed to be a good thing. But surely one of the most common, if not the absolute most common cropping operation is to crop all four sides at once. With a typical graphics program, this would be done with a single operation, using the dragging rectangle paradigm that he doesn’t like. With his program, it requires four separate steps. Hmm. Oh well, at least the bear is dancing.
And then there’s Cooper’s stereotype of programmers: it becomes tiresome pretty early in the book. His contention seems to be that since we enjoy figuring things out, we purposely make things hard for non-programmers to figure out. Well, I have news for him: Humans are adapted to figuring things out. It’s an instinctive thing that we do. Like all of our behaviors, there’s a wide range among humans, some of us are better at it than others. What we don’t instinctively do is blame the developer when we can’t figure something out. Pre-technology, when humans had trouble climbing a tree or crossing a river, they couldn’t claim that the tree or the river was poorly designed just because they couldn’t figure it out. If it isn’t worth the trouble, fine – give up. I’m a programmer, but I don’t bother recording shows with my VCR because it’s just not that important to me. If it’s truly important to climb the tree or cross the river, there are humans throughout history who have found the right way to accomplish it.
Cooper says that we programmers find it embarrassing to look too closely at personal goals, but he’s the one who’s obsessed with embarrassment, and with the idea that users don’t want to feel that they’re stupid. He anticipates that users might have trouble figuring things out, so he proposes designing software that _under_estimates the intelligence of the users. If that doesn’t make them feel stupid, it might be because they’re too stupid to realize what he’s done!
Finally, regarding his suggestions for how companies should alter their development process - he spends a lot of time trying to convince us that we should do it, but doesn’t explain in practical terms how companies are expected to implement his ideas. He talks about hiring (or designating) interaction designers and not short-changing the up-front design process. So far so good, but he anticipates that we may say that we don’t have time in the schedule to do it, and he’s right – so what’s his solution to this? I suppose we have to hire his consulting firm to find out.
In summary, I’d give the book two stars (out of ten). There are some things I agree with, but most of his methods I don’t, and even for the things I do agree with, he presents them in such an arrogant, presumptuous manner that it wouldn’t be a convincing argument if I didn’t already agree.
May 3, 2021
Slightly dated, but still a classic. A must read for anyone in product management and related fields.
January 15, 2009
If this is meant to be the business case for interaction design, it's a pretty sad business case. The ideas are good, but they way it's put is frustrating.
There's some useful material in this book, but it's hard to dig out in the constant noise of Mr Cooper's whining. You could easily scan the first 120 pages, then read about half of the chapters on persona and goals, and you'd have it.
I am left with the taste of BUFD in my mouth too. That may be a misunderstanding, but it seems that we need to have a big interaction design to get it all right, right from the beginning. This is not something I like the idea of.
Yes, interaction design should be handled by pro's. Thanks Alan.
A book to borrow, quickly scan through, then return.
There's some useful material in this book, but it's hard to dig out in the constant noise of Mr Cooper's whining. You could easily scan the first 120 pages, then read about half of the chapters on persona and goals, and you'd have it.
I am left with the taste of BUFD in my mouth too. That may be a misunderstanding, but it seems that we need to have a big interaction design to get it all right, right from the beginning. This is not something I like the idea of.
Yes, interaction design should be handled by pro's. Thanks Alan.
A book to borrow, quickly scan through, then return.
January 15, 2014
Although Alan Cooper’s 1998 book The Inmates are Running the Asylum is now aging, it is still a helpful read for anyone in the software industry that doesn’t accept the importance of interaction design to software. Even if you are someone who does accept ID’s value, if you don’t believe it should happen before implementation begins, and with a separate team of professionals than your developers, then you frankly need to read it. There is no longer any question about the validity of Cooper’s arguments in Inmates. According to the ACM Digital Library, it is cited by at least 231 scholarly and professional articles on design. And if you really do not have any prior exposure to the idea of interaction design, then go buy or borrow it now before I metaphorically smack you on the side of the head.
Perhaps the most validating thing about Inmates from a 2014 perspective is how successful Cooper’s analysis has been in predicting the past ten or fifteen years of software. For example, in one part of the book he case studies Apple and states that although Apple up to then had made every poor business decision imaginable, they remained in business with a dedicated cult following of customers due to the centrality of interaction design to everything they do. He predicts that they will make a comeback. Lo and behold, Apple is a more profitable company than Microsoft today.
If you don’t read books for the truth of their insights, then read Inmates for its entertainment value. With his fond lampooning of software developers as “homo logicus” and his continually humorous anecdotes about poor product design and its impact to his personal life, Cooper keeps things light and drives his points home while avoiding either a know-it-all or boorish attitude. He actually sounds more like a really excited design geek. Inmates reads less as diatribe and more as passionate outpouring.
At any rate, developers and managers of all stripes will benefit from its balanced view, and everyone else involved in software will get more than a few nuggets to think over about their current projects. It’s a nice little book and a great reminder of how interaction design needs to play a central role in software. Four of five stars.
http://code.scottshipp.com/2014/01/09...
Perhaps the most validating thing about Inmates from a 2014 perspective is how successful Cooper’s analysis has been in predicting the past ten or fifteen years of software. For example, in one part of the book he case studies Apple and states that although Apple up to then had made every poor business decision imaginable, they remained in business with a dedicated cult following of customers due to the centrality of interaction design to everything they do. He predicts that they will make a comeback. Lo and behold, Apple is a more profitable company than Microsoft today.
If you don’t read books for the truth of their insights, then read Inmates for its entertainment value. With his fond lampooning of software developers as “homo logicus” and his continually humorous anecdotes about poor product design and its impact to his personal life, Cooper keeps things light and drives his points home while avoiding either a know-it-all or boorish attitude. He actually sounds more like a really excited design geek. Inmates reads less as diatribe and more as passionate outpouring.
At any rate, developers and managers of all stripes will benefit from its balanced view, and everyone else involved in software will get more than a few nuggets to think over about their current projects. It’s a nice little book and a great reminder of how interaction design needs to play a central role in software. Four of five stars.
http://code.scottshipp.com/2014/01/09...
June 16, 2021
I would simply read this book for the very cheeky analogies, metaphors and comparisons that the author has used. Taking potshots in the dark, you cannot shave a table into a chair, painting a corpse, and many more.
Another thing that I love the most about this book is that it is opinionated. The author does not want to be politically correct and he calls a spade a spade. I love such lethal honesty and as expected tons of readers were butt hurt, and thus the low ratings for this book. I love the fact that the author simply tramples on the developers head first. Almost every other developer i have met in my life is head strong, (I was too, when i was coding) and assumes that because he is doing the coding, that the whole world revolves around him and that he is the only person in the project that is useful and all the others are simply butlers to run errands for developers. The author simply puts developer in their place. The world ran when there was no code and the world will run when nobody will have to code - Yes, I am talking about LOW CODE/NO CODE future.
Design exists everywhere, and designers exist everywhere, the discipline of design led product development, design sprints, design thinking, all of them take root in this book. This books seems to be way ahead of its time. The author is a visionary, needless to say, just that he fucked political correctness, and there is at least one paragraph in the book that manages to hurt everyone - including gays, feminists, animal rights activists, programmers, designers, coders, managers, carpenters, tech leads, VPs of companies, CEOs, industrial designers,Usability Testers and many more......
The funny thing is that everything that the author said is true. People have hard time accepting truth that hurts them. Instead if the author could have lied, and praised everybody he could have received all the accolades for his great insights.
There are many take always from this book
1. Don't leave the design work or product scope, product vision, mission or product features or anything related to the product to developers.
2. The changes that you do earlier on the napkin, on paper, on wireframes, on low fidelity mockups, on high fidelity mock ups, on prototypes, on specs will have 10x, 100x, 1000x, 10000x, 100000x respectively while development - the analogy of a movie script to movie pre production and post production is perfect for this use case.
3. The book carefully makes a case for Interaction design, out of which service design, behavioral design, conceptual design and others emerge.
4. The book differentiates between usability testing, industrial design, interface design, and other kinds of designs and explain how interaction design is better than the rest.
Need less to say the industry has changed very must according to the rules written in this book. Now every company does design first and hires designers, before they hire develolpers. I have seen many companies that went coding first, literally go bankrupt before my own eyes. One start up folded in six months, because they literally had no clue what they were doing and were adding features that stakeholders asked for left and right, without any rhyme or reason. I saw another startup add features depending on the customer requests and saw millions go down the drain during the process and shut down. Over time i.e. from working in 5-6 startups i have reached similar conclusions, whenever i see someone going down this foolish path of code first and think later, i warn them about the consequences and quit the project. It is wiser to jump off a leaking ship before it takes you down with it. I worked at Google as a contractor and I have seen first hand how google gets it right every single time, by actually doing the designs, prototypes and Interaction testing, as i worked with them as a UX Research associate.
Every single line in this book is right. Designer time is the most valuable and Redoing or rework will cause maximum damage to the product and the project. Thus I have learned these lessons from my own experience as I became a senior product manager. But if i had read this book as few years, I would have reached these conclusions far sooner and without having to have experienced these bitter truths from one failed startup to the next (though not mine).
This books is extremely useful for any project manager, product manager or CEO or anybody trying to run a digital product.
i loved reading the book from the beginning till the last page. Not a single page was boring or repetitive. The talk about scanner, the talk about cars and keys, all of them reminded me of Dan NormaN'S Design of everyday things.
Here are the keywords from the book.
Books mentioned:
Crossing the chasm
The secrets of consulting
The first twenty million dollars is always the hardest
I sing the body electronic
Skin in the game
Leading geeks
An obsolete culture
Managing the professional service firm
The media equation
How the mind works
Behavioural design
Interaction design
Interface design
Conceptual design
Dancing bear ware
Mother and apple pie
Cognitive friction
Spray and pray method of funding
Throwing away prototypes
Capability vs viability vs desirability
Self referential design
The seven habits of highly engineered people
They are remarkably revealing in their hyperbole
1. They will be generous in their selfishness
2. Blindness improves their vision
3. They will not only bite the hand that feeds them but also their own hand
4. They will very hard to maintain the image that they care very little about their image
5. They will keep fixing what is not broken till it is broken
6. I did not answer incorrectly, you just asked the wrong question
7. They consider absence of criticism a complement
Homo logicus vs Homo sapiens
Programmers are like jocks
Programming culture
Be kind to chips and cruel to users
The media equation - Nas and reeves
How the mind works
Another thing that I love the most about this book is that it is opinionated. The author does not want to be politically correct and he calls a spade a spade. I love such lethal honesty and as expected tons of readers were butt hurt, and thus the low ratings for this book. I love the fact that the author simply tramples on the developers head first. Almost every other developer i have met in my life is head strong, (I was too, when i was coding) and assumes that because he is doing the coding, that the whole world revolves around him and that he is the only person in the project that is useful and all the others are simply butlers to run errands for developers. The author simply puts developer in their place. The world ran when there was no code and the world will run when nobody will have to code - Yes, I am talking about LOW CODE/NO CODE future.
Design exists everywhere, and designers exist everywhere, the discipline of design led product development, design sprints, design thinking, all of them take root in this book. This books seems to be way ahead of its time. The author is a visionary, needless to say, just that he fucked political correctness, and there is at least one paragraph in the book that manages to hurt everyone - including gays, feminists, animal rights activists, programmers, designers, coders, managers, carpenters, tech leads, VPs of companies, CEOs, industrial designers,Usability Testers and many more......
The funny thing is that everything that the author said is true. People have hard time accepting truth that hurts them. Instead if the author could have lied, and praised everybody he could have received all the accolades for his great insights.
There are many take always from this book
1. Don't leave the design work or product scope, product vision, mission or product features or anything related to the product to developers.
2. The changes that you do earlier on the napkin, on paper, on wireframes, on low fidelity mockups, on high fidelity mock ups, on prototypes, on specs will have 10x, 100x, 1000x, 10000x, 100000x respectively while development - the analogy of a movie script to movie pre production and post production is perfect for this use case.
3. The book carefully makes a case for Interaction design, out of which service design, behavioral design, conceptual design and others emerge.
4. The book differentiates between usability testing, industrial design, interface design, and other kinds of designs and explain how interaction design is better than the rest.
Need less to say the industry has changed very must according to the rules written in this book. Now every company does design first and hires designers, before they hire develolpers. I have seen many companies that went coding first, literally go bankrupt before my own eyes. One start up folded in six months, because they literally had no clue what they were doing and were adding features that stakeholders asked for left and right, without any rhyme or reason. I saw another startup add features depending on the customer requests and saw millions go down the drain during the process and shut down. Over time i.e. from working in 5-6 startups i have reached similar conclusions, whenever i see someone going down this foolish path of code first and think later, i warn them about the consequences and quit the project. It is wiser to jump off a leaking ship before it takes you down with it. I worked at Google as a contractor and I have seen first hand how google gets it right every single time, by actually doing the designs, prototypes and Interaction testing, as i worked with them as a UX Research associate.
Every single line in this book is right. Designer time is the most valuable and Redoing or rework will cause maximum damage to the product and the project. Thus I have learned these lessons from my own experience as I became a senior product manager. But if i had read this book as few years, I would have reached these conclusions far sooner and without having to have experienced these bitter truths from one failed startup to the next (though not mine).
This books is extremely useful for any project manager, product manager or CEO or anybody trying to run a digital product.
i loved reading the book from the beginning till the last page. Not a single page was boring or repetitive. The talk about scanner, the talk about cars and keys, all of them reminded me of Dan NormaN'S Design of everyday things.
Here are the keywords from the book.
Books mentioned:
Crossing the chasm
The secrets of consulting
The first twenty million dollars is always the hardest
I sing the body electronic
Skin in the game
Leading geeks
An obsolete culture
Managing the professional service firm
The media equation
How the mind works
Behavioural design
Interaction design
Interface design
Conceptual design
Dancing bear ware
Mother and apple pie
Cognitive friction
Spray and pray method of funding
Throwing away prototypes
Capability vs viability vs desirability
Self referential design
The seven habits of highly engineered people
They are remarkably revealing in their hyperbole
1. They will be generous in their selfishness
2. Blindness improves their vision
3. They will not only bite the hand that feeds them but also their own hand
4. They will very hard to maintain the image that they care very little about their image
5. They will keep fixing what is not broken till it is broken
6. I did not answer incorrectly, you just asked the wrong question
7. They consider absence of criticism a complement
Homo logicus vs Homo sapiens
Programmers are like jocks
Programming culture
Be kind to chips and cruel to users
The media equation - Nas and reeves
How the mind works
September 8, 2010
A classic on user-centered design, especially as it relates to computerized products (that is, most products). Cooper meanders at times, and he spends longer than is now needed to build the business case for moving interaction design out of the hands of programmers. But he's spirited and instructive and (mostly) as relevant as ever.
Now that I'm expand my consulting business into user experience and product development, I got a lot from this book. I look forward to using the tools described in it, including the three "heavy hitters" -- personas, goals, and scenarios -- and others. With the right team, and insights from a few more authors who've followed Cooper's lead, I'm going to find this kind of work challenging and fun. I hope that the result will be products that make a difference in people's lives.
Now that I'm expand my consulting business into user experience and product development, I got a lot from this book. I look forward to using the tools described in it, including the three "heavy hitters" -- personas, goals, and scenarios -- and others. With the right team, and insights from a few more authors who've followed Cooper's lead, I'm going to find this kind of work challenging and fun. I hope that the result will be products that make a difference in people's lives.
June 22, 2012
Read this for the June meeting of the Vancouver User Experience Book Club.
This was one of those "I can't believe it took me so long to read this" type books. I was already well on-board the user-centered design train, but this gave me some new tools to think about and describe the value of UX.
I especially liked the section on Homo Logicus, which I have now been observing everywhere. I definitely have a component of that in myself, so having the concept is a good way to check my own thinking against what a normal human might think.
Another idea from this that's been very powerful is the idea of personal goals, specifically the goal to not feel stupid. I'm trying to ask myself in almost everything I do now: "Will this make someone feel stupid?" If it will, I'll (try to...) find another way.
This was one of those "I can't believe it took me so long to read this" type books. I was already well on-board the user-centered design train, but this gave me some new tools to think about and describe the value of UX.
I especially liked the section on Homo Logicus, which I have now been observing everywhere. I definitely have a component of that in myself, so having the concept is a good way to check my own thinking against what a normal human might think.
Another idea from this that's been very powerful is the idea of personal goals, specifically the goal to not feel stupid. I'm trying to ask myself in almost everything I do now: "Will this make someone feel stupid?" If it will, I'll (try to...) find another way.
May 20, 2017
- old economy: engineer designs a product (bridge), workers are doing construction. new economy: software engineer does both design and construction
- cognitive friction: problems arise from the constantly changing system
- apologists (wow, dancing bear) vs survivors (dancing is hard for the bear, this is the best I can get)
- triangle of capability (engineering), viability (business), desirability (design)
- designing with personas
- task oriented (programmers) vs goal oriented (designers)
- status bar experiment with 50$
- designer is like a doctor who knows how to read x-ray: training required to do it
- making software is like making movies (you should minimize the duration of production phase)
- interaction designer should drive the quality of the product
- cognitive friction: problems arise from the constantly changing system
- apologists (wow, dancing bear) vs survivors (dancing is hard for the bear, this is the best I can get)
- triangle of capability (engineering), viability (business), desirability (design)
- designing with personas
- task oriented (programmers) vs goal oriented (designers)
- status bar experiment with 50$
- designer is like a doctor who knows how to read x-ray: training required to do it
- making software is like making movies (you should minimize the duration of production phase)
- interaction designer should drive the quality of the product
May 3, 2014
A really sexist and insulting quote by Tom Corddry killed an otherwise good book for me: "Designers are invariably female, are talkative, live in lofts, have vegetarian diets , and wear found objects in their hair. Developers are invariably male, eat fast food, ands onto talk except to say, 'Not true'."
Killed it dead.
Killed it dead.
August 23, 2015
No central theme. No focus. Discussions are more religious and with prejudice than with any substance.
September 6, 2013
In The Inmates are Running the Asylum, computer programmer Alan Cooper argues that, in contemporary software development, there has been a lack of attention paid to creating a user-friendly end product. Specifically, he suggests that programmers, who have majority (if not exclusive) control of the finished merchandise, have different objectives than the users for whom the product is meant: programmers care about how the computer "computes" and tend to ignore the ease with which the user can interact with the software. Because user testing is ignored or introduced too late in the process, programmers tend to leave out design elements that would make their products more user-friendly. The theme of the book is that interactive products need to be controlled by interaction designers instead of software engineers, and that this control must begin in the initial stages of the product’s development.
Once Cooper has given an overview of these broad ideas, he proceeds to explore the issue in-depth. In the first several chapters in particular, the author makes it his objective to go over his main points again and again, restating, rephrasing, and looking at the issue from every possible angle. He repeats his conclusions numerous times, based on different types of evidence because, he claims, his suggestions are so unintuitive to those in control of the finished product (the programmers). To this end, he introduces what “bad” software is and shows how the software development process itself leads to these interaction problems. Delving into the nature of the programmers themselves, he argues that their methodology and mindset makes them unsuitable for creating user-friendly programs and discusses why alternatives to interaction designers fail. He then elucidates the role of the interaction designer and ends by emphasizing that managers must force everyone, particularly the programmers, to be obsequious to the interaction designer in order to make their efforts worthwhile.
Cooper’s book is fairly straightforward and he manages to avoid all but the essential technical terms that might confuse a reader. When those technical aspects do creep up in later chapters, his style helps make them more accessible. When reading this, I couldn’t help but make the occasional reference to Edward Said’s Orientalism. In a sense, both authors are attempting to do the same thing: overturn a system that seems intuitively wrong but is difficult to change, due to the entrenched interests/mindsets of the people that are most directly involved with it. Comparing it to Orientalism, however, is giving it far too much credit. As one gets to the end of the book, there is more of a sense that, while the problem he describes is very real, he is also trying to “sell” what he does (he runs an interaction design consulting firm). This comes off most strongly in the way he divides computer users into two groups: if you think things are at all okay the way they are, then you are an apologist. If you can only use the computer to function in the areas that you absolutely must, then you are a survivor. In essence, disagree about the severity or nature of the problem and you are the enemy.
One section that bothered me was “polite behavior”. In discussing ways to think about improving user interaction, Cooper argues that software should be “polite” and explores a number of ways in which this could be possible, but some of what he writes did not work for me. For example, in one of his analogies:
“When I am deeply engaged in intense conversation with my tablemates, I expect the waiter to attend to other duties. It would be highly inappropriate for the waiter to interrupt our discussion to say ‘Hello, my name is Raul, and I’ll be your waitperson for the evening.’ On the other hand, when our table conversation has ended and I am swiveling my head and trying to make eye contact with Raul, I expect him to hustle over to my table”
Cooper does not seem to care if there are other people in the restaurant, and certainly not about the poor guy who is working for minimum wage, in a frustrating job where he routinely gets blamed for things he has no control over, like the quality of the food. He has to multitask and fast; he can’t sit around waiting for you to finish a conversation to take your order. He also can’t drop whatever else it is he is doing when you decide that you are ready. Yes, it is a service industry, but there are other people to serve as well. And I know it is just an imperfect analogy, but it is nevertheless revealing. In another section:
“I don’t want my butcher to tell me on November 21 that he is out of Thanksgiving turkeys. I want to know well in advance that the supply is limited and that I need to place my order early.”
First of all, if you don’t know that the turkey supply becomes limited around Thanksgiving, that’s not the butcher’s fault. Furthermore, unless the butcher is psychic, he is not going to know exactly when his turkeys will run out. At most he can tell you how many he gets in and that common sense dictates that you should buy a Thanksgiving turkey at the earliest reasonable time. Cooper also seems to want everyone to know exactly what he wants and how he wants it, and that includes computers. For example:
“When I order salad in a good restaurant, they bring me a good salad. In a bad restaurant, I get the third degree along with it: ‘Spinach, Caesar, or mixed greens? Onions? Croutons? Grated cheese? Parmesan on the side? Served before or after the main course?’”
Hyperbole aside, how is the waiter supposed to know what you would consider a “good salad”, what foods you don’t like, or what you might be allergic to? Most people would rather sit through a few questions to get a salad that they want than risk getting one that’s no good. Also consider:
“[…] if my assistant can’t book me the flight I want, I expect him to confidently book something very close to the one I want without bothering me with details.”
Because spending 30 seconds listening to a proposal and responding “Yeah, that sounds good” is much worse than being stuck on a 14-hour flight with a crappy airline because your assistant decided that a closer time to your original choice was more important than a reputable airline.
In essence, Cooper does what he criticizes everyone else for doing: he insists that computers be built around what things that he finds important, and then claims to represent everyone. He complains that “software is always whining at me with confirmation dialog boxes”, as if the half-second it takes to confirm is really that big of a problem. I think that there are few, if any, out there who have not encountered a situation where a fritzy computer or accidental click might have led to catastrophe if not for a determined confirmation box. Just the other day, my mouse pointer shot across the screen and tried to close my browser. Had it not been for the confirmation box, I would have had to re-open (not to mention remember) the dozen or so tabs I had. His entire argument is based around the user not being as technically savvy as the programmer, yet he thinks that confirmation boxes that help guide users and avert mistakes are a hindrance. All this is not to say that the section is useless, but some of the examples and analogies he uses do little to strengthen his argument.
He is also too optimistic in believing that there are solutions that can please everyone. In an example dealing with the design of an airplane seat entertainment computer, he decides that the “persona” he is going to design for is an elderly man with arthritis, and that he will include features to (unobtrusively) satisfy the needs of the more technically-advanced customers. First of all, for a guy who does not even want his waiter to try and determine a salad he would like, Cooper is quick to assume that the other “personas” will be happy to jump through a small hoop or two to access the features and usability that the elderly man cannot and will be happy to do so. More importantly, however, his solution, a dial rather than a touch screen, is far from perfect. Anyone who has taken a long airplane flight in recent years probably knows just how easy it is to break a touch entertainment device on a plane. Now, imagine what would happen with a dial, something children, and a lot of bored adults, would fiddle with subconsciously. Over millions of flight hours and customers, how long does he expect that dial to last before it wears off or breaks? Touch screens can be broken of course, but it takes a lot more effort than with a mechanical dial.
In practice, Cooper’s argument boils down to taking software interactivity away from the hands of programmers and putting it into those of interaction designers. On the whole I agree with him and believe that interaction designers have a much better idea of what users want, but it is not as perfect a solution as he suggests. Interaction designers are (as the author himself proves) subjective and imperfect and are simply making very educated guesses that are far superior to those of the programmers. This book was written in 1998 for programmers, to convince them of the importance of a separate (and paramount) process of interaction design. As most users of technology will probably attest, however, the book’s general message is still relevant today, and non-programmers will, if nothing else, gain great insight into why it is that so many products are so non-user friendly. Cooper’s argument is excellent and valuable, but must be taken with a grain of salt as well.
Once Cooper has given an overview of these broad ideas, he proceeds to explore the issue in-depth. In the first several chapters in particular, the author makes it his objective to go over his main points again and again, restating, rephrasing, and looking at the issue from every possible angle. He repeats his conclusions numerous times, based on different types of evidence because, he claims, his suggestions are so unintuitive to those in control of the finished product (the programmers). To this end, he introduces what “bad” software is and shows how the software development process itself leads to these interaction problems. Delving into the nature of the programmers themselves, he argues that their methodology and mindset makes them unsuitable for creating user-friendly programs and discusses why alternatives to interaction designers fail. He then elucidates the role of the interaction designer and ends by emphasizing that managers must force everyone, particularly the programmers, to be obsequious to the interaction designer in order to make their efforts worthwhile.
Cooper’s book is fairly straightforward and he manages to avoid all but the essential technical terms that might confuse a reader. When those technical aspects do creep up in later chapters, his style helps make them more accessible. When reading this, I couldn’t help but make the occasional reference to Edward Said’s Orientalism. In a sense, both authors are attempting to do the same thing: overturn a system that seems intuitively wrong but is difficult to change, due to the entrenched interests/mindsets of the people that are most directly involved with it. Comparing it to Orientalism, however, is giving it far too much credit. As one gets to the end of the book, there is more of a sense that, while the problem he describes is very real, he is also trying to “sell” what he does (he runs an interaction design consulting firm). This comes off most strongly in the way he divides computer users into two groups: if you think things are at all okay the way they are, then you are an apologist. If you can only use the computer to function in the areas that you absolutely must, then you are a survivor. In essence, disagree about the severity or nature of the problem and you are the enemy.
One section that bothered me was “polite behavior”. In discussing ways to think about improving user interaction, Cooper argues that software should be “polite” and explores a number of ways in which this could be possible, but some of what he writes did not work for me. For example, in one of his analogies:
“When I am deeply engaged in intense conversation with my tablemates, I expect the waiter to attend to other duties. It would be highly inappropriate for the waiter to interrupt our discussion to say ‘Hello, my name is Raul, and I’ll be your waitperson for the evening.’ On the other hand, when our table conversation has ended and I am swiveling my head and trying to make eye contact with Raul, I expect him to hustle over to my table”
Cooper does not seem to care if there are other people in the restaurant, and certainly not about the poor guy who is working for minimum wage, in a frustrating job where he routinely gets blamed for things he has no control over, like the quality of the food. He has to multitask and fast; he can’t sit around waiting for you to finish a conversation to take your order. He also can’t drop whatever else it is he is doing when you decide that you are ready. Yes, it is a service industry, but there are other people to serve as well. And I know it is just an imperfect analogy, but it is nevertheless revealing. In another section:
“I don’t want my butcher to tell me on November 21 that he is out of Thanksgiving turkeys. I want to know well in advance that the supply is limited and that I need to place my order early.”
First of all, if you don’t know that the turkey supply becomes limited around Thanksgiving, that’s not the butcher’s fault. Furthermore, unless the butcher is psychic, he is not going to know exactly when his turkeys will run out. At most he can tell you how many he gets in and that common sense dictates that you should buy a Thanksgiving turkey at the earliest reasonable time. Cooper also seems to want everyone to know exactly what he wants and how he wants it, and that includes computers. For example:
“When I order salad in a good restaurant, they bring me a good salad. In a bad restaurant, I get the third degree along with it: ‘Spinach, Caesar, or mixed greens? Onions? Croutons? Grated cheese? Parmesan on the side? Served before or after the main course?’”
Hyperbole aside, how is the waiter supposed to know what you would consider a “good salad”, what foods you don’t like, or what you might be allergic to? Most people would rather sit through a few questions to get a salad that they want than risk getting one that’s no good. Also consider:
“[…] if my assistant can’t book me the flight I want, I expect him to confidently book something very close to the one I want without bothering me with details.”
Because spending 30 seconds listening to a proposal and responding “Yeah, that sounds good” is much worse than being stuck on a 14-hour flight with a crappy airline because your assistant decided that a closer time to your original choice was more important than a reputable airline.
In essence, Cooper does what he criticizes everyone else for doing: he insists that computers be built around what things that he finds important, and then claims to represent everyone. He complains that “software is always whining at me with confirmation dialog boxes”, as if the half-second it takes to confirm is really that big of a problem. I think that there are few, if any, out there who have not encountered a situation where a fritzy computer or accidental click might have led to catastrophe if not for a determined confirmation box. Just the other day, my mouse pointer shot across the screen and tried to close my browser. Had it not been for the confirmation box, I would have had to re-open (not to mention remember) the dozen or so tabs I had. His entire argument is based around the user not being as technically savvy as the programmer, yet he thinks that confirmation boxes that help guide users and avert mistakes are a hindrance. All this is not to say that the section is useless, but some of the examples and analogies he uses do little to strengthen his argument.
He is also too optimistic in believing that there are solutions that can please everyone. In an example dealing with the design of an airplane seat entertainment computer, he decides that the “persona” he is going to design for is an elderly man with arthritis, and that he will include features to (unobtrusively) satisfy the needs of the more technically-advanced customers. First of all, for a guy who does not even want his waiter to try and determine a salad he would like, Cooper is quick to assume that the other “personas” will be happy to jump through a small hoop or two to access the features and usability that the elderly man cannot and will be happy to do so. More importantly, however, his solution, a dial rather than a touch screen, is far from perfect. Anyone who has taken a long airplane flight in recent years probably knows just how easy it is to break a touch entertainment device on a plane. Now, imagine what would happen with a dial, something children, and a lot of bored adults, would fiddle with subconsciously. Over millions of flight hours and customers, how long does he expect that dial to last before it wears off or breaks? Touch screens can be broken of course, but it takes a lot more effort than with a mechanical dial.
In practice, Cooper’s argument boils down to taking software interactivity away from the hands of programmers and putting it into those of interaction designers. On the whole I agree with him and believe that interaction designers have a much better idea of what users want, but it is not as perfect a solution as he suggests. Interaction designers are (as the author himself proves) subjective and imperfect and are simply making very educated guesses that are far superior to those of the programmers. This book was written in 1998 for programmers, to convince them of the importance of a separate (and paramount) process of interaction design. As most users of technology will probably attest, however, the book’s general message is still relevant today, and non-programmers will, if nothing else, gain great insight into why it is that so many products are so non-user friendly. Cooper’s argument is excellent and valuable, but must be taken with a grain of salt as well.
February 21, 2017
Seminal work on interaction design in software; must read if you're in the business of designing software applications for users. I find myself now recognizing (and getting angry with) the pitfalls Cooper railed against in the book, both in my work and in the products with which I interact, which speaks to the impact of the book.
May 17, 2007
The first 2/3's of the book basically detail cautionary tales about products that didn't have sufficient design, or else they make the author's case that design is neglected. These would make great arguments if you had to sell an idea to a manager or development team (or if you felt insecure and needed a hug).
The last third provides some great insight into design practices. I found his suggestions very practical. I wish this section was longer than the first two.
As a software developer at a small company, I found this book very useful for my day-to-day work. Also I highly recommend the similar book "About Face" which details good GUI design (as opposed to general product design, which this book focuses on).
What I don't like about this book is the author's tone. Like most interaction designers, he reminds me of the Mac zealots of old who have all the world's answers. He does have very good points, but he still comes across as pushy and overconfident.
I'm by no means an expert at design, but everyone at our company cares deeply about the subject. I'm frustrated that several authorities on interaction design say it is 'impossible' for programmers -- or indeed for non-experts -- to design well. This book is no exception: he insists programmers have conflicts of interest that keep them from putting the user first. It makes it hard to like him when he insults me; if the book were more programmer-friendly, I'd give this a 4/5. (It's ironic that the book that focuses on emotionally satisfying end users leaves this reader particularly detached.)
But he is a very intelligent and experienced designer, and I'm glad I read the book. Especially the last third.
The last third provides some great insight into design practices. I found his suggestions very practical. I wish this section was longer than the first two.
As a software developer at a small company, I found this book very useful for my day-to-day work. Also I highly recommend the similar book "About Face" which details good GUI design (as opposed to general product design, which this book focuses on).
What I don't like about this book is the author's tone. Like most interaction designers, he reminds me of the Mac zealots of old who have all the world's answers. He does have very good points, but he still comes across as pushy and overconfident.
I'm by no means an expert at design, but everyone at our company cares deeply about the subject. I'm frustrated that several authorities on interaction design say it is 'impossible' for programmers -- or indeed for non-experts -- to design well. This book is no exception: he insists programmers have conflicts of interest that keep them from putting the user first. It makes it hard to like him when he insults me; if the book were more programmer-friendly, I'd give this a 4/5. (It's ironic that the book that focuses on emotionally satisfying end users leaves this reader particularly detached.)
But he is a very intelligent and experienced designer, and I'm glad I read the book. Especially the last third.
August 11, 2008
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.
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.
April 7, 2021
This book speaks absolute truth. Not much has changed in the past 10+ years from the publication of his book, which makes me wonder how effective it was. The tech industry is flawed, but a book is not the solution.
August 6, 2007
This is a kind of parallel volume to Donald A Norman's "Design of Everyday Things".
As a confirmed klutz in life, these two authors are my heroes. Sometimes it's helpful to be reassured that it's not always just me, that things appear to me to be appallingly designed because they are, in fact, appallingly designed. By lazy, uncaring "design professionals".
This book concentrates more on issues and products related to computing (Bill Gates: are you listening? are you even capable of listening?).
A refreshing clarion call for change. Normally I detest the phrase "paradigm shift", as exemplifying the worst of corporate jargon. But here it is appropriate: the author is calling for nothing less.
Let's hope, for our sanity and safety, and that of future generations, that someone is listening.
As a confirmed klutz in life, these two authors are my heroes. Sometimes it's helpful to be reassured that it's not always just me, that things appear to me to be appallingly designed because they are, in fact, appallingly designed. By lazy, uncaring "design professionals".
This book concentrates more on issues and products related to computing (Bill Gates: are you listening? are you even capable of listening?).
A refreshing clarion call for change. Normally I detest the phrase "paradigm shift", as exemplifying the worst of corporate jargon. But here it is appropriate: the author is calling for nothing less.
Let's hope, for our sanity and safety, and that of future generations, that someone is listening.
November 24, 2013
I think this book should be read by people who are in the business of software engineering:
- it presents an interesting point of view on the interaction design and designing with user in mind;
- it highlights many parts of the current process that are broken;
- it makes a lot of stereotypical and cynical statements about programmers, and many of those are unfortunately, correct - people should be aware of them.
On the negative side:
- the author makes many claims that don't seem to include sufficient proof or examples. It often sounds that the author advertises his method of software engineering, but requires the reader to accept it without sufficient proof;
- it seems like the author still has some beef w/ Microsoft. This topic keeps coming up and I am not sure if it's relevant in most of the cases.
- it presents an interesting point of view on the interaction design and designing with user in mind;
- it highlights many parts of the current process that are broken;
- it makes a lot of stereotypical and cynical statements about programmers, and many of those are unfortunately, correct - people should be aware of them.
On the negative side:
- the author makes many claims that don't seem to include sufficient proof or examples. It often sounds that the author advertises his method of software engineering, but requires the reader to accept it without sufficient proof;
- it seems like the author still has some beef w/ Microsoft. This topic keeps coming up and I am not sure if it's relevant in most of the cases.
August 6, 2016
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.
April 9, 2013
09/17/2012: The author's incessant whining makes this book hard to read at a pace faster than half a page a week. I wish it was a terrible book so I could stop reading it.
Finished 04/08/2013:
Thanks to the author and others like him, the world of software development has come along way since this was written. It's not where it needs to be, but it's better.
So if you can slog through the long-winded, condescending arrogance that is this book you'll find a lot of really compelling arguments for why interaction design is needed.
But really, I hope someone else writes the next book that helps us take this profession where it needs to go.
Finished 04/08/2013:
Thanks to the author and others like him, the world of software development has come along way since this was written. It's not where it needs to be, but it's better.
So if you can slog through the long-winded, condescending arrogance that is this book you'll find a lot of really compelling arguments for why interaction design is needed.
But really, I hope someone else writes the next book that helps us take this profession where it needs to go.
November 30, 2012
Alan Cooper is a recognized name in human computer interaction. This book represents some of his initial work from the 90's which at the time represented very provocative thinking. With the influence of Apple on software design along with the massive effort being put out by Microsoft, some of the ideas Cooper rants and raves about in this book seem almost quaint. Unfortunately in my opinion, Cooper set a tone for user interface designers of condescension and mockery. For some reason UI designers even today seem to think the only way to talk about the good of their design is to mock the bad in other designs. Primarily for that reason I am not a fan of Cooper's work.
May 2, 2014
This is the book that introduced me to interaction design, and helped me realize that this is what I wanted to do instead of programming. I recommend it because more programmers and their managers need to understand that, whether they are conscious of it or not, they are doing design work, and even if they have the best intentions, it's not their area of expertise.
Read
May 25, 2011It's book Must read for UI experts and IT mangers. Especially for junior UX.
There is a little bit information about prototyping method. The aim of this book is converting of your mind in sphere of creating apps and web sites.
There is a little bit information about prototyping method. The aim of this book is converting of your mind in sphere of creating apps and web sites.
November 2, 2018
An excellent product management and interaction design primer. The author takes his own advice in writing that “software should be confident” and exhibit the “principle of commensurate effort”. Some of his examples are dated but the principles are timeless.
March 1, 2011
Great overview of business need for user centered design. Must read for any UX practitioner! Cooper knows what he's talking about.
May 9, 2019
Книга позиционируется как мотиватор к проведению работ по проектированию взаимодействия пользователя с ПО.
На множестве примеров разбирая, почему проектирование и тестирование взаимодействия, производящееся уже после начала написания кода, обладает крайне ограниченными возможностями.
Не смотря на то, что большинство примеров относятся к времени написания книги и что сейчас ситуация во многих областях разработки ПО изменилась в лучшую сторону, книга остается актуальной.
Сравнение "танцующего медведя" с любым плохо спроектированным ПО очень нравится.
Ситуация, когда софт содержит в себе огромную массу функций, но добраться до них или использовать их крайне сложно и неудобно - это именно "танцующий медведь".
Функция "танца" присутствует, но исполняется так, что все счастье, только в том, что оно вообще работает, а не в том, что оно работает хорошо.
Есть в книге идея, что людям, вынужденным работать с "танцующими медведями", приходится либо смиряться с неудобством, продираясь через сложности ПО, становясь апологетом и защищая сложность ПО, либо смиряться с неудобством и стараться как можно меньше контактировать с ним, становясь уцелевшим.
Разница между апологетами и уцелевшими в том, что первые - защищают навороченный функционал, значительно преуменьшая проблемы при работе с ним и превознося саму функциональность, вторые же - жалуются на неудобство ПО, не могут с ним работать как апологеты, но и не могут точно сформулировать в чем причина неудобства. Потому как главная причина состоит в том, что людям не нравится, когда ПО выставляет их дураками, а признаваться в том, что ты не можешь справиться с чем-то, открыто заявляя, что чувствуешь себя дураком, под давлением общества не представляется возможным.
В книге присутствует своеобразный тест на принадлежность к касте "хомо логикус" или "хомо сапиенс", т.е. к программистам или пользователям, и основан на проецировании ситуаций.
Понравилась еще затронутая тема целей/задач, которая во многих книгах по управлению временем раскрывается. Тут же достаточно коротко, но емко произвели деление на цели - то, что статично и практически не изменяется во времени (полежать под пальмами в отпуск, например), и на задачи - те этапы, что приведут к желаемому получению цели (смена работы, бронирования, расчеты, etc). При этом задачи являются динамическими, так как под влиянием внешних факторов могут как появляться, пропадать, так и изменяться, а цель при этом остается статичной.
Еще в книге описан очень крутой метод создания персонажей для проектирования.
Суть в том, что записывая функциональность для софта, часто туда заносят все-все-все модули, чтобы покрыть максимальный сегмент рынка. Однако при этом абсолютно не учитываются потребности людей, которым действительно интересен продукт и его ОСНОВНОЙ функционал, а не множество второстепенных функций.
В итоге интерфейс софта усложняется, для того, чтобы вместить больше допиленных модулей, и конечному заинтересованному пользователю уже неудобно им пользоваться, так как самые ему необходимые вещи могут быть скрыты или никак не выделены на фоне остальных. Для решения этой проблемы предлагается придумывать виртуального пользователя, наделенного множеством деталей: именем, работой, привычками, ежедневными делами. Тем самым фактически сужая область разработки.
Важно, чтобы этот персонаж не был из среды апологетов, иначе не получится добиться простого интерфейса.
На множестве примеров разбирая, почему проектирование и тестирование взаимодействия, производящееся уже после начала написания кода, обладает крайне ограниченными возможностями.
Не смотря на то, что большинство примеров относятся к времени написания книги и что сейчас ситуация во многих областях разработки ПО изменилась в лучшую сторону, книга остается актуальной.
Сравнение "танцующего медведя" с любым плохо спроектированным ПО очень нравится.
Ситуация, когда софт содержит в себе огромную массу функций, но добраться до них или использовать их крайне сложно и неудобно - это именно "танцующий медведь".
Функция "танца" присутствует, но исполняется так, что все счастье, только в том, что оно вообще работает, а не в том, что оно работает хорошо.
Есть в книге идея, что людям, вынужденным работать с "танцующими медведями", приходится либо смиряться с неудобством, продираясь через сложности ПО, становясь апологетом и защищая сложность ПО, либо смиряться с неудобством и стараться как можно меньше контактировать с ним, становясь уцелевшим.
Разница между апологетами и уцелевшими в том, что первые - защищают навороченный функционал, значительно преуменьшая проблемы при работе с ним и превознося саму функциональность, вторые же - жалуются на неудобство ПО, не могут с ним работать как апологеты, но и не могут точно сформулировать в чем причина неудобства. Потому как главная причина состоит в том, что людям не нравится, когда ПО выставляет их дураками, а признаваться в том, что ты не можешь справиться с чем-то, открыто заявляя, что чувствуешь себя дураком, под давлением общества не представляется возможным.
В книге присутствует своеобразный тест на принадлежность к касте "хомо логикус" или "хомо сапиенс", т.е. к программистам или пользователям, и основан на проецировании ситуаций.
Понравилась еще затронутая тема целей/задач, которая во многих книгах по управлению временем раскрывается. Тут же достаточно коротко, но емко произвели деление на цели - то, что статично и практически не изменяется во времени (полежать под пальмами в отпуск, например), и на задачи - те этапы, что приведут к желаемому получению цели (смена работы, бронирования, расчеты, etc). При этом задачи являются динамическими, так как под влиянием внешних факторов могут как появляться, пропадать, так и изменяться, а цель при этом остается статичной.
Еще в книге описан очень крутой метод создания персонажей для проектирования.
Суть в том, что записывая функциональность для софта, часто туда заносят все-все-все модули, чтобы покрыть максимальный сегмент рынка. Однако при этом абсолютно не учитываются потребности людей, которым действительно интересен продукт и его ОСНОВНОЙ функционал, а не множество второстепенных функций.
В итоге интерфейс софта усложняется, для того, чтобы вместить больше допиленных модулей, и конечному заинтересованному пользователю уже неудобно им пользоваться, так как самые ему необходимые вещи могут быть скрыты или никак не выделены на фоне остальных. Для решения этой проблемы предлагается придумывать виртуального пользователя, наделенного множеством деталей: именем, работой, привычками, ежедневными делами. Тем самым фактически сужая область разработки.
Важно, чтобы этот персонаж не был из среды апологетов, иначе не получится добиться простого интерфейса.
This entire review has been hidden because of spoilers.
Displaying 1 - 30 of 196 reviews