B2.17.2Unexpressed anti-affordancedesignresearch

Unexpressed anti-affordance makes users repeatedly try impossible actions

Aliases: unexpressed constraint · repeated ineffective attempt · nonresponse attribution

What it is

When a system does not allow an action but fails to communicate the limit through state, boundary, explanation, or feedback, its anti-affordance is unexpressed. People continue to believe action is possible from visible form, naming, or prior experience, repeatedly clicking, dragging, submitting, or changing input method. The problem is not one failure; the system has not helped people include “impossible” in their action model.

Why it happens

People have several reasonable attributions for nonresponse: slow network, missed click, inaccurate input, a busy system, or an action that is not permitted. Without discriminating signals, repetition is rational; people may switch device, refresh, or seek help. Each silent failure adds time and frustration and can trigger duplicate requests or circumvention. Expressing the limit turns an ambiguous failure into an understandable state and next step.

Studying it

Under real limiting conditions, observe initial response, repetition count, attribution, alternative attempts, and abandonment. Ask people what they think happened, what they would try next, and what information would make them stop. Compare silent refusal, weak state, explicit reason, condition hint, and alternative path, measuring ineffective repetition, recovery time, and system-state understanding.

Where it stops holding

Not every nonresponse needs a full explanation: a brief load or easily retried light action can use concise acknowledgment or a processing state. Conversely, frequent error text creates feedback fatigue. The key is providing information sufficient to change next behavior when people reasonably will continue trying, consequence is high, or a limit persists. If a system ought to support an action, fixing capability matters more than explaining refusal.

Applying it

  • Provide perceptible state and local reason for key limits, distinguishing processing, temporary unavailability, unmet condition, and permanent lack of support.
  • At failure, point to a condition to meet, availability time, or alternative path rather than leaving people to retry the same action.
  • Monitor repeated clicks, duplicate submission, refresh, and support requests as signals of unexpressed limits or performance problems.

Related

  • Same group: B2.17.1 Anti-affordance actively prevents an action, unlike simply not offering it · B2.17.3 A disabled state must explain why it is unavailable and how to make it available · B2.17.4 Hiding to prevent action also damages discoverability of the function
  • Nearby: B2.06.2 Feedback must be timely; delay is attributed to nonresponse · B2.05 Constraints
  • Search terms: unexpressed constraint · repeated attempts · nonresponse attribution

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/B2.17.2