Affordances, Signifiers & Feedback (Norman's Model)

The full lesson

When a user stares at a button and wonders “does clicking this do something?” — or pushes a door that needs to be pulled — that is a design failure. Donald Norman’s model, developed in The Design of Everyday Things (1988, revised 2013), gives us precise words for diagnosing and fixing these failures.

Three concepts do the work:

• Affordances describe what actions are possible.
• Signifiers communicate what actions are perceived as possible.
• Feedback closes the loop by confirming what happened.

Together they form the bedrock of intuitive interaction design.

Affordances: What the Object Actually Allows

An affordance is a relationship between an object (or interface element) and a user that makes a particular action possible. Norman borrowed the term from psychologist James Gibson, who used it to describe how animals perceive action possibilities in their environment. A flat rock affords sitting. A stone affords throwing.

In digital interfaces, affordances depend on the user. A text field affords typing. A drag handle affords repositioning. A swipe target affords dismissal. Crucially, an affordance exists whether or not the user perceives it. A dropdown menu affords selection even if the user never discovers it.

Physical vs. Perceived Affordances

Norman draws a distinction many designers miss:

Type	Definition	UI Example
Physical affordance	What the system actually allows	A list item can be reordered by drag
Perceived affordance	What the user believes they can do	User does not realize items are draggable

A physical affordance with no perceived affordance is invisible — it exists but goes unused. Most “discoverability” problems in software are exactly this gap. Pull-to-refresh, force-touch menus, and keyboard shortcuts are all affordances with poor or absent signifiers.

Signifiers: Making Affordances Visible

A signifier is any perceptible signal that tells users how something can be used. It bridges the gap between a physical affordance and a user’s perceived affordance. Signifiers can be intentional (a button’s visual treatment, a drag handle icon, a tooltip) or accidental (a worn path across a lawn — called a desire line — that reveals where people actually walk).

Signifiers are the designer’s primary tool. You usually cannot change what a system affords without rebuilding it. But you can almost always improve the signifiers that communicate those affordances.

Categories of Signifiers in UI

• Visual shape cues. Raised or beveled button styles, underlines on links, card shadows, border radius, and fill color all signal “this element responds to clicks.” Flat design stripped many of these away, creating interfaces where tappable and non-tappable elements looked identical.
• Labels and microcopy. The clearest signifier is often just a word. “Drag to reorder”, “Click to expand”, and “Swipe left to dismiss” are explicit signifiers. They cost attention but prevent confusion.
• Icons and iconography. Icons only work as signifiers when users already understand them. The hamburger icon (three horizontal lines) is still widely misread outside of tech-savvy audiences — research consistently shows it performs worse than a labelled “Menu” button for non-expert users.
• Motion and state change. A button that depresses on hover, a card that lifts on focus, a progress bar that starts filling — these are dynamic signifiers that signal interactivity through behavior. They are especially powerful for affordances that have no physical-world equivalent.
• Cursor change. The browser cursor is an underused signifier. The pointer cursor communicates clickability, grab communicates draggability, and text communicates editability. A cursor that does not match the affordance creates small friction that accumulates across a session.

Feedback: Closing the Action Loop

Feedback is the system’s response that confirms an action occurred, shows the result, and indicates the new state. Without feedback, users cannot verify that their action worked. They either repeat it (double-submit, double-click, redundant tap) or abandon the task unsure of what happened.

Norman identifies feedback as one of seven fundamental interaction design principles. It is also the one most frequently omitted in modern software — especially in async, API-driven interfaces where server responses are not instantaneous.

The Feedback Loop in Practice

A complete feedback loop has three moments:

1. Preemptive feedback (before action). A loading indicator, a disabled state, a tooltip — anything that sets expectations before the user commits. “This will delete 47 items” is preemptive feedback on a destructive operation.
2. Immediate feedback (during action). The button depresses. The drag indicator appears. The progress bar fills. This confirms that the system received the action and prevents users from repeating something they think did not register.
3. Outcome feedback (after action). A success message, an error with a recovery path, a changed state. The user’s understanding of the world is now updated.

Missing any of these three moments creates a feedback gap. The most common gap today is the immediate moment: async operations that give no visual acknowledgment of receipt, leaving users wondering whether their click registered at all.

Feedback Timing and the Doherty Threshold

Norman’s work on feedback intersects with the Doherty Threshold (covered in a separate lesson). Responses delivered within 400ms feel instantaneous and need no explicit “loading” signifier. Responses between 400ms and ~2 seconds need a subtle indicator — a spinner or a button state change. Responses over 2 seconds need a progress bar or skeleton screen that communicates both that the system received the action and gives a sense of how long to wait.

Error Feedback: The Most Neglected Corner

Error states are feedback too — and they fail more often than success states. Generic messages like “Something went wrong” or “Invalid input” give the user nothing to act on. They force the user to diagnose the problem from scratch, which is pure wasted mental effort.

WCAG 2.2 Success Criterion 3.3.1 requires that input errors be identified and described in text. That is a floor, not a ceiling. Modern best practice goes further:

• Name the specific problem. “Phone number must be 10 digits — no spaces or dashes” tells the user exactly what went wrong.
• Prescribe the fix. “Re-enter your email address” is more actionable than “Email not recognized.”
• Position the message near the field. Errors scrolled off-screen are invisible. Use aria-describedby to link the error to the input for screen readers.
• Validate on blur, not on submit. Waiting until form submission to surface errors means users complete the entire form before learning they made a mistake ten fields ago. Inline validation on blur — when the user leaves a field — catches errors at the moment of lowest interruption cost.

Mapping: The Bridge Between Signifiers and Feedback

Norman introduces natural mapping as a related principle: controls should be arranged spatially to match the things they control. A stove knob placed above and to the left of the left-front burner has natural mapping. Four identical knobs in a horizontal row do not.

In interface design, mapping appears in:

• Tab order and visual order alignment. Keyboard navigation should follow the visual left-to-right, top-to-bottom reading order. A mismatch between DOM order and visual order — a common CSS Grid side effect — destroys the mapping between the user’s visual model and their keyboard experience.
• Proximity between controls and their effects. A “Delete row” button in a table should sit on the row it deletes, not in a toolbar at the top of the screen.
• Directional controls. A carousel “next” arrow on the right should move content to the left, revealing new content from the right. Reversing this breaks the spatial metaphor.

Conceptual Models: Why Signifiers Must Match the System Image

Norman’s model also includes conceptual models — the mental model a user builds about how a system works. Users form this model entirely from the system’s image: what the UI shows them. A good conceptual model lets users predict the outcome of actions they have never taken before.

Signifiers build conceptual models. Every visual affordance cue, every label, every piece of feedback teaches the user something about how the system works. When those signals are inconsistent — when the same interaction has different effects in different parts of the app, or when similar-looking elements behave differently — users build inaccurate mental models and errors follow.

This is why consistency is not an aesthetic value but a usability requirement. A design system enforces consistent signifiers across components, which in turn builds a consistent and accurate conceptual model. When a user learns that a filled blue button is always the primary action, that becomes a reliable signifier throughout the entire product.

Applying Norman’s Model to Modern Interface Patterns

Forms

Forms are a dense intersection of all three concepts. Each field must signal what it affords (a text box signals typing, a dropdown signals selection), provide clear signifiers (persistent label, input format hint, character count), and give feedback at every moment (on focus, on blur with inline validation, on submit with success or error state).

The outdated pattern of placeholder-as-label fails on all three counts. It destroys the signifier because the label vanishes on input. It misrepresents the affordance because users sometimes mistake placeholder text for pre-filled content. And it eliminates any feedback anchor for errors.

Navigation

Persistent visible navigation is a signifier for the product’s structural affordances — the places a user can go. Hiding navigation behind a hamburger menu on desktop removes the signifier for the affordance. This is why task-completion benchmarks consistently show worse performance on hamburger-hidden navigation. The affordance (the ability to navigate) still exists, but without a visible signifier it goes undiscovered.

Loading and Async States

An async action with no immediate feedback breaks the signifier-feedback loop. The user cannot tell whether the affordance worked. Skeleton screens — introduced by Luke Wroblewski and popularized by Facebook around 2013 — are a form of outcome feedback that communicates shape before content. This also reduces perceived load time by setting accurate expectations. Skeleton screens outperform generic spinners for content-heavy layouts because they provide richer information about what is coming. Spinners remain appropriate for short blocking operations (under 1-2 seconds) where a skeleton would add more complexity than the wait justifies.

Touch and Gesture Interfaces

Touch affordances are notoriously under-signified because gestures have no visible form until performed. Pull-to-refresh is a classic example: the affordance existed for years before designers added the rubber-band animation — a signifier — that communicates “you are approaching the threshold.” Without the signifier, users who discovered the gesture did so by accident. Modern best practice is to provide at minimum an onboarding signifier (an animated hint on first use) and a persistent motion signifier (the rubber-band or progress indicator) for non-obvious gestures.