Hiding entirely makes people think the function does not exist

What it is

Once an unauthorized item is taken off the navigation, the choice field has no gap, no grey slot, no name. People read “cannot see it” as “this product does not have this capability”. Hiding is understood as absence — the cognitive cost of the hide strategy. A fake door is saved, and so is the sentence “it exists, you just cannot go there yet”. The cost peaks when someone has already heard the capability’s name, or is collaborating with a colleague who has permission.

Why it happens

Navigation is the public catalogue of what the product can do. An item not in the catalogue is, by default, not in the goods. Training, contract language, a colleague’s “look at Export over there”, all point at a name. When the navigation cannot be matched to that name, people do not guess permission first. They guess they have the wrong product, the wrong version, or a colleague who is bluffing. Support tickets become “do you even have Export”, not “how do I turn Export on”. Hiding has translated a permission question into an existence question.

Exploratory users take the misread harder: they learn the product’s boundary by sweeping the navigation. A hidden capability never enters their model; later, even after it is turned on, they do not know where to look — and if the enablement event does not also reveal the item and name it, the model will not grow by itself.

Studying it

Give participants a capability that appeared in materials or in a colleague’s speech but is hidden on the navigation, and ask “does this product have X” and “if so, where”. Independent variable: hidden versus disabled-with-reason. Dependent variables: rate of judging it absent, rate of hunting in settings or support, and whether after enablement they can find the entry without being shown.

The slice of live tickets that ask “do you have function Y” and turn out to be permission is field evidence for this mechanism.

Where it stops holding

For a capability that role must not even know about (unreleased, a security isolation, an admin surface during an exam), people thinking it does not exist is the goal, not the cost. An item that has never been named outside and will never be enabled for that role will not produce this misread when hidden. Disable-with-reason exposes the name; when the name itself is sensitive, this mechanism cannot be used against hiding. If enablement happens off the navigation (a mailed link that lands directly), existence is carried by that link, and the misread from a hidden nav item is smaller.

Applying it

• Capabilities that will be named in training, contracts, or cross-role collaboration should not be fully hidden from people who will be enabled or who are already collaborating; disable-with-reason keeps existence.
• After enablement, do not only show the entry — point at it as “this is what was just turned on”, filling in the model that hiding never grew.
• Support scripts should split “does it exist” from “can your role use it”, so both sides do not idle on existence.
• How to check: take an unauthorized user who has heard of the capability, give only the navigation, no voiceover, and ask whether the product has it. “No” is the misread. Switch to disable-with-reason and the answer should become “yes, but it needs enablement / this role”.

Related

• Within the group: E5.18.1 Unauthorized items may be hidden, or shown disabled with a reason · E5.18.3 After a permission change, navigation must update rather than cache the old structure · E5.18.4 Permission must be checked on the server; hiding nav is not authorization
• Adjacent: E5.04 Hamburger Menus · E5.16 Shortcuts and Pinned Items
• Search terms: feature absence misconception · hidden navigation · permission discoverability