The Psychology of “Obvious”: Affordances, Signifiers & Mental Models
Some products feel obvious. You walk up, you know what to do, and it works. Other products make you stop and think — "Wait, do I push or pull? Did that save? Where's the button?" The difference is rarely intelligence. It is design. This chapter explains the small set of ideas, mostly from Don Norman's classic book The Design of Everyday Things (first published 1988, revised and expanded in 2013), that explain why some things feel obvious and others feel like a trap.
Norman spent years studying why ordinary objects — doors, stoves, light switches — confuse smart people. His conclusion: when a person fails to use something, the design failed, not the person. The same logic applies to your software. When a non-technical print-shop owner can't find how to publish a product, the screen failed them.
Affordance: what an object lets you do
Norman borrowed the word affordance from a perceptual psychologist named J.J. Gibson, then narrowed it for design.
- Affordance
- The possible actions an object permits, given who is using it. It is a relationship between an object and a person — not a property of the object alone.
A chair affords sitting. A handle affords grasping and pulling. A flat plate on a door affords pushing. Gibson argued an affordance simply exists, whether or not anyone notices it. Norman cared more about perceived affordances — the actions a user can actually recognize. An action the user cannot see might as well not exist.
Signifier: the cue that tells you how
Because designers kept calling every visual cue an "affordance," Norman split the idea in two. In the 2013 edition he made signifier the star.
- Signifier
- A perceptible cue — a shape, label, color, or sound — that announces an affordance exists and tells you where and how to act.
Norman wrote: "Forget affordances; what people need, and what design must provide, are signifiers." A door can always be pushed (the affordance). The flat metal plate is the signifier that says "push, here."
The Norman door
While on sabbatical at Cambridge in the 1980s, Norman kept fighting with doors — pulling ones meant to be pushed. A Norman door is now any door whose design tells you the wrong thing. Put a graspable handle on a door that only pushes open, and the signifier lies: the handle says "pull," the door says "push." The honest fix is pure signifier design — a flat plate (nothing to grab) for push, a bar or handle for pull.
Mapping: lining controls up with their effects
- Mapping
- The relationship between a set of controls and the things they control. Natural mapping uses spatial layout and convention so the right action is obvious — no labels needed.
The classic case is a stove. Four burners sit in a square, but the four knobs sit in a row. Which knob runs which burner? You guess, you read tiny labels, you burn dinner. Arrange the knobs in the same square layout as the burners and the mapping becomes natural — each knob sits visually near its burner. A bank of identical light switches has the same problem; lay them out to mirror the room and it solves itself. A steering wheel is the gold standard: turn right, go right — nobody has to learn it.
BAD MAPPING NATURAL MAPPING
burners: [A][B] burners: [A][B]
[C][D] [C][D]
knobs: (1)(2)(3)(4) knobs: (A)(B)
"which knob? read label" (C)(D)
"knob sits under its burner"
Mental models: the story in the user's head
- Mental model
- What a user believes about how a system works — the internal story they carry, built from past experience with similar things. It drives every action they try.
People act on their model, not on your code. If a shop owner believes "saving happens when I leave the page," they won't click Save. Norman frames three models that must line up:
- Designer's model — how the designer intends the system to work, in their head.
- System image — everything the system actually shows: the UI, labels, behavior, help text. The designer cannot talk to the user directly; they communicate only through this.
- User's model — what the user builds, derived entirely from the system image, not from the designer's intentions.
Designer's model --build--> SYSTEM IMAGE --read--> User's model
(intent) (the UI) (mental model)
\___________ must converge: same story ___________/
The two gulfs: where errors are born
In 1986, Ed Hutchins, Jim Hollan, and Don Norman named two gaps that a user must cross. Norman popularized them in DOET.
| Gulf | The question | Bridged by |
|---|---|---|
| Execution | "How do I make it do what I want?" | Affordances, signifiers, constraints |
| Evaluation | "Did it work? What state is it in now?" | Feedback, visible system status |
NN/g (the Nielsen Norman Group, the consultancy Norman co-founded) gives a sharp example: a Windows Bluetooth toggle whose state was ambiguous. Users couldn't evaluate whether Bluetooth was off — but once that was clear, they instantly knew how to execute turning it on. Successful execution usually depends on correct evaluation first.
Conceptual models & metaphors
- Conceptual model
- A simplified story the design deliberately projects so users form a correct mental model.
Metaphors are a tool for building one: they let users carry knowledge from a familiar real-world thing into a new interface. The desktop (files and folders), the trash can (drag to delete; it fills up, can be emptied or restored), and the shopping cart (add items, review, check out) all evoke a concrete image and an action script.
Bringing it to your screen
These ideas converge on one design rule: make it look obvious.
- A button must look pressable — fill, padding, shadow, contrasting color are signifiers of the "click" affordance. A flat label leaves users unsure it's interactive (an execution gulf).
- A link must look clickable — the underline or distinct color is the signifier. Strip it and you hide the affordance.
- Checkout must match the user's model of "buy a thing" — cart → review → address → pay → confirmation. Steps out of order, costs revealed late, or a missing "did it work?" confirmation all open the evaluation gulf.
- Feedback is mandatory — every action needs immediate, plain confirmation ("Saved," "Added to cart"), never silence or a raw status code.
Finally, the deepest model is the user's model of their own goal. Clayton Christensen's milkshake story illustrates it: researchers found roughly 40% of milkshakes were bought early in the morning by solo commuters, "hired" to make a boring drive interesting and hold off hunger until 10am. The fix wasn't flavor — it was making the shake thicker (lasts the commute) and easy to grab. (The numbers are an oft-told anecdote, so treat the figures as illustrative.) The lesson holds: design for the job the user is hiring your product to do, not just the feature you think you shipped.
Key takeaways
- Affordance = what is possible; signifier = the visible cue that tells the user it's possible and how. Design for signifiers.
- Mapping makes controls obvious by spatial and conventional correspondence — natural mapping needs no labels.
- Users act on their mental model, built only from the system image; make that image express your intent so the two models converge.
- Errors live in the gulf of execution ("how do I?") and the gulf of evaluation ("did it work?") — bridge them with signifiers and feedback.
- Lean on familiar metaphors and conventions (cart, trash, Jakob's Law), but only when your behavior matches the real-world script.