Introduction
You likely feel constant frustration when using everyday digital devices and software applications. Technology products become increasingly complex, demanding excessive attention while failing to perform basic tasks reliably.
Software products are difficult to use because engineers rather than designers control their behavior, but adopting goal-directed design solves this problem.
Alan Cooper argues that programmers design software from the inside out, prioritizing technical capability over human needs. This creates interfaces that treat you like a computer rather than a person.
The book explains why technology creates severe cognitive friction and examines how development management styles waste massive amounts of money. You will discover how programmer psychology shapes bad interfaces and learn a systematic method for putting interaction designers in charge.
The following questions guide the exploration:
- Why do digital products make simple tasks difficult?
- How do programming mentalities ruin software usability?
- What precise methods align product behavior with your real goals?
1. Riddles for the Information Age
Technology products have become excessively complicated and unreliable because software-driven automation introduces unpredictable meta-states.
The high-tech industry has inadvertently put software engineers in charge of product design, resulting in an engineering culture that values features over usability.
Software firms like Microsoft and various technology companies leave products to be shaped entirely by the minds of programmers. Engineers build products from a technical frame of reference, focusing on awesome power and flexibility. They ignore how excruciatingly difficult tools are for normal humans to learn and use. This gives rise to a condition where the inmates are running the asylum.
Modern consumer electronics become harder to use as computers take over mechanical functions and execute opaque automated decisions. Alan Cooper describes his Nikon COOLPIX 900 digital camera, which has a complex four-setting power switch. A power-management program shuts off the LCD display mid-shot, eventually taking a high-resolution picture of his kneecap. The camera requires 7 seconds to boot up.
Software-based products often present precise data without informing users of context, leading to fatal operational mistakes. In December 1995, American Airlines Flight 965 departed from Miami to Cali, Colombia, crashed into a granite peak at 10,000 feet, resulting in the death of 152 passengers and all 8 crewmembers. Investigators labeled it human error. The flight computer allowed the pilot to select a navigation fix starting with 'R'. Instead of 'ROZO', he selected 'ROMEO' which was 132 miles away, causing the plane to crash into a mountain because the computer only tracked its internal computations without warning the pilot of the dangerous choice.
Systemic flaws in software engineering standards permit simple data input errors to cause catastrophic failures in mission-critical hardware. Programmers establish low quality thresholds compared to traditional engineering disciplines. Unvalidated inputs like a zero can trigger mathematical division errors that completely crash control systems. In September 1997, the USS Yorktown guided-missile cruiser went dead in the water for two hours and 45 minutes after a technician entered a zero into a fuel-valve management computer running Windows NT, causing a division-by-zero crash.
2. Cognitive Friction and Software Apartheid
Software interaction creates a unique mental strain called cognitive friction, forcing users to either become apologists or silently blame themselves.
Unlike physical tools whose behavior stays in a predictable range matching physical laws, software-based products introduce meta-states where identical physical inputs perform entirely different actions depending on the invisible context. Playing a violin is physically difficult but low in cognitive friction because it does not suddenly shift into a meta-state where it sounds like a bell, whereas a microwave oven's number keys shift functions between intensity and duration.
Demanding computer literacy for basic tasks creates a societal divide that excludes capable people from employment and participation. Obscure file systems and poor interaction design force users to master technical trivia, creating an artificial barrier known as software apartheid that locks out non-technical individuals from the modern workforce.
Jane, an account coordinator, lost a half-day of work and panicked when a background file-viewing action by a technician named Sunil threw her document search into an obscure folder 6 levels deep.
Users respond to cognitive friction by abandoning complex features, learning only the minimum subset necessary to accomplish their immediate work. The usage frequency of any technology feature is inversely proportional to the amount of interaction needed to control it, leading users and apologists to ignore advanced capabilities.
Cooper notes that despite having a sophisticated home-entertainment system with a 55 inch screen and thousands of features, his family uses it exactly like a basic Motorola television from the year 1975 because the advanced options involve too much cognitive friction.
3. Wasting Money on Bad Software
Physical manufacturing incurs real costs for every added part, creating a negative feedback loop. In software, adding features in code seems virtually free to executives, leading to software bloat where marginal functions obscure essential ones and multiply tech-support burdens.
Software projects waste millions of dollars because management obsesses over arbitrary deadlines without defining what a completed product actually looks like.
Products like Lotus Notes, Adobe Photoshop, Intuit Quicken, and Microsoft Word are encrusted with bewildering arrays of features that confound users. Microsoft spends $800 million annually on technical support.
Lacking a clear vision of the finished product or user reactions, managers rely on arbitrary deadlines and force developers to start coding immediately. This leads to Parkinson's Law expansions, the Ninety-Ninety Rule, and abandoned projects.
Start-up companies like Worlds, Inc. spent tens of millions of dollars before their virtual online world project was euthanized by directors without ever being fully defined. Nomadic Computing spent $15 million creating an undefined mobile product. The Worlds, Inc. project ran for three years before it was euthanized.
To defend against vague specifications, programmers demand precise feature lists. During deadline negotiations, programmers assign longer durations to difficult interface items, pushing them to the bottom of the list while easy-to-code features bubble to the top. This feature-list bargaining allows programmers to secretly control project scope by inflating estimates for nebulous user-interface items.
T/Maker shipped more copies of WriteNow to universities than Microsoft shipped Word in 1987, but eventually lost the market because deadline pressures prevented them from adding endnotes.
Treating prototypes as production code bases introduces foundational scar tissue that ultimately causes projects to fail or require massive rewrites. Prototypes are built rapidly with compromised data structures and shortcuts, acting as scaffolding rather than stone walls. Managers often force teams to build on top of prototypes because they run, creating an accumulation of scar tissue that restricts future software growth.
In 1988, Alan Cooper sold the Ruby prototype to Bill Gates, which became Visual Basic. While Microsoft's Russ Werner was initially indignant that Cooper threw the prototype away to restart from scratch, doing so ensured the product was delivered successfully on schedule.
4. The Psychology of Computer Programmers
Software engineers are so steeped in the literal behavior of silicon that they cannot excel at the unpredictable world of human design. Immersion in deterministic systems makes it hard to address human needs. Attempting both programming and interaction design at the same time is nearly impossible.
Programmers possess a distinct psychological profile that makes them trade simplicity for control and focus on possibilities rather than probabilities.
Bill Atkinson and Andy Hertzfeld, two of the most talented programmers behind the Apple Macintosh, headed General Magic. Its stellar product failed largely due to a lack of interaction design.
The Jetway Test illustrates the fundamental psychological divide between programmers who desire technical control and users who desire simplicity. When boarding an aircraft via a Jetway, turning left into the complex cockpit appeals to those who want control and understanding of technical complexity. Turning right into the cabin appeals to those who want to relinquish authority and simply reach their destination comfortably.
Alan Cooper recalls being introduced to flying in 1979 by programmer-nerd Gary Kildall, noting how programmers thrive on daunting cockpit complexities.
Programmers willingly trade simplicity for control, whereas normal humans trade control for simplicity. Programmers enjoy managing complex, deterministic systems and build interfaces packed with features that give users maximum control. Ordinary users prefer fewer options to avoid making mistakes.
In Windows 95, the Find File function offers massive control by letting users specify areas, file types, and contents. This pleases programmers but increases the probability of user error.
Programmers focus on what is possible in complex systems to the exclusion of what is probable. This leads to obsessive preparation for edge cases. Because computers operate on strict mathematical propositions, programmers treat one-in-a-million edge cases as absolute necessities. They clutter the interface with controls for rare scenarios while obscuring frequently used functions.
Programmers often joke that there are only three numbers: 0, 1, and infinity, ignoring practical human quantities like 500.
Programmers share the competitive, immature, and dominating mindset of high school jocks, but use mental ability instead of physical strength as their weapon. Nerds who were dominated physically in youth discover in adulthood that mental dominance in the information age grants immense power. Lacking a maturation process to temper this power, they often humiliate users with overly complex software.
Alan Cooper admits that until his late 20s he was a bully who used his programming skills and mastery of complex systems as fists to hoot at those who could not keep up.
5. Designing for Goals with Personas
Real users lack the vision to see solutions to their own problems. You must invent precise pretend users with names, backgrounds, and unique goals to guide your work.
Goal-directed design uses specific fictional archetypes called personas to eliminate feature debates and align software behavior with human needs.
Personas are hypothetical archetypes of actual users defined with rigorous specificity. Every project cast of characters includes 3 to 12 unique personas.
You can apply this method directly to your own projects:
- Develop a precise description of the user and what he wishes to accomplish.
- Make up pretend users and design for them.
- Assemble all personas on a single sheet of paper containing their names, pictures, job descriptions, goals, and telltale quotes.
Remedy Inc. created the persona Leo Pierce, a low-tech marketing assistant, to shift engineering focus away from internal help-desk technicians and onto direct accessibility. When programmers use generic terms like the user, they rely on possibility thinking. Referring to a specific persona brings the focus back to verified user objectives and drastically accelerates delivery schedules.
Narrowing the design target to a single specific person yields far greater commercial success than attempting to please a broad demographic. Expanding functionality to include multiple constituencies introduces control barriers that degrade the user experience for everyone. Designing for an extreme minority who loves the product generates fanatical customer loyalty.
In 1997, Sony Trans Com approached the design firm facing an impossible interface challenge for their P@ssport video-on-demand system. The team selected Clevis McCloud, an aging septuagenarian with arthritis and no computer experience, as their primary persona. Sony replaced a deep hierarchical tree of screens and a handheld controller with a physical data wheel and a monocline grouping of movie posters.
Chrysler chairman Robert Lutz pushed forward with the Dodge Ram pickup despite 80 percent of focus group participants hating it, because the remaining 20 percent loved it, turning it into a best-seller.
6. Designing for Politeness and Power
Software often acts like an uncooperative stranger instead of a helpful companion. A desktop computer fails to remember personal habits or recognize you, unlike an automatic-flush urinal in an airport bathroom that is more aware of presence.
Polite software emulates a sensitive and caring human companion while satisfying personal, practical, and corporate goals simultaneously.
Alan Cooper calls polite software an essential requirement for user satisfaction. You can identify politeness through specific traits:
- 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
Fudgability allows you to bend rules temporarily and take actions out of sequence, preventing major downstream mistakes. Manual systems allow workers to accept incomplete transactions or expedite urgent matters temporarily. Computerized systems usually reject intermediate states, but adding fudgability with a detailed audit trail prevents you from feeling alienated and reduces colossal errors. A human clerk can post an order before detailed customer information arrives, whereas a computerized system rejects the transaction.
Tasks are transient procedures, whereas goals are stable end conditions that remain constant even as technology changes. Programmers focus on step-by-step tasks, which leads to frustrating interaction. Designing for goals ensures long-term satisfaction because tasks change while goals remain steady. Traveling from St. Louis to San Francisco in 1850 involved a Conestoga wagon and a Winchester rifle for safety, while in 1999 it involved a Boeing 777.
Effective interaction design must satisfy personal, practical, and corporate goals without prioritizing false goals. Personal goals include not feeling stupid and having fun, while practical goals involve handling tasks and corporate goals focus on profits. Software fails if it violates personal goals, regardless of technical efficiency. Ted spent an hour reading a 40-page manual for his new television set because the parameter-setting process made him feel stupid.
7. A Managed Process for Product Quality
Transforming software development requires adopting a moviemaking preproduction model and placing interaction designers in charge of quality.
When vendors stop listening and start following customer demands, they transform from product companies into custom service bureaus. Becoming a customer-driven company by blindly implementing every client feature request leads to a chaotic product lacking conceptual integrity and corporate decline. IBM prided itself on being a customer-driven company in the 1980s, and its customers drove it right off the top of the mountain from a market leader to a follower.
Filmmakers spend a year or more in preproduction and only a couple of months in intense filming, using an eraser, pencil, and time to make dramatic script and set changes cheaply before cameras roll. Software development mirrors this structure, yet teams spend merely days on planning and months on expensive coding.
Great interaction design is meaningless unless it is comprehensively documented in writing with exhaustive detail, acting as an architectural blueprint for programmers. A written specification acts like a military battle plan and a movie script, explicitly telling programmers what to build and where not to add extraneous features.
Follow these rules for documentation:
- write, storyboard, animate, and sketch solutions with sufficient completeness and detail;
- organize design documents using the spiral method of a newspaper, moving from headlines to broad paragraphs and finally complete detail;
- explicitly state where the programmer is not to voluntarily insert extra dialog boxes.
Interaction designers must serve as the ultimate owners of product quality, holding the authority over external behavior while taking responsibility for usability.
When everyone is responsible for quality, nobody is responsible. Designers must have skin in the game by accepting responsibility for the final user experience. Shared Healthcare Systems Inc. successfully embraced user personas and a unified resident record after interaction designers mapped out software managing long-term health-care facilities.
Fostering a design-friendly process is more important than hiring a star designer.
Use these practices to structure your team:
- keep design teams small with two or three designers per product;
- insulate the design team from managers and programmers early in the project;
- assign a design communicator responsible for documenting the team's work.
10 Key Ideas
- The high-tech industry has inadvertently put software engineers in charge of product design, resulting in an engineering culture that values features over usability.
- Software interaction creates a unique mental strain called cognitive friction, forcing users to either become apologists or silently blame themselves.
- Software projects waste millions of dollars because management obsesses over arbitrary deadlines without defining what a completed product actually looks like.
- Programmers possess a distinct psychological profile that makes them trade simplicity for control and focus on possibilities rather than probabilities.
- Goal-directed design uses specific fictional archetypes called personas to eliminate feature debates and align software behavior with human needs.
- Polite software emulates a sensitive and caring human companion while satisfying personal, practical, and corporate goals simultaneously.
- Designing for goals ensures long-term satisfaction because tasks change while goals remain steady.
- Transforming software development requires adopting a moviemaking preproduction model and placing interaction designers in charge of quality.
- Interaction designers must serve as the ultimate owners of product quality, holding the authority over external behavior while taking responsibility for usability.
- Becoming a customer-driven company by blindly implementing every client feature request leads to a chaotic product lacking conceptual integrity and corporate decline.