Usability failure

Signifiers: an affordance nobody can see is not a feature

A signifier is the perceivable cue that tells someone an action is possible — the shading, border, colour or shape that says “this is a button”. An affordance is the action being possible at all. The two are independent, and an interface can be technically correct and semantically valid while offering no visible sign of where to act. Eyetracking finds that weaker clickability cues cost measurable time and attention on ordinary tasks.

What it is

Donald Norman introduced “affordance” to design from ecological psychology, and then spent years correcting how the field used it. In Interactions in 1999 he set out the distinction plainly: what a designer actually controls on a screen is the perceived affordance — the cue that suggests an action — not the affordance itself. A screen can be clicked anywhere; that is its real affordance and it never changes. What changes is whether the user has any reason to believe a particular region will respond. Norman later settled on “signifier” for that perceivable cue, precisely because “affordance” kept being used to mean it.

The practical form of the distinction is this. Whether a control works is one question. Whether anybody can tell it is a control is a completely separate question, answered by different evidence, and a product can pass the first and fail the second without any test noticing.

The Nielsen Norman Group measured the cost in an eyetracking study in 2017. Seventy-one participants each performed tasks on nine real web pages, each prepared in two versions differing only in the strength of their clickability cues. On the pages with weak signifiers, participants spent 22% more time and made 25% more eye fixations, both statistically significant. They were not confused in a way they would report; they were simply slower, and looked at more things, to reach the same place.

The first level of this game is the distinction reduced to its smallest possible form. The instruction sentence reads “To get started, enter your name and then tap Submit.” The word “Submit” in that sentence is a real HTML button element — it is focusable by keyboard and a screen reader announces it as a button, so its semantics are entirely correct. What it has no longer got is any signifier: no background, no border, no padding, the surrounding paragraph’s font and weight, a body-text grey, and a text cursor rather than a pointer. Below it sit two large, well-styled buttons labelled “Cancel” and “Save”, neither of which submits anything.

So every visual cue points at two controls that do not do the job, and the control that does the job carries none. Nothing is broken. Nothing would fail an automated accessibility check. The level is only difficult for people who look at it.

Why it works on people

People do not read an interface and then decide where to click. They scan for the shapes that experience has taught them are actionable, and act on the first plausible candidate. That scan is fast, largely pre-attentive, and driven by visual properties — contrast against the surrounding surface, an enclosing boundary, a fill, a shadow, an underline, a conventional colour.

A control that lacks those properties is not merely less obvious; it is absent from the candidate set. The user is not weighing it and rejecting it. It never entered the comparison, which is why they can stare directly at a link for thirty seconds and not see it, and why they get frustrated in a way that feels disproportionate — the interface has told them the thing they need does not exist.

Conventions do most of the work here, and conventions are learned rather than natural. Norman’s 1999 argument is that much of what designers call affordance in graphical interfaces is really convention: there is nothing intrinsically clickable about a blue underlined phrase, but three decades of the web have made it a reliable signal. Conventions are cheap to use and expensive to break, and their value is precisely that they were not invented by you.

Flat visual styles are not the villain, but they removed the cheapest signifiers first. Shadows, bevels and gradients were doing real perceptual work; when they went, the remaining budget for “this is actionable” was colour and position alone. That is a thin budget, and it is the one that fails hardest for users with colour vision deficiency, on low-contrast displays, in bright sunlight, or for anyone tired.

The failure is systematically invisible to the people who build the product. A designer knows where the button is; they placed it. A developer knows it is a button; they wrote it. Both perceive a signifier that is not in the pixels but in their memory, and neither can un-know it. This is why the problem survives internal review and surfaces only in support tickets or in a session with someone who has never seen the screen.

Semantic correctness and perceivability are genuinely independent, and conflating them is the most common way teams talk themselves out of the problem. Correct markup serves assistive technology and is non-negotiable. It does nothing whatsoever for a sighted user scanning for a shape. This level is the proof: perfect semantics, zero discoverability.

Where you meet it

  • A primary action styled as plain text next to a heavily styled secondary action, so the visual hierarchy is the exact inverse of the intended one.
  • “Ghost” or outline-only buttons used for the main action on a page, with a border light enough to disappear against the surface on a laptop screen at an angle.
  • Body text with links that carry no underline and only a slight hue shift, indistinguishable in greyscale and to a substantial fraction of readers.
  • Icon-only controls with no label, no border and no background, relying on the user recognising a glyph they have not seen before.
  • Entire regions made clickable — a card, a table row, a tile — with no cue at the point where the eye lands, so the interaction is discovered only by accidental hover.
  • Actions that appear on hover alone, which are invisible on any touch device and to anyone navigating by keyboard.
  • A pointer style that contradicts the element’s behaviour — a text cursor on a button, or a pointer on something inert — teaching the user the wrong lesson at the moment they are testing their guess.
  • Disabled controls styled so much like enabled ones that users repeatedly click them, or enabled ones styled so faintly they are assumed to be disabled.

Designing around it

  • Separate the two questions explicitly in review. Ask whether the control works, and then ask, as a distinct item with distinct evidence, whether a first-time user can locate it. A control that passes the first and fails the second is broken, and needs to be recorded as broken.
  • Give every actionable element at least two independent signifiers, one of which is not colour. A border plus a fill, a fill plus a shadow, an underline plus a weight change. Colour alone fails for colour-blind users, in greyscale, in sunlight and on cheap displays — the same redundancy argument the colour-only UI page makes in detail.
  • Use the platform’s conventions rather than your own. The value of an underlined link or a filled rectangle is that the user learned it somewhere else and brought it with them. Novel signifiers have to be taught, and you do not get to teach them.
  • Make the primary action the most visually prominent thing in its group, always. If the secondary action is more strongly styled, users will click it — not because they misread, but because they never got as far as reading.
  • Never let the pointer style contradict behaviour. A pointer cursor on things that respond, the default arrow on things that do not, and never a text cursor on a control. The pointer is the user’s cheapest test of a hypothesis and it should always answer honestly.
  • Do not rely on hover to reveal an action. Hover does not exist on touch, does not exist for keyboard navigation, and is not discoverable by anyone who has no reason to move the pointer there. Anything hover reveals must be reachable another way.
  • Test with someone who has never seen the screen, and give them the task rather than the tour. The five seconds before their first click tell you more about your signifiers than any amount of internal discussion, because you cannot un-know where your own button is.
  • Watch the aggregate for the signature: a page with a high dwell time, a lot of undirected mouse movement, and clicks landing on inert regions near the real control. That combination means people are hunting, and it is measurable long before anybody files a complaint.

Questions

What is the difference between an affordance and a signifier?

An affordance is an action being possible; a signifier is the perceivable cue that tells someone it is possible. Donald Norman drew the distinction after watching the design field use “affordance” to mean the cue. On a screen the distinction is sharp: any pixel can be clicked, so what a designer actually designs is the signifier — the border, fill, colour or shape that makes a region look like it will respond.

Can a control be accessible and still be impossible to find?

Yes, and the two properties are independent. A correctly marked-up button is focusable by keyboard and announced as a button by a screen reader regardless of how it is painted. Strip its background, border and padding and give it body-text colour, and it becomes invisible to a sighted user scanning for something to click while remaining fully conformant to the criteria that govern name, role and value.

Is flat design bad for usability?

Not inherently, but it removed the cheapest clickability cues and many teams did not replace them. Nielsen Norman Group’s eyetracking study found participants spent 22% more time and made 25% more fixations on versions of real pages with weaker signifiers. The problem is not flatness; it is spending the whole signifier budget on colour and position.

How many clickability cues does a control need?

At least two independent ones, and not both colour. Colour alone fails for readers with colour vision deficiency, in greyscale, on low-contrast displays and in bright light, and WCAG 1.4.1 prohibits relying on it as the only visual means of conveying information. A border plus a fill, or an underline plus a weight change, survives all of those conditions.

Why does my team keep missing this?

Because you cannot un-know where your own button is. Everyone who built the screen perceives a signifier that exists in their memory rather than in the pixels, which makes the failure invisible in internal review and obvious to the first person who has never seen it. Watching a stranger’s first five seconds is the only reliable test.

Sources

  1. Norman, D. A. (1999). Affordance, conventions, and design. Interactions, 6(3), 38–43. The correction to the field’s use of “affordance”: what a screen designer controls is the perceived cue, and much of what reads as affordance in graphical interfaces is learned convention rather than anything intrinsic.
  2. Moran, K. (2017). Flat UI Elements Attract Less Attention and Cause Uncertainty. Nielsen Norman Group. Eyetracking study, 71 participants across nine web pages prepared in strong- and weak-signifier versions. Weak signifiers cost 22% more time and 25% more fixations, both statistically significant.
  3. W3C. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.1: Use of Color, Level A. Colour must not be the only visual means of conveying information or indicating an action — the enforceable form of the redundant-signifier rule.
  4. W3C. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 4.1.2: Name, Role, Value, Level A. Governs whether a control’s role is exposed to assistive technology. Worth citing precisely because it is orthogonal to visibility: this game’s first level satisfies it completely and is still unusable by sight.

Related patterns