About Face
Design that puts people first
Description
By the late 1990s, most software worked. It compiled, it shipped, it did what the spec sheet promised. And people hated using it. They blamed themselves — the manual was confusing, they weren't technical enough, they must have clicked the wrong thing. Alan Cooper, a programmer who had built one of the first visual tools that would become Microsoft's Visual Basic, watched this happen for years and drew a different conclusion. The problem wasn't the user. The problem was that nobody had designed the thing to be used by an actual human being in the first place.
Cooper's frustration became a book. First published in 1995 and then substantially rebuilt across later editions with co-authors Robert Reimann, David Cronin and others, About Face laid out a way of thinking that treated the behavior of a digital product as something to be deliberately designed — not something that fell out of the code as an afterthought. It argued that most software was built engineering-first, and that this order of operations quietly produced interfaces that served the machine's logic rather than the person's intentions. The fix was not more features or a prettier skin. It was a discipline: interaction design, with its own methods, its own vocabulary, and its own place before a single line of code got written.
The book became one of the founding texts of a field that barely existed when Cooper started writing. Product teams still argue about its ideas, and many of the words designers use every day trace back to its pages. What made it stick was not a set of rules to memorize but a shift in where you point the question — away from what the software can do, toward what a specific person is trying to accomplish and how the product can help without getting in the way.
The question we’re asking : Why did so much working software feel hostile to use, and what did Cooper propose to fix the order in which we build it?What we’ll see : How About Face reframes design around real human intentions, and turns a vague sense of "good" software into a method teams can actually follow.
Table of contents
01Chapter 1 — The dancing bear nobody wanted
Cooper had a favorite image for the software of his era: the dancing bear. You go to the circus, you see a bear dance, and you're amazed — not because the bear dances well, but because it dances at all. Most digital products, he argued, were dancing bears. We marveled that they worked and forgave everything else. The VCR that blinked twelve o'clock forever, the enterprise system that needed a week of training, the phone menu that trapped you in loops — all of it worked, technically, and all of it was miserable to actually use.
The reason, in Cooper's telling, was structural. Software was built by engineers, and engineers optimize for what engineers can see: it runs, it's fast, it handles the edge cases, the data is consistent. Those are real virtues. But none of them is the same as being usable, and the person who could tell the difference — someone whose job was the human's experience rather than the machine's correctness — usually wasn't in the room. Design, when it happened at all, arrived late, once the architecture had already locked in the behavior. By then the shape of the thing was decided.
02Chapter 2 — Personas, or the end of the elastic user
The most famous idea in the book is the persona, and Cooper's route to it was almost accidental. While designing a project-management tool in the early 1990s, he found himself talking through decisions in the voice of an imagined user he had sketched from interviews — a specific woman with a specific job, specific habits, specific frustrations. Designing for her, rather than for "the user" in the abstract, made the arguments sharper and the choices clearer. He gave her a name and a photo, and the technique became central to everything he taught afterward.
The problem a persona solves is what Cooper called the elastic user. When a team designs for "the user," that user quietly stretches to justify whatever anyone wants to build. The power user needs every option exposed; the novice needs everything hidden; the occasional visitor needs a tutorial. Since all of these people are "the user," every feature can be defended, and the product bloats into something that serves no one particularly well. The elastic user is a rhetorical convenience that lets the team avoid deciding who they're actually for.
03Chapter 3 — Goals are not tasks
Personas exist to serve something, and in Cooper's framework that something is goals — which he is careful to distinguish from tasks. A task is a thing you do: enter the invoice number, click submit, wait for the confirmation. A goal is the state you're actually after: get paid, look competent to your boss, be done before lunch. Software historically obsessed over tasks and ignored goals, which is why so many products let you complete every step and still leave you feeling defeated. You did the work; you didn't get what you wanted.
This is the heart of what the book calls goal-directed design. You start not with features or screens but with the persona's goals, and you work backward to the behavior that would serve them. Cooper draws a useful line between kinds of goals. There are end goals — what the person wants to accomplish. There are experience goals — how they want to feel while doing it, such as unintimidated and in control. And there are life goals, the deeper aspirations a product should never violate, like not wanting to feel stupid or to look bad in front of colleagues. Tasks are just the means; when you design straight from tasks, you optimize the means and lose the end.
04Chapter 4 — Software with a personality problem
Step back from the methods and About Face is making a claim that is closer to ethics than to craft. Every piece of software has a de facto personality — the way it treats you when things go wrong, the assumptions it makes about your competence, the moments it interrupts you and the moments it stays quiet. Nobody usually chooses that personality on purpose; it accumulates out of a thousand small engineering decisions. Cooper's argument is that it should be chosen, deliberately, because a product's behavior toward people has moral weight whether or not the team acknowledges it.
This reframes interaction design as the discipline that takes responsibility for that behavior. When a form loses an hour of your work because you missed a field, when an error message blames you for a mistake the system made possible, when an interface demands your attention for the software's convenience rather than yours — these are not neutral technical facts. They are decisions about how much a company's product respects the person on the other side. Cooper's most cutting observation is that badly behaved software makes people feel stupid, and that this cost never appears on any balance sheet even though people carry it home.
05Conclusion
The dancing bear that opened the book turns out to be the whole argument in miniature. Working software was never the finish line; it was the low bar we had mistaken for one. What Cooper and his co-authors offered was a way to raise it without hand-waving — start from a real person, name their goals, design the behavior that serves those goals, and let the interface fall out last rather than first. The personas, the scenarios, the goal-directed sequence are all machinery in service of a single reversal: putting the human's intentions ahead of the machine's logic in the order things get decided.