Four Knobs in a Row: Mental Models

A hotel bathroom. One lever, no markings. You lift it — nothing. You turn it left, wait, turn it further, and get scalded. At home you do all this without looking, in half a second, while thinking about something else.

Same task, same hands. What's missing is the picture in your head: which way is hot, how long it takes, what this lever even controls. At home that picture is complete. Here you have to rebuild it by experiment, and the experiments hurt.

Three models, one channel

Don Norman drew a diagram that is worth carrying around for the rest of your career. It has three parts.

The designer's model — the full, correct picture of how the system works. It lives in your head, in the code, and in the documentation.

The user's model — the picture in the head of the person using it. Built from what they see, what they've used before, and what happened last time they tried.

The system image — everything the product actually shows: the screen, the labels, the icons, the sounds, the way it behaves.

The uncomfortable part is what connects them. The designer and the user never meet. The user's model is built only out of the system image. Every explanation you didn't put into the interface — every "it's obvious," every "we'll cover it in the docs" — simply doesn't arrive.

The user never talks to you. They talk to the screen.

That single fact converts most design arguments into something checkable. "But it's logical" is a statement about your model. The only question that matters is what the system image says on its own, to someone who wasn't at the meeting.

Affordances and signifiers

Back to the door for a moment, because Norman uses it to separate two ideas people constantly merge.

An affordance is what an object makes possible: a flat panel affords pushing, a handle affords gripping and pulling, a slot affords inserting. It's a relationship between the thing and the person's abilities, and it exists whether or not anyone notices.

A signifier is the sign that tells you the affordance is there. The handle isn't just pullable — it announces pulling. Norman added this term in the 2013 revision of his book precisely because "affordance" had been misused for years to mean "visual hint."

The distinction earns its keep on screens, where nothing is physically anything. A button can't literally be pressed; a card can't literally be dragged. Everything is a signifier: the shadow that says "raised," the underline that says "link," the rounded rectangle that says "tap here," the cursor that changes shape. Strip the signifiers — the flat era of interface design tried this — and the affordance becomes invisible. The thing is still clickable. Nobody clicks it.

Two failure modes follow, and they are opposites:

A signifier with no affordance — it looks tappable, nothing happens. This is the more infuriating one: the interface lied.
An affordance with no signifier — it works, nobody finds it. Every hidden gesture, every swipe-to-do-something with no visible hint, lives here.

Mapping and feedback

Two more mechanics decide whether a person's model can form at all.

Mapping is how well the arrangement of the controls matches the arrangement of the things they control. Norman's example is a stove: four burners in a square, four knobs in a row. There's no way to know which knob is which, so every cook learns their own stove by trial and error, and every guest burns something. Arrange the knobs in a square that matches the burners, and there's nothing to learn.

Screens have the same problem in a hundred quiet forms. A settings toggle far from the thing it affects. A filter panel that doesn't visibly change the list. An "advanced" section holding a switch that alters the main screen. Distance between cause and effect is where mental models go to die.

Feedback is the system telling you what happened. Robert Miller established the thresholds in 1968 and they haven't moved, because human perception hasn't:

0.1 s — feels instant, like direct manipulation. Under this, no indicator is needed.
1 s — the thread of thought survives, though the delay is felt. Still no spinner; a spinner here makes it feel slower.
10 s — the limit of attention. Beyond it, you need progress that visibly moves, and ideally something to read.

IBM's Walter Doherty added a commercial angle in 1982 with the Doherty threshold: when a system responds in under about 400 ms, people don't just wait less, they work in a qualitatively different way — faster, more experimentally, with more attention on the task and less on the machine.

The rule that follows is blunt: every action gets an acknowledgement, immediately. Not when the server answers — immediately. The button changes state, the row appears greyed, the item moves. If it fails, you undo it and say so. That's optimistic feedback, and it's the reason good apps feel fast on bad networks.

The two gulfs

Norman splits every usability problem into one of two gaps, and the split is genuinely useful when you're staring at a screen with no idea what's wrong.

The gulf of execution — the distance between what a person wants to do and knowing how to do it here. What can I do? How do I do it? Where is it? Hidden features, unlabelled icons, unclear entry points.

The gulf of evaluation — the distance between what happened and understanding what happened. Did that work? What state am I in now? What did it just do? Missing confirmations, silent failures, changes with no visible result.

Try it on your own product. Take one task, walk it, and write down every question a first-timer would silently ask. Sort them into the two columns. The taller column tells you what kind of designer you need to be this week.

Jakob's law: the model was built elsewhere

Here's the part that hurts ambitious designers.

Jakob Nielsen's formulation: users spend most of their time on other sites. Their model of "how a website works," "how a cart works," "what that icon means," was assembled from hundreds of other products — and yours gets a few minutes to fit into it.

This isn't an argument against originality; it's an argument about where to spend it. Every convention you break has a price paid in relearning: the logo in the top-left going home, the cart in the top-right, the magnifier meaning search, the underlined text being a link, the back gesture, the primary button on the right in one ecosystem and the left in another. Break one and you'd better be buying something with it.

The trap is that this cost is invisible to you specifically. You've seen your interface a thousand times; your model of it is perfect. There's a whole article ahead on why your own fluency is the least reliable instrument in the building.

When the models diverge

Some of the worst product failures are simply two models drifting apart until they snap.

The classic is the trash can. In the user's model, deleting a file in a synced folder means "get this off my computer." In the system's model, it means "delete it everywhere, for everyone, including your colleague who is editing it." Both models are internally coherent. Only one of them was shown.

Or: a person edits a document, closes the laptop, and assumes it's saved because the last five apps they used autosaved. Or: they add an item to a cart on their phone and expect it on the desktop. Or: they press Back and expect the form to still be filled in.

None of these are stupidity. They are correct predictions from a model built on other products, applied to yours. Which gives you the diagnostic question for any support ticket that starts with "the user thought that…": what did the interface show that made this the reasonable conclusion?

In practice

Ask people to draw it. Give someone a pen and ask them to sketch how they think your product is organised, or where their data lives. It takes two minutes and reveals the gap between models faster than any interview question.

Read your screen as a stranger. Point at each element and say out loud what it promises. Then check whether it delivers exactly that. Anything that promises more than it does is a lie you shipped.

Cover the labels. Hide the text under your icons and see if you can still name them. Almost nobody can, beyond the five or six truly universal ones. The conclusion is not "better icons" — it's "keep the label."

Put cause next to effect. For every control, ask where its result is visible. If the answer is "on another screen," either move it or show the result where the control lives.

Acknowledge instantly, confirm later. Never let a click produce nothing for a second. Change the state now, reconcile with the server after, undo loudly if it failed.

When the model must be new, teach it once. Occasionally your concept genuinely has no precedent. Then it needs an explicit, one-time explanation at the moment of first use — not a tour of the whole app, one sentence where the concept first appears.

Check yourself

Close the article and answer in your own words:

Why can't the designer's model reach the user directly, and what follows from that?
What is the difference between an affordance and a signifier, and what does each look like when it's missing?
What does the stove-knob problem look like in an interface you use?
What are the three response-time thresholds and what changes at each?
A user clicks a button and the row doesn't change until the server answers. Which gulf is that, and what's the fix?
What does Jakob's law actually forbid — originality, or something narrower?
A support ticket says "the user thought the file was only deleted on their machine." What's the question you ask next?

In short

Three models: yours, the user's, and the system image between them. The user builds their model only from what the product shows.
An affordance is a possible action; a signifier is the sign that it's possible. On screens, everything is a signifier — remove them and features go invisible.
Mapping is the match between the arrangement of controls and the arrangement of effects. Distance between cause and effect breaks understanding.
Feedback thresholds: 0.1 s instant, 1 s thought survives, 10 s attention ends; under ~400 ms people work in a different mode entirely.
Gulf of execution: "how do I do this?" Gulf of evaluation: "what just happened?" Every usability problem is one or the other.
Jakob's law: people's models are built on other products, so every broken convention is paid for in relearning.
When a user "thought wrong," ask what the interface showed that made their conclusion reasonable.