Affordance

Affordance

Affordance is the relationship between an object's properties and the actions it makes possible. A door handle affords pulling; a flat plate affords pushing; a button affords pressing; a slider affords sliding. When the affordance matches the intended use, the design works without instruction. When the affordance contradicts the intended use, even a sign saying "PUSH" cannot fully repair it — users still try to pull the handle first.

Definition (in our own words)

Affordance is what an object's appearance, shape, weight, and material tell the user about what they can do with it. The affordance lives partly in the object itself (a button has a graspable shape) and partly in the user's perception of it (a child seeing a button for the first time has a different model than an adult who's seen ten thousand). Designers control the visual and behavioral signals; users bring prior experience. Where the two align, the design "just works"; where they diverge, the user must read, ask, or guess.

Origins and research lineage

• James J. Gibson, The Ecological Approach to Visual Perception (Houghton Mifflin, 1979). Gibson coined "affordance" in ecological psychology to describe what an environment offers an animal: a horizontal surface affords standing; a graspable object affords carrying. The concept predates HCI but maps naturally to it.
• Donald Norman, The Design of Everyday Things (1988, revised 2013). Translated affordance from Gibson's perceptual psychology into design vocabulary. Norman's iconic example — doors that look like they pull but actually push — became shorthand for affordance failure.
• Norman's later refinement — "Signifiers, not affordances" (2008). Norman clarified that what designers actually control are signifiers (visible cues that suggest an action). The affordance is the underlying possibility; the signifier is what tells the user about it. The book's principle covers both, but the distinction matters in fine-grained design discussion.
• Lidwell, Holden & Butler (2003) compactly stated the principle as "a property in which the physical characteristics of an object or environment influence its function" and gave the door-handle-vs-flat-plate example as the canonical illustration.
• Web/UI affordance research — Bagrow, Tognazzini, and many others have studied how affordance translates to flat 2D screens. The shift from skeuomorphic to flat design (around 2013) reduced traditional affordance signals; subsequent recovery (subtle shadows, hover states, motion) has rebuilt them in less literal forms.

Why affordance matters

Affordance is the fastest comprehension channel a UI has. A user looking at a screen for half a second can tell — preattentively, before reading a single label — which elements are interactive and which are content. Strong affordance lets the user form a working theory of the page in seconds; weak affordance forces them to point at things and watch what happens.

The cost of weak affordance compounds:

• Time wasted hovering over non-interactive elements to check.
• Time wasted scanning for the interactive element among the inert ones.
• Misclicks on things that look interactive but aren't (or vice versa).
• Anxiety about what happens when something is clicked.
• Eventual learned helplessness — users stop exploring and stick to the obvious paths.

When to apply

• Every interactive element must have an affordance signal. This is non-negotiable.
• Every non-interactive element must not look interactive. False affordance is as damaging as missing affordance.
• Custom controls — when reaching past native HTML elements, you take on responsibility for the affordances those native elements provided for free.
• Empty states and onboarding — affordance carries the "what can I do here?" answer before any text does.
• Touch surfaces — touch has no hover, so affordance must work in the still state.

When NOT to apply (or when to be careful)

• Decorative elements that aren't interactive should not have affordance signals. A "Welcome" banner shouldn't look like a button just because it's prominent.
• Disabled controls need anti-affordance — visibly different (lower opacity, different cursor) so users don't try to interact.
• Power-user-only controls in dense UIs can have subtler affordance because experts use spatial memory; new-user surfaces need stronger cues.

What the user reads as affordance

Affordance signals fall into a small set of categories:

Shape and outline

A bordered, rectangular shape with text inside reads as a button — across cultures, across years. The convention is so strong that it survives flat design: even a single-line border is enough to communicate "pressable."

Color contrast against context

An element that's a different color than its surroundings reads as set apart, often as interactive. The brand-color CTA is the canonical case.

Depth and elevation

Drop shadows, gradients, raised edges all suggest "pressable object floating above the page." Even subtle elevation (box-shadow: 0 1px 2px rgba(0,0,0,0.05)) is enough to communicate "this is a button, not flat content."

Cursor change

Hover changes the cursor (cursor: pointer) — a strong "this is clickable" signal on desktop. For touch users this doesn't help; pair with visual signals.

Hover and focus state

Color change, shadow shift, slight scale on hover signals "this responds to you." Focus ring on keyboard focus signals "this is interactive and currently selected."

Underline (for links)

Underlined text reads as a link. The convention is so old it predates the web (footnotes in print). Stripping link underlines for aesthetic reasons damages affordance — color alone is weaker, especially for color-blind users.

Iconography

A trash-can icon affords delete; a pencil icon affords edit; a magnifying glass icon affords search. These are learned affordances — they require prior exposure — but conventional icons have become as universal as physical-object affordances were before screens.

Position and grouping

Buttons clustered at the bottom of a card or modal afford "primary actions." A control isolated in the corner of a row affords "this row's options." Position carries affordance through learned UI conventions.

Worked examples

Example 1: button vs. text vs. plain content

<!-- Plain content: no affordance, none expected -->
<p>Your account expires in 14 days.</p>

<!-- Link: text-link affordance (color + underline on hover) -->
<p>Your account expires in 14 days. <a href="/billing">Update billing</a></p>

<!-- Button: button affordance (shape + background) -->
<p>Your account expires in 14 days.</p>
<button class="btn-primary">Update billing</button>

.btn-primary {
  background: hsl(220 90% 50%);
  color: white;
  padding: 8px 16px;
  border: 0;
  border-radius: 6px;
  font-weight: 500;
  cursor: pointer;
}
.btn-primary:hover { background: hsl(220 90% 45%); }
.btn-primary:focus-visible {
  outline: 2px solid hsl(220 90% 50%);
  outline-offset: 2px;
}

a { color: hsl(220 90% 40%); text-decoration: underline; text-decoration-thickness: 1px; text-underline-offset: 2px; }
a:hover { text-decoration-thickness: 2px; }

The plain <p> reads as content. The <a> reads as a link via color + underline. The <button> reads as a button via shape + color + cursor + hover.

Example 2: clickable card

A common modern pattern: a card that's entirely clickable. The challenge: a card looks like content by default; making it clickable requires explicit signals.

<a href="/projects/acme" class="card-link">
  <article class="project-card">
    <h3>Acme Project</h3>
    <p>Q4 marketing site refresh</p>
    <p class="meta">3 open tasks · Due May 15</p>
  </article>
</a>

.card-link { text-decoration: none; color: inherit; display: block; }
.project-card {
  border: 1px solid hsl(0 0% 88%);
  border-radius: 8px;
  padding: 16px;
  background: white;
  transition: border-color 150ms, box-shadow 150ms, transform 150ms;
}
.card-link:hover .project-card {
  border-color: hsl(220 90% 60%);
  box-shadow: 0 4px 12px rgba(0,0,0,0.08);
  transform: translateY(-1px);
}
.card-link:focus-visible .project-card {
  outline: 2px solid hsl(220 90% 50%);
  outline-offset: 2px;
}

The card's affordance: subtle border in the still state (suggesting "object, not flat content"), strong response on hover (border color, shadow lift, slight upward translate). Without those state changes, the card looks identical to a non-clickable info panel.

Example 3: drag handle

A drag handle is a deliberately-novel control; its affordance must teach the user.

<li class="sortable-row">
  <button class="drag-handle" aria-label="Drag to reorder">
    <svg viewBox="0 0 24 24" width="16" height="16">
      <circle cx="9" cy="6" r="1.5" /><circle cx="9" cy="12" r="1.5" /><circle cx="9" cy="18" r="1.5" />
      <circle cx="15" cy="6" r="1.5" /><circle cx="15" cy="12" r="1.5" /><circle cx="15" cy="18" r="1.5" />
    </svg>
  </button>
  Task name
</li>

.drag-handle {
  cursor: grab;
  background: transparent;
  border: 0;
  padding: 8px;
  color: hsl(0 0% 60%);
}
.drag-handle:hover { color: hsl(0 0% 30%); }
.drag-handle:active { cursor: grabbing; }

The signals: the six-dot icon (an established convention), cursor: grab (signals "you can pick this up"), and a hover state to confirm the control responds.

Example 4: editable inline text

A field that becomes editable on click — useful but affordance-fragile because the field looks like static text by default.

<h2 class="editable" contenteditable="true">Project name</h2>

.editable {
  cursor: text;
  border-bottom: 1px dashed transparent;
  padding-bottom: 2px;
  transition: border-color 150ms;
}
.editable:hover { border-bottom-color: hsl(0 0% 70%); }
.editable:focus {
  border-bottom-color: hsl(220 90% 50%);
  outline: 0;
}

Hover signals "you can interact" via the dashed underline. Focus locks in via solid color. Without these, users don't realize the heading is editable until they accidentally click and panic.

Example 5: anti-affordance for disabled controls

<button class="btn-primary" disabled>Save (no changes)</button>

.btn-primary[disabled] {
  background: hsl(0 0% 92%);
  color: hsl(0 0% 50%);
  cursor: not-allowed;
}
.btn-primary[disabled]:hover { background: hsl(0 0% 92%); /* no change */ }

The disabled state visibly removes affordance: lighter color (recedes), cursor: not-allowed (signals impossibility), no hover response. Pair with a label or tooltip explaining why it's disabled — disabled affordance tells the user they can't, but not why.