Perceived Affordances, Signifiers, and Conventions

Core Concepts

From Gibson to Norman: A Necessary Divergence

Module 01 introduced affordances as relational properties — what an environment offers an actor, independent of whether it is perceived. That is Gibson's formulation. It is ecologically precise and theoretically elegant. It is also, for a designer or engineer, incomplete.

Don Norman adapted Gibson's concept for design and human-computer interaction with a decisive shift: rather than asking what an interface objectively allows, Norman asked what users believe they can do. This reframing introduced the concept of perceived affordance — what a user recognizes as a possible action based on perceptual signals from the design.

For design purposes, what matters is not what the interface objectively allows, but what users believe they can do based on their perception of visual, auditory, and haptic feedback.

This is not a weakening of the concept. It is a change in theoretical priority. Gibson was describing perception in the natural world. Norman was addressing a design problem: how do you build things people can actually use? The two projects require different framings, and the affordance concept has evolved in ways that deviate significantly from Gibson's original intentions to accommodate this practical demand.

Norman later acknowledged the semantic distinction explicitly: designers can only control perceived affordances through visual cues — icons, colors, spatial layouts — not the underlying system capabilities. The designer's domain is perception, not physics.

What a Perceived Affordance Actually Is

A perceived affordance is what a user interprets as possible based on what they can observe. It is not a property of the interface alone, nor of the user alone — it is a relationship between the two, mediated by the design.

Perceived affordances result from mental interpretations based on past knowledge and experience, and are supported by visual, auditory, and haptic feedback along with design conventions and constraints. That last clause is critical: past knowledge and conventions are doing heavy lifting here. A user who has spent years with GUI software arrives at any new screen with a dense set of expectations. That prior experience shapes what they see as available actions before they click a single thing.

In digital environments, this becomes the dominant mode of perception. Screens have no inherent material properties that directly suggest action possibilities. A door knob has physical properties — shape, texture, size — that afford grasping and turning; a button on a screen has no comparable physical properties. Therefore, in software, affordances are always perceived — dependent on learned visual conventions, interface design choices, and user experience. There is no fallback to physical reality.

Signifiers: The Communication Layer

Norman's most useful clarification — introduced in the 2013 revised edition of The Design of Everyday Things — is the term signifier.

A signifier is a perceptible cue (visual, auditory, tactile, or other modality) that communicates where action is possible and how to take that action. The signifier is not the affordance. The affordance is the functional capability — what the system can actually do. The signifier is the perceptual signal that makes that capability visible.

The distinction:

• The affordance is that a button accepts clicks.
• The signifier is the raised 3D appearance, the hover effect, the cursor change — everything that tells you the button can be clicked.

In a well-designed interface, the signifier faithfully represents the affordance. In well-designed interfaces, signifiers clearly communicate the affordance, allowing users to discover and use interactive elements without instruction.

Norman introduced the new terminology precisely because practitioners had been conflating these concepts. After the design community adopted "affordance" in 1988, designers often conflated the action possibility with the signal communicating that possibility. By the 2013 edition, Norman was explicit: much of what designers actually work with is signifiers, not affordances. The terminological shift was not pedantry — it was a correction of a persistent and consequential error in design discourse.

Signifiers are also not limited to the visual channel. Signifiers can be conveyed through multiple perceptual modalities: visual (color, shape, text, icons), auditory (sounds, tones), and haptic/tactile (vibration, resistance, pressure). William Gaver's work in 1991 emphasized that affordance-relevant information includes tactile and auditory signals, not just visual ones — a point that carries direct implications for accessibility.

Conventions as Compressed Signifiers

Not every signifier is an explicit visual cue. A large share of what makes an interface navigable is convention: accumulated, shared understanding about how things work in a particular design tradition.

Perceived affordances in software interfaces are significantly shaped by design conventions and user expectations, which are learned and culturally contingent. Underlined blue text signifies a link not because anything in the physics of pixels demands it, but because decades of convention have made this association automatic for vast numbers of users. The convention is the signifier.

This points to something designers and engineers regularly underestimate: what is intuitive for users familiar with desktop GUI conventions may be opaque for users unfamiliar with those conventions. There is no such thing as an objectively intuitive interface. "Intuitive" means "matches the prior knowledge and conventions of this particular user population." Affordances that are obvious within one design tradition can be invisible in another.

Cultural contingency is not a marginal edge case. Empirical research documents that light switch affordances differ between US and UK users: US users interpret upward movement as "ON" and downward as "OFF," while UK users interpret the reverse. The same mechanical interaction affords different meanings depending on which regional convention the user has internalized. And a checkmark symbol, which in Western cultures signals approval or completion, may indicate incorrectness or negative evaluation in some Asian cultural contexts. Identical visual elements can afford fundamentally different interpretations — and therefore different actions — depending on the user's background.

Compare & Contrast

Gaver's Four-Cell Framework

William Gaver's 1991 paper "Technology Affordances" extended Norman's framework into a structured vocabulary for diagnosing how systems succeed or fail at communicating their capabilities. Gaver analyzed the relationship between two independent variables: whether an affordance is actually present, and whether a perceptual signal (signifier) is present.

Fig 1

This four-cell model provides a diagnostic vocabulary that generalizes directly from UI to code:

Category	Affordance	Signifier	Effect
Perceptible	Present	Present	User can discover and use the capability.
Hidden	Present	Absent	Capability exists but is invisible; requires exploration or documentation.
False	Absent	Present	Signifier misleads; user attempts an action that does not work.
Correct Rejection	Absent	Absent	Interface makes no promises it cannot keep.

Hidden affordances reduce discoverability and usability because users cannot perceive what is possible without additional cues or learning. False affordances create user frustration because they violate the implicit contract between perceived and real affordance. Correct rejection, while inelegant, is at least honest — it does not misdirect.

In a codebase, "signifier" maps onto names, type signatures, module boundaries, docstrings, and structural patterns — everything that shapes how another engineer reads the system's capabilities. The four categories apply verbatim.

Worked Example

The Norman Door — and Its API Equivalent

Norman's most famous example is the door that has a pull handle on a push side. The handle is a signifier — its shape affords pulling, so the user pulls. But the door requires pushing. The real affordance (pushability) is contradicted by the perceived affordance (pullability). The result is a moment of confusion so common Norman's name was eventually attached to it: a Norman Door.

Now consider an API equivalent. A method is named getUser(id). The name is a signifier. It implies: read-only, retrieves a user, produces a result. The actual implementation — the real affordance — issues a write to an audit log, increments a counter in a rate-limiting table, and triggers a downstream event. None of this is signified. The method name is a Norman Door.

Walk through the Gaver framework:

• The real affordances include: fetching a user record, writing an audit entry, incrementing a counter, triggering a downstream event.
• The signified affordance is: fetching a user record.
• The audit write, counter increment, and event trigger are hidden affordances — functionally present but perceptually invisible.
• Nothing signals the side effects. Users of this method will discover them through bugs, not through reading.

Now consider the reverse failure. A method is named publishEvent(payload). Convention says this will deliver the event. In fact, the method silently enqueues a task and returns without error if the queue is full. The signifier (publishing) promises a real affordance (delivery) that does not exist in the full sense. This is a false affordance — the method name creates a perceived affordance that the implementation does not honour.

The engineering lesson tracks exactly with the design lesson. The affordance (what the code actually does) and the signifier (how it is named, typed, and documented) must be aligned. Where they diverge, another engineer will eventually fall through the gap.

Common Misconceptions

"If I build the capability, the affordance is there."

This confuses real affordance with perceived affordance. Capability that no one can find or understand is not usable capability. An interface may possess a functional capability that users fail to perceive — and a method, module, or API that no one knows how to use correctly has, from a practical standpoint, failed. The real affordance is necessary but not sufficient.

"Intuitive just means obvious."

It means obvious to this specific group with this specific background. Claims about "intuitive design" or "obvious affordances" are only valid within specific user populations with shared prior experience and cultural conventions. An API that is obvious to the team that built it, with full knowledge of its internal model, may be completely opaque to an onboarding engineer approaching it fresh. "Obvious" is always relational.

"Signifiers are a UI concern. Code is different."

Signifiers are perceptual cues that communicate affordances. In a codebase, those cues are method names, type signatures, return types, module boundaries, naming conventions, and structural patterns. Every design choice that shapes how another engineer reads a system is, functionally, a signifier. The mechanism is identical; only the modality differs.

"Norman door problems are physical design failures. Software doesn't have them."

When the signifier contradicts the real affordance, users experience confusion and frustration — in physical and digital systems. A configuration parameter named timeout_ms that actually accepts seconds is a Norman Door. A flag named dry_run that still writes to a database is a Norman Door. The physical form is different; the failure mode is identical.

"Conventions are just habits. I can define my own."

Conventions are learned through accumulated experience and carry substantial cognitive weight. Signifiers that are effective in one cultural or design context may be ineffective in another where different conventions prevail. An engineering team that invents its own naming or structural conventions without considering what incoming engineers will expect is designing a system with non-standard signifiers. The capability may be present; the perception will not follow automatically.