The office coffee machine had four silver buttons, all the same size, all equally confident, and none of them said what would happen after being pressed. One button made espresso. One made hot water. One started cleaning. One did nothing obvious for a few seconds, which was enough time for a new teammate to press it twice and create a small, wet problem on the counter.
That kind of moment is ordinary enough to be funny, but it is also the heart of The Design of Everyday Things. Don Norman is not only talking about doors, switches, and coffee machines. He is talking about a quiet contract between an object and the person trying to use it. The object should give enough clues that a reasonable person can form a reasonable next action without feeling stupid.
This article is a personal reflection from Don Norman’s The Design of Everyday Things, published by Basic Books in its revised and expanded 2013 edition. The original work was first known as The Psychology of Everyday Things. I am using the book as a lens for software and product work, not trying to summarize every chapter.
A product should not make people guess
One useful word from the book is discoverability: can people look at the thing and discover what actions are possible? In software, this is often where friction begins. A screen may be technically complete but behaviorally quiet. The button exists, but the state is unclear. The form is valid, but the user cannot tell why the submit button is disabled. A setting is powerful, but nobody knows what changes after turning it on.
Consider an internal admin screen for refunding orders. The team may assume the flow is obvious: search order, choose reason, enter amount, submit. But a support agent seeing it for the first time has different questions. Is this a full refund or partial refund? Will the customer receive an email? Can this be reversed? Does it update finance automatically? If the interface does not answer those questions at the right moment, the agent must rely on memory, Slack messages, or courage.
A clearer refund screen would make the behavior visible before the risky click. The primary button might say “Refund $48.20 to Visa ending 4242,” not only “Submit.” A small review panel can show whether the customer gets an email, whether finance is notified, whether the refund can be cancelled, and which audit note will be saved. The example is small, but it shows how copy, state, and layout become part of the system’s safety.
Norman’s lesson is gentle but demanding: if a user has to guess too much, the design has pushed its work onto the user. Sometimes that is acceptable for expert tools, but even expert tools need visible structure. A database migration console can be complex. It should not be mysterious.
Signifiers are the language of behavior
Norman separates what can be done from what tells people what can be done. In a physical object, a handle may suggest pulling and a flat plate may suggest pushing. In software, signifiers include labels, button shape, cursor changes, disabled states, placeholders, empty states, affordance in layout, and even where something is placed on the screen.
A common mistake is assuming visual cleanliness is the same as clarity. Teams remove labels, hide secondary actions behind icons, reduce contrast, and make everything feel calm in the mockup. But when the screen reaches a real user, the calmness becomes silence. People hover randomly, open menus only to see what is inside, and ask support where the action went.
| Weak signifier | What the user may wonder | Clearer design move |
|---|---|---|
| Disabled submit button with no reason | Is the page broken, or did I miss a field? | Show inline validation and explain the missing requirement near the control. |
| Icon-only destructive action | Does this remove, archive, or only hide the item? | Use a clear label, stronger visual hierarchy, and a recovery path. |
| Clickable card that looks like static content | Can I open this, select it, or only read it? | Use hover state, focus state, cursor, and a visible action area. |
| Toggle with abstract copy | What changes after this is turned on? | Describe the concrete behavior and show the current state after changing it. |
One practical example is a billing setting called “smart retry.” The engineering team may know it means failed payments will be retried three times across seven days. A customer does not know that. A better screen says what will happen, when it will happen, whether the customer is notified, and how the user can stop it. The signifier is not decoration. It is part of the product’s behavior.
Mapping is how the interface keeps its promise
Mapping is the relationship between a control and its effect. A stove with four knobs arranged like the four burners is easier to use because the physical layout teaches the relationship. Software has the same problem, only less visible.
A team dashboard with filters at the top and charts below is familiar because the mapping is spatial and predictable. Change the filters, the charts change. But imagine a permissions screen where checkboxes on the left affect a preview hidden inside a tab on the right. The control may work perfectly in code, while the user cannot build a reliable mental bridge between action and outcome.
Good mapping reduces the need for memory. A deployment screen should make environment, branch, version, and impact visibly connected. If production and staging look nearly identical, a small slip becomes more likely. If the production action is physically separated, color-coded with restraint, labeled clearly, and requires reviewing the exact version, the interface is doing some of the remembering for the user.
When someone changes a control, can they immediately see what part of the system will change, what state it is in now, and how to recover if the action was wrong?
Feedback is respect for attention
Feedback tells people that the system heard them. It does not have to be noisy. In fact, too much feedback becomes another kind of confusion. But no feedback leaves people suspended between action and evaluation, which is where repeated clicks, duplicate submissions, and support tickets begin.
A payment form is a simple example. After a user presses “Pay,” the worst interface becomes quiet. The button still looks clickable, the page does not change, and the user wonders whether the payment is processing. A better interface disables the button, shows progress, explains that the user should not close the page, and then gives a clear final state. If something fails, the error message should say what happened, whether money moved, and what the next safe action is.
Feedback also matters inside team tools. A CI dashboard should not only say “failed.” It should point to the stage, the failing check, the likely owner, and the relevant logs. A feature flag console should not only say “saved.” It should show which environment changed and when the new state will take effect. These details sound small until the team is tired and a release is close.
Conceptual models shape trust
The strongest idea in the book, for me, is the conceptual model. People carry an internal explanation of how a system works. It may be incomplete, but it guides every action they take. If the model is wrong, even careful users can make wrong decisions.
Software often creates weak conceptual models when implementation details leak through the interface. A file sync tool may show “syncing” without explaining whether files are local, remote, conflicted, or waiting for network. A user then invents a model: maybe the file is safe, maybe it is not. The next action depends on that guess.
Product teams can help by making the system image coherent. Names, states, flows, empty screens, confirmation messages, and support docs should tell the same story. If the product says “workspace” in one place, “organization” in another, and “team” in a third, people do not only learn three words. They may learn three different mental models and never know which one controls billing, permissions, or data ownership.
| System area | Weak conceptual model | Clearer model |
|---|---|---|
| Draft publishing | “Saved,” “submitted,” and “published” appear as loose labels. | Show a simple state path: draft, in review, scheduled, live, archived. |
| Team permissions | Roles, seats, and billing ownership are mixed on one screen. | Separate access, billing, and ownership while showing how they relate. |
| Data import | The user uploads a file and waits without knowing validation status. | Show upload, validation, mapping, preview, commit, and rollback as distinct steps. |
This is where design becomes more than surface polish. The interface is teaching the product’s logic. If it teaches a confused story, users will act from confusion. If it teaches a stable story, people can move with more confidence.
Use the world so users do not need to memorize everything
Norman contrasts knowledge in the head with knowledge in the world. Good design does not force people to remember every rule. It places enough information in the environment so the next action is easier to infer.
In software, this can be as plain as keeping field requirements visible, showing examples beside an input, leaving breadcrumbs in a multi-step process, or displaying recent activity near a risky setting. It can also mean designing defaults that reflect the most common safe path. A user should not have to remember from last month that CSV import expects dates in ISO format. The screen can show an example and validate before upload.
This is especially important for tools used under pressure: incident consoles, finance workflows, healthcare screens, legal review systems, production deploy tools. People using them are often interrupted, tired, or moving between tasks. A good interface carries more memory for them.
Key takeaways
- Discoverability is product work. A screen should reveal what actions are possible without forcing people to hunt.
- Signifiers are not decoration. Labels, states, placement, and motion tell users how the product behaves.
- Mapping reduces memory load. Controls should sit close to the effects they create, especially in risky workflows.
- Feedback prevents anxious repetition. The system should acknowledge action and make the next safe step visible.
- Conceptual models shape trust. Naming, state, flow, and documentation should teach one coherent product story.
- Good design puts knowledge in the world. Examples, validation, breadcrumbs, and safe defaults reduce the amount users must carry in memory.
What stays with me from The Design of Everyday Things is not only that doors should look pushable or pullable. It is the broader humility behind that lesson. When a person hesitates, misclicks, or asks a question that seems obvious to the team, the first response does not have to be blame. It can be curiosity. What did the product fail to say? What model did it teach? What clue was missing at the moment it mattered?
Many better products are built from those small corrections. One clearer label. One better state. One safer mapping. One piece of feedback that arrives at the right time. Quiet changes, but they make the interface feel less like a test and more like a place where a person can think clearly.