The Design of Everyday Things: Don Norman's principles applied to UI/UX
There's a kind of door almost everyone has pushed when they should have pulled. Don Norman accidentally gave the phenomenon a name: in The Design of Everyday Things, he uses that mundane object to show that when you need a manual to open a door, the problem isn't you — it's the design.
The book was written about physical objects, but every principle in it has a direct counterpart on screen. I've spent years working on the line between design and engineering, and I rarely open a product without spotting a Norman door hidden somewhere in the flow. Below are the principles I lean on most in day-to-day UI/UX.
Affordances and signifiers
An affordance is the relationship between what an object lets you do and who uses it. A chair "offers" sitting; a button "offers" pressing. In the digital world, though, almost nothing has a real physical affordance — it's all pixels. That's why the concept that actually matters in an interface is the signifier: the visible cue that communicates where the action happens.
Underlining a link, giving a button depth, showing a cursor that changes shape — those are signifiers. When you strip them all away in the name of a "clean" look, you're removing the map, not the clutter.
Affordances determine which actions are possible. Signifiers communicate where the action should happen. Bad UI tends to have the first without the second.
Flat design taken to the extreme is the classic example: a piece of text that is a button and a piece of text that is just text look identical. The action exists, but nobody finds it.
Mapping
Mapping is the correspondence between controls and their effects. The book's example is stove burners: when the knobs sit in a row and the burners in a square, you guess wrong forever. When each knob is spatially aligned with its burner, you get it right without thinking.
In an interface, mapping shows up in decisions like:
- a volume slider that grows from left to right, the way we expect it to;
- pagination arrows that point in the direction the content moves;
- a toggle whose "on" state sits visually to the right and lit.
Good mapping is the kind you never notice — it simply coincides with the intuition the user already brought in from outside.
Feedback
Every action needs a perceptible, immediate reaction. Press an elevator button and it lights up; without that, you press again and again. On screen, the absence of feedback produces the same behaviour: the user clicks "Save" three times because nothing confirmed the first click.
Good feedback answers three questions in order:
- Did I get your command? — the loading state, the button that depresses.
- Is it happening? — the progress bar, the skeleton.
- Did it finish, and how? — the success toast, the specific error message.
Skip any of these steps and a two-second wait turns into the feeling of a broken product.
Conceptual model
The user builds a mental model of how the system works from what they see. The designer's job is to make that model match the real model of the implementation. When the two diverge, frustration appears: the person acts according to the model they imagined, and the system responds according to what was coded.
A shopping cart is a good metaphor precisely because it borrows a ready-made mental model from the physical world — you add, remove, see the total. When an interface invents its own metaphor and doesn't sustain it, it pays the price in support tickets.
The gulfs of execution and evaluation
Norman describes two chasms between intent and action:
- the gulf of execution — the distance between what I want to do and figuring out how to do it;
- the gulf of evaluation — the distance between the system acting and me understanding what happened.
Good design narrows both. Signifiers and mapping shorten execution; feedback shortens evaluation. When I get a ticket that says "the user couldn't find the button," it's almost always a gulf of execution. When it's "I did it but I don't know if it worked," it's evaluation.
Constraints: prevent the error before explaining it
Instead of relying on the user's attention, constrain the possible actions. A date field that only accepts valid dates eliminates an entire class of errors. Disabling "Submit" while the form is incomplete is a constraint — as long as you say why it's disabled.
Norman separates two kinds of error that call for different solutions:
- Slips: you knew what you wanted, but your hand missed. Fight them with constraints and generous click targets.
- Mistakes: you formed the wrong goal. Fight them with a clearer conceptual model, not with more validation.
Instead of: "Error: invalid input"
Prefer: "The date must be in the future — delivery can't be in the past"
The first message blames the user. The second explains the constraint and shows the way out.
Human-centred design
The thread that stitches it all together is human-centred design: start from people's real needs, not from the technology or the aesthetics. Norman champions the loop of observing, generating ideas, prototyping and testing — repeated until the interface disappears and only the task remains.
The lesson I carry from the book is almost an acceptance test: when the user fails, the design is at fault. Before adding a tooltip to explain the button, ask why the button needed explaining. Almost always you can change the signifier, the mapping or the constraint — and make the door open the right way on the first try.