Anti-affordance actively prevents an action, unlike simply not offering it

What it is

An anti-affordance is a property by which an interface or object actively expresses and enforces that an action cannot be taken this way now—for example a boundary that cannot be dragged past, a disabled but explainable submit button, format restriction, or permission limit. It differs from simply not offering an action. If a function never exists, people may have no expectation; an anti-affordance usually confronts an imaginable, visible, or known action and prevents it under current conditions.

Why it happens

Systems use state, rules, and boundaries to limit ineffective, dangerous, or mistimed action. When a limit is perceptible and explained, people update their understanding of the action space and meet a condition or take an alternative path. When a backend only refuses without expression, people attribute failure to nonresponse, defect, or an accidental mistake and may repeat the attempt. Anti-affordance thus includes both preventing and communicating why prevention occurs.

Studying it

List actions people might reasonably try that the system should not allow. Test whether they understand the limit before action or after the first failure, know when it becomes available, and can find an alternative. Record repeated ineffective attempts, error attribution, help seeking, circumvention, and abandonment. Compare hiding, disabling, constrained input, local explanation, and post-error explanation to identify forms that prevent error while retaining understanding.

Where it stops holding

A limit should not excuse missing capability, technical debt, or opaque rules. If a goal is legitimate, blocking without a recovery path creates frustration; a lower-risk version, draft, or condition guidance may fit better. Anti-affordance must also not expand so far that it obstructs experts, assistive technology, or legitimate exceptions, and should be differentiated by risk and context.

Applying it

• Define the concrete risk, condition, and alternative path for an action that must be blocked, enforcing the limit at the point of action rather than reporting an error only afterward.
• Use state, labels, feedforward, or local explanation to communicate unavailability reason and conditions for availability instead of silent rejection.
• Test limitations across permissions, devices, and exceptional states to ensure they prevent real error without unexpectedly blocking legitimate use.

Related

• Same group: B2.17.2 Unexpressed anti-affordance makes users repeatedly try impossible actions · 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.05 Constraints · B2.03.3 A wrong signifier is more harmful than none
• Search terms: anti-affordance · negative affordance · action constraint