Hiding to prevent action also damages discoverability of the function

What it is

Completely hiding a function that is temporarily unavailable or conditional does prevent action in the current state, but also leaves people unaware that the capability exists, when it appears, why it vanished, or how to satisfy its condition. This hidden constraint turns an anti-affordance into an invisible gap. It may reduce immediate misactivation while damaging longer-term discovery, learning, and understanding of system boundaries.

Why it happens

A visible but limited function communicates “this capability exists, but a condition is currently unmet.” When hidden, people can infer only from absence and often do not know what to search for or which prerequisite to meet. They may read state change as feature removal, revoked permission, or lack of support. Hiding also makes entries in help, training, and screenshots diverge from the live interface, increasing transfer and support cost. The benefit of blocking action must be weighed with this information loss.

Studying it

Compare hiding, visible disabling, a visible condition explanation, and a visible alternative path for understanding of function existence, availability conditions, completion path, and later rediscovery. Test first use, permission changes, object states, and task recovery, because hidden rules often surface only on state transition. Record whether people know what to ask, where they look, and whether they attribute absence to unsupported capability.

Where it stops holding

Hiding has valid cases: a function may be wholly irrelevant to the current object, exposure may create security risk, or an empty entry may mislead. The issue is not never hide, but distinguish irrelevant from temporarily unavailable, permanently unsupported from conditionally activatable. Frequent or critical capability that should be found when needed cannot disappear merely to keep an interface simple.

Applying it

• For temporarily unavailable, conditionally activatable, or reasonably expected capability, prefer visible limited state, a short reason, and an activation path.
• Hide only when a function is genuinely irrelevant or display is risky, while ensuring help, search, and related pages still explain the capability boundary.
• Test rediscovery and recovery after state change; if disappearance makes people believe the function does not exist, use an explainable limit or related cue instead.

Related

• Same group: B2.17.1 Anti-affordance actively prevents an action, unlike simply not offering it · 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
• Nearby: B2.08 Visibility · B2.09 Discoverability
• Search terms: hidden constraint · discoverability · conditional availability