售价: ¥190.00
前翻 后翻
正在播放... 已暂停   您正在聆听的 Audible 音频版本的样品。
查看全部 2 张图片

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition) (英语) 平装 – 2004年3月5日

平均4.1 星
5 星
4 星
3 星
2 星
1 星
平均4.1 星 189条亚马逊美国的评论 us-flag |
| 天天低价·正品质优
| 自营

显示所有 格式和版本 隐藏其他格式和版本
全新品最低价 非全新品最低价
退换承诺: 此商品支持30天免费退换 详情


click to open popover



  • iPhone/iPad/Mac
  • Android手机或平板电脑



  • 出版社: Sams Publishing; 2 (2004年3月5日)
  • 平装: 288页
  • 语种: 英语
  • ISBN: 0672326140
  • 条形码: 9780672326141, 0752063326145
  • 商品尺寸: 15.5 x 1.8 x 23.1 cm
  • 商品重量: 399 g
  • ASIN: 0672326140
  • 用户评分: 分享我的评价
  • 亚马逊热销商品排名: 图书商品里排第530,291名 (查看图书商品销售排行榜)
  • 您想告诉我们您发现了更低的价格?



As a software inventor in the mid-70s, Alan Cooper got it into his head that there must be a better approach to software construction. This new approach would free users from annoying, difficult and inappropriate software behavior by applying a design and engineering process that focuses on the user first and silicon second. Using this process, engineering teams could build better products faster by doing it right the first time.

His determination paid off. In 1990 he founded Cooper, a technology product design firm. Today, Cooper's innovative approach to software design is recognized as an industry standard. Over a decade after Cooper opened its doors for business, the San Francisco firm has provided innovative, user-focused solutions for companies such as Abbott Laboratories, Align Technologies, Discover Financial Services, Dolby, Ericsson, Fujitsu, Fujitsu Softek, Hewlett Packard, Informatica, IBM, Logitech, Merck-Medco, Microsoft, Overture, SAP, SHS Healthcare, Sony, Sun Microsystems, the Toro Company, Varian and VISA. The Cooper team offers training courses for the Goal-Directed® interaction design tools they have invented and perfected over the years, including the revolutionary technique for modeling and simulating users called personas, first introduced to the public in 1999 via the first edition of The Inmates.

In 1994, Bill Gates presented Alan with a Windows Pioneer Award for his invention of the visual programming concept behind Visual Basic, and in 1998 Alan received the prestigious Software Visionary Award from the Software Developer's Forum. Alan introduced a taxonomy for software design in 1995 with his best-selling first book, About Face: The Essentials of User Interface Design. Alan and co-author Robert Reimann published a significantly revised edition, About Face: The Essentials of Interaction Design, in 2003.

Alan's wife, Susan Cooper, is President and CEO of Cooper. They have two teenage sons, Scott and Marty, neither of whom is a nerd. In addition to software design, Alan is passionate about general aviation, urban planning, architecture, motor scooters, cooking, model trains and disc golf, among other things. Please send him email at inmates@cooper.com or visit Cooper's Web site at http://www.cooper.com.




1. Riddles for the Information Age.

What Do You Get When You Cross a Computer with an Airplane? What Do You Get When You Cross a Computer with a Camera? What Do You Get When You Cross a Computer with an Alarm Clock? What Do You Get When You Cross a Computer with a Car? What Do You Get When You Cross a Computer with a Bank? Computers Make It Easy to Get into Trouble. Commercial Software Suffers, Too. What Do You Get When You Cross a Computer with a Warship? Techno-Rage. An Industry in Denial. The Origins of This Book.

2. Cognitive Friction.

Behavior Unconnected to Physical Forces. Design Is a Big Word. The Relationship Between Programmers and Designers. Most Software Is Designed by Accident. "Interaction" Versus "Interface" Design. Why Software-Based Products Are Different. The Dancing Bear. The Cost of Features. Apologists and Survivors. How We React to Cognitive Friction. The Democratization of Consumer Power. Blaming the User. Software Apartheid.


3. Wasting Money.

Deadline Management. What Does "Done" Look Like? Parkinson's Law. The Product That Never Ships. Shipping Late Doesn't Hurt. Feature-List Bargaining. Programmers Are in Control. Features Are Not Necessarily Good. Iteration and the Myth of the Unpredictable Market. The Hidden Costs of Bad Software. The Only Thing More Expensive Than Writing Software Is Writing Bad Software. Opportunity Cost. The Cost of Prototyping.

4. The Dancing Bear.

If It Were a Problem, Wouldn't It Have Been Solved by Now? Consumer Electronics Victim. How Email Programs Fail. How Scheduling Programs Fail. How Calendar Software Fails. Mass Web Hysteria. What's Wrong with Software? Software Forgets. Software Is Lazy. Software Is Parsimonious with Information. Software Is Inflexible. Software Blames Users. Software Won't Take Responsibility.

5. Customer Disloyalty.

Desirability. A Comparison. Time to Market.


6. The Inmates Are Running the Asylum.

Driving from the Backseat. Hatching a Catastrophe. Computers Versus Humans. Teaching Dogs to Be Cats.

7. Homo Logicus.

The Jetway Test. The Psychology of Computer Programmers. Programmers Trade Simplicity for Control. Programmers Exchange Success for Understanding. Programmers Focus on What Is Possible to the Exclusion of What Is Probable. Programmers Act Like Jocks.

8. An Obsolete Culture.

The Culture of Programming. Reusing Code. The Common Culture. Programming Culture at Microsoft. Cultural Isolation. Skin in the Game. Scarcity Thinking. The Process Is Dehumanizing, Not the Technology.


9. Designing for Pleasure.

Personas. Design for Just One Person. The Roll-Aboard Suitcase and Sticky Notes. The Elastic User. Be Specific. Hypothetical. Precision, Not Accuracy. A Realistic Look at Skill Levels. Personas End Feature Debates. Both Designers and Programmers Need Personas. It's a User Persona, Not a Buyer Persona. The Cast of Characters. Primary Personas. Case Study: Sony Trans Com's P@ssport. The Conventional Solution. Personas. Designing for Clevis.

10. Designing for Power.

Goals Are the Reason Why We Perform Tasks. Tasks Are Not Goals. Programmers Do Task-Directed Design. Goal-Directed Design. Goal-Directed Television News. Goal-Directed Classroom Management. Personal and Practical Goals. The Principle of Commensurate Effort. Personal Goals. Corporate Goals. Practical Goals. False Goals. Computers Are Human, Too. Designing for Politeness. What Is Polite? What Makes Software Polite? Polite Software Is Interested in Me. Polite Software Is Deferential to Me. Polite Software Is Forthcoming. Polite Software Has Common Sense. Polite Software Anticipates My Needs. Polite Software Is Responsive. Polite Software Is Taciturn About Its Personal Problems. Polite Software Is Well Informed. Polite Software Is Perceptive. Polite Software Is Self-Confident. Polite Software Stays Focused. Polite Software Is Fudgable. Polite Software Gives Instant Gratification. Polite Software Is Trustworthy. Case Study: Elemental Drumbeat. The Investigation. Who Serves Whom. The Design. Pushback. Other Issues.

11. Designing for People.

Scenarios. Daily-Use Scenarios. Necessary-Use Scenarios. Edge-Case Scenario. Inflecting the Interface. Perpetual Intermediates. "Pretend It's Magic". Vocabulary. Breaking Through with Language. Reality Bats Last. Case Study: Logitech ScanMan. Malcolm, the Web-Warrior. Chad Marchetti, Boy. Magnum, DPI. Playing "Pretend It's Magic". World-Class Cropping. World-Class Image Resize. World-Class Image Reorient. World-Class Results. Bridging Hardware and Software. Less Is More.


12. Desperately Seeking Usability.

The Timing. User Testing. User Testing Before Programming. Fitting Usability Testing into the Process. Multidisciplinary Teams. Programmers Designing. How Do You Know? Style Guides. Conflict of Interest. Focus Groups. Visual Design. Industrial Design. Cool New Technology. Iteration.

13. A Managed Process.

Who Really Has the Most Influence? The Customer-Driven Death Spiral. Conceptual Integrity Is a Core Competence. A Faustian Bargain. Taking a Longer View. Taking Responsibility. Taking Time. Taking Control. Finding Bedrock. Knowing Where to Cut. Making Movies. The Deal. Document Design to Get It Built. Design Affects the Code. Design Documents Benefit Programmers. Design Documents Benefit Marketing. Design Documents Help Documenters and Tech Support. Design Documents Help Managers. Design Documents Benefit the Whole Company. Who Owns Product Quality? Creating a Design-Friendly Process. Where Interaction Designers Come From. Building Design Teams.

14. Power and Pleasure.

An Example of a Well-Run Project. A Companywide Awareness of Design. Benefits of Change. Let Them Eat Cake. Changing the Process.



5 星
4 星
3 星
2 星
1 星

此商品在美国亚马逊上最有用的商品评论 (beta) (可能包括"Early Reviewer Rewards Program"的评论)

美国亚马逊: 平均4.1 星 189 条评论
2/2 人认为此评论有用
平均4.0 星 Read it for the smart stuff, but ignore the stupid stuff 2013年4月17日
评论者 V. Shah - 已在美国亚马逊上发表
版本: Kindle电子书 已确认购买
The author has a lot of important things to say about the importance of design in software, and the many ways in which good design is sabotaged by management, programmers, deadlines, conventional thinking, tradition, lethargy, and sloth. Fighting these influences to achieve excellently designed products is incredibly important, and incredibly difficult, and the author makes this case well.

Where he goes totally off the rails is when he attacks stereotypes instead of people. He claims that every programmer thinks that he is different and can cross between coding and interaction design -- but none of them can. It turns out that he means that he was the first, and the last, one to be able to do so, because he is God. He claims that graphic designers are there to pretty up an interaction designers designs -- while ignoring the true amount of collaboration that has to be achieved between graphic design, interaction design, and programming to achieve any excellent software. His solution to bad design is to listen to nobody but the designer. (He never mentions the possibility of a subpar interaction designer.)

Finally he spends a lot of time attacking various management structures that are found at Microsoft and companies who mimic Microsoft. Well, I have worked in the NYC tech scene for 20+ years, and nobody here gives a damn about Microsoft's management practices. In the years since the book came out, it has turned out that nobody anywhere cares about Microsoft management practices anymore. It just felt like another rant about something that is relevant to nobody.

But if you wade through the extremist ranting, there really are useful messages and examples throughout the book. It's worth reading if you're in the business of making software.
1/1 人认为此评论有用
平均4.0 星 Good Book for Understanding Challenges of Designing User Friendly Technologies 2014年1月3日
评论者 Lorne Bailey - 已在美国亚马逊上发表
版本: 精装 已确认购买
While I agree with many things Alan Cooper says about the challenges of designing user friendly technologies for normal end users, I think his attitude is a bit pessimistic about how engineers and programmers design technologies that are yet to come... I think it is better to encourage Universities and Colleges to require a certain amount of technical support and customer support courses in additional to standard social sciences courses required for a typical science major for Engineering and computer science students to graduate... This should also be required for any student who hopes to get into any field of study where work in this field would affect end users of products and services rendered to them. Engineers and Technical workers need to take responsibility for their work and help end users with their products. Furthermore, licensing for Engineers and Technical workers should not only require ability to design products and technologies (i.e. traditional assessment materials), but also require ability to communicate effectively with end users and support their products and technologies. This might be a great book for young students in high school and college who want to study Engineering, IT Services, Computer Sciences or related fields.
平均5.0 星 Wonderful book describing the value of interaction design! 2016年1月10日
评论者 Deepak Balakrishna - 已在美国亚马逊上发表
版本: 平装 已确认购买
Well worth it! Having been in the IT industry for over 20 years I have seen the "old" models that Alan describes so well - where the engineers are asked to "design" and control the UX/UI. I have done this myself as an engineer and as a PM - and not having the right UX/UI vision I can attest that it was a terrible idea. I have seen how valuable interaction design in at my most recent gigs and how much it simplifies work for us business and product managers leaving the work of UX/UI to trained professionals. Alan makes a compelling case on why that should be so.
平均3.0 星 Good effort could have been better 2013年8月14日
评论者 M. Waterman - 已在美国亚马逊上发表
版本: Kindle电子书 已确认购买
This book was helpful for me in some ways as a UX interactive designer. The book does a good job at spotlighting the personalities of software engineers and programmers and did an excellent job of providing examples of poor interactive design. My only issue is the author doesn't go deep enough when explaining UX ideas, such as personas or case/user scenarios instead goes on and on stating examples of his companies wonderful efforts and work. For example in the chapter about user scenarios he quickly goes over the value of scenarios and then the rest of the chapter is about how his company did blah, blah, blah. I really didn't need example after example on what his company did, which by the last third of the book just started to wear on me. Too much fluff and ego make this an average book.
平均4.0 星 silly title, great ideas 2011年6月20日
评论者 RC - 已在美国亚马逊上发表
版本: 平装 已确认购买
This was a textbook for my Interaction Design class, but the ideas are valid in boat loads of circumstances. I highly recommend it to everyone, in fact, not just programmers and designers. While you're at it, be sure to pick up The Paradox of Choice: Why More Is Less, which solidifies his ideas from the consumer side of things.

I'm a junior high teacher by trade, so I'm going to particularly recommend it to teachers. Students, just like tech consumers, come in a variety of levels of understanding. One of the biggest challenges is to cater a lesson to smart students, slow students, and all the students in between. Teachers, like programmers, like all of us, tend to assume that others' experience is similar to their own, so they plan with themselves in mind. This book helps explain how to break out of that mentality and design for everyone.