Usability and Norman's Principles

Have you ever pushed a door that said pull? Stood at a hob turning the wrong knob? Hunted a website for the one button you needed? That flash of "am I stupid?" is almost never your fault — it is a design failure. The cognitive scientist Don Norman spent a career arguing exactly this, and the poorly-designed door became so famous it earned a nickname: the "Norman door."

Usability is how easily and pleasantly people can achieve their goals with a product. Norman gave us a small, powerful vocabulary for why some things are usable and others infuriating. Master these words and you can diagnose bad design — and avoid it — on purpose, whether you're building a touch app or a command line tool.

The four words that explain (almost) everything

Affordance. What an object lets you do — the relationship between the thing and its user. A flat plate on a door affords pushing; a handle affords pulling or gripping; a slider affords sliding. Affordances are about possibilities, whether or not you notice them.
Signifier. The visible signal that tells you an affordance is there and how to use it. The word "PUSH", an arrow, a underline on a link, the little shadow that makes a button look pressable. Affordance is the possibility; the signifier is the clue. A Norman door has the affordance to be pushed but the wrong signifier (a pull-handle).
Feedback. The system telling you what just happened. A button that visibly depresses, a click sound, a spinner, a "message sent" tick. Without feedback you don't know whether your action worked, so you press again — and again.
Mapping. How the layout of the controls matches the layout of what they affect. Good mapping is spatial and obvious: hob knobs arranged like the burners they control, a volume slider that goes up for louder. Bad mapping makes you guess.

There are two more you should know: constraints (limiting what can be done to prevent errors — a plug that only fits one way, a greyed-out button) and consistency (the same action works the same way everywhere, so knowledge transfers).

They're constantly muddled, so pin it down: an affordance is what an object can do (a chair affords sitting; a door with a flat plate affords pushing). A signifier is the perceivable hint that advertises it (the sign "PUSH", the pressable look of a button). You can have an affordance with no signifier — a hidden keyboard shortcut affords quitting the app, but nothing tells you it exists — and that's exactly the kind of invisible affordance that makes software frustrating.

Norman's seven stages of action

Norman also modelled what your brain does every time you use anything. It's a loop: you start with a goal, cross a Gulf of Execution (figuring out how to act), then cross a Gulf of Evaluation (figuring out what happened). Good design makes both gulfs easy to bridge. Step through the cycle:

A design that bridges the Gulf of Execution uses clear signifiers, good mapping and constraints (so you know how to act). A design that bridges the Gulf of Evaluation gives strong feedback (so you know whether it worked). Bad design widens either gulf and leaves the user stranded.

Diagnosing a real design

Take a lift (elevator) call panel. You want to go up. Good design: two clearly labelled buttons ▲ and ▼ (signifiers), that look pressable (affordance signalled), arranged with up on top (mapping), that light up when pressed (feedback), and that you physically can't press "down" for a top floor (constraint). Now imagine a single unlabelled round button that gives no light when pressed — every one of Norman's principles is broken at once, and you'll stand there jabbing it, unsure if the lift is even coming.

The classic mistake is treating affordance and signifier as the same thing, or calling any on-screen hint an "affordance." Keep them separate:

Affordance = the action the object makes possible (a link can be clicked).
Signifier = the visible clue that reveals it (the link is blue and underlined).

Also don't confuse feedback (telling the user what happened) with mapping (how controls line up with their effects). In an exam, name the exact principle — "poor feedback," "bad mapping," "missing signifier" — not just "bad design."