A disabled state must explain why an action is unavailable
Aliases: disabled reason · unavailable action · prerequisite · disabled control
What it is
An explainable disabled state does more than show that a control cannot be activated: it identifies a missing condition, source of restriction, or route back to availability. A grayed-out button says only “no”; a reason and next step say “why” and “what now.” A submit control may identify a missing required field, export may identify a permission or selection scope, and a temporarily unavailable feature may distinguish processing, network, and plan limits. Explanation turns a dead end into actionable state information.
Why it happens
Disabling interrupts an intention chain. Someone recognizes a desired action but cannot use clicking to obtain a response. Without a reason, they must guess whether a control is broken, permissions are missing, a prerequisite is incomplete, or a temporary outage occurred. Wrong guesses produce repeated clicking, leaving to search, support requests, or abandonment. Exposing prerequisites connects an unavailable action to a remedy and makes product rules more predictable on later encounters.
Studying it
Ask participants to attempt a target action with missing prerequisites, restricted permission, work in progress, and system trouble. Compare disabled-only and reason-plus-recovery versions using diagnosis accuracy, time to eligibility, ineffective clicks, help seeking, and perceived fairness. Do not only ask whether copy is understood; observe whether people can remediate. Test state updates too: a stale explanation is often worse for trust than none.
Where it stops holding
Not every temporary control needs lengthy explanation. Obvious physical limits or prerequisites visible in adjacent fields may use a short cue, and expanding every reason in dense lists can create noise. Safety, permission, and commercial restrictions cannot be hidden behind a vague “unavailable”; if a specific rule cannot be disclosed, offer a legitimate next step or support path. Explanation is not an excuse for an error: actual faults need error reporting and recovery or retry.
Applying it
- Model each cause separately—missing input, invalid selection, permission, processing, offline state, exhausted allowance, unsupported feature—with its own explanation and next action.
- Put the explanation where people inspect or try the control, synchronized with current state rather than buried in help.
- Link user-remediable conditions to correction, navigation, or automatic location; offer waiting, alternatives, or contact for those users cannot change.
- In blocked-task tests, people should state why they cannot proceed, what to do next, and when to stop retrying without asking someone else.