The choice to hide or disable depends on recoverability
Aliases: hide versus disable · recoverability · conditional action · unavailable action
What it is
Recoverability of unavailable actions determines whether a temporarily unusable capability should remain visible and disabled or be hidden in the current context. When someone can complete input, gain permission, wait for work, change a selection, or change situation to restore it, a disabled item can expose a goal and recovery route. When the condition cannot be changed by this person, the function does not belong in the situation, or exposure only adds burden, hiding is usually better. The question is not merely whether less UI looks cleaner, but whether a feasible next action exists.
Why it happens
A disabled item conveys that a capability exists and that a condition blocks it. In recoverable cases, this visibility supports a capability map, makes prerequisites legible, and prompts remediation; hiding can falsely imply lack of support. In unrecoverable cases, it repeatedly advertises an intention that cannot be acted on, increasing search and frustration. Recoverability determines informational value: a restriction that can become action is useful feedback, while one that cannot is often noise.
Studying it
For the same task, compare hidden, unexplained disabled, and disabled-with-recovery versions. Observe capability discovery, correct judgments about recoverability, time to alternatives, and frustration. Include permission, subscription, device capability, workflow prerequisite, temporary processing, and permanent lack of support, since people infer “can I change this?” differently. Do not compare click rate alone: hiding reduces futile clicks but can conceal a task users could have completed.
Where it stops holding
Recoverability is not the sole factor. Safety and privacy may require hiding sensitive capability even where an administrator could grant it, and policy may limit explanation. Expert tools may retain an unrecoverable item as a capability signpost, though a novice interface should not become a field of dead ends. Conditions also change: an unrecoverable restriction may become recoverable after account, device, or approval changes, so the decision cannot be frozen indefinitely.
Applying it
- For each conditional action, model whether users can restore it, who can, expected timing, and whether capability exposure is appropriate; decide hide or disable from that model.
- Explain and link a remedy for recoverable disabled items; use hiding, an alternative, or controlled capability information for unrecoverable ones.
- Recompute state after account switches, permission updates, device connection, and workflow completion so hiding or disabling does not become stale.
- Test “what can I do to make this available?” If people blame themselves for an unrecoverable limit or miss a recoverable capability, revise the decision.