| |
| |
| Foreword | |
| |
| |
| Preface | |
| |
| |
| |
| Computer Obliteracy | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| It Costs You Big Time | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| Customer Disloyalty | |
| |
| |
| Desirability | |
| |
| |
| A Comparison | |
| |
| |
| Time to Market | |
| |
| |
| |
| Eating Soup with a Fork | |
| |
| |
| |
| The Inmates Are Running the Asylum | |
| |
| |
| Driving from the Backseat | |
| |
| |
| Hatching a Catastrophe | |
| |
| |
| Computers Versus Humans | |
| |
| |
| Teaching Dogs to Be Cats | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| Interaction Design Is Good Business | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| Getting Back into the Driver's Seat | |
| |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| |
| Power and Pleasure | |
| |
| |
| An Example of a Well-Run Project | |
| |
| |
| A Company-Wide Awareness of Design | |
| |
| |
| Benefits of Change | |
| |
| |
| Let Them Eat Cake | |
| |
| |
| Changing the Process | |
| |
| |
| Index | |