Unauthorized items may be hidden, or shown disabled with a reason

What it is

When the current user is not allowed to use a navigation item, the interface has two honest moves: hide it, or leave it in place disabled with a reason. Both are more honest than “looks pressable, errors after the tap”. The difference is whether people should know the place exists. The choice happens when the navigation is drawn, not after someone has gone in.

Why it happens

Hiding removes the item from the choice field. The field stays clean, and no one taps a door that will fail. It fits places that should not exist for that role: members do not see an admin console, examinees do not see authoring. Disabling keeps the item on the map, selected state cannot go there, but the name remains, with “needs this role / needs to be turned on”. It fits “it exists, you just cannot go there now”: a module that appears after upgrade, export that must be requested, a queue colleagues have and you do not yet. The map stays complete, so a gap is not read as a broken product, at the cost of unusable area in the choice field.

“Pressable, then fail” takes neither benefit: the field is polluted by a fake door, failure arrives late, and often says only “error”, not permission. Disabled without a reason is also dishonest: people see a grey item and cannot tell whether it is temporary, paid, or broken. The reason must be readable beside the item, not only in a dialog after a tap.

Where it stops holding

Capabilities so sensitive that even the name must not leak (an unreleased internal tool) can only hide; disable would expose the name to people without permission. Conversely, a capability whose name already lives in contracts, training, and colleagues’ speech costs more to hide, and should disable with a reason. Switching the same item between the two strategies across roles makes the map jitter; pick one and keep it when roles change. On a narrow mobile width a disabled item still occupies a slot and may crowd out items the user can use; hiding then fits better.

Applying it

• Pick a strategy per unauthorized item in advance: hide if it should not exist for that role; disable with a reason (what is missing, who can turn it on) if it exists but is currently unusable.
• Do not make it pressable and then error. Put the reason beside the item, not only on hover.
• Use the same strategy for like items in one product; do not grey some and vanish others.
• How to check: view the navigation as an unauthorized account. What should hide must be absent; what should remain must be present, not activatable, and the reason readable without a tap. Any “tapped, then told no permission” is a third, dishonest move. Then check that the reason is specific to a role or an enablement action, not a bare “cannot access”.

Related

• Within the group: E5.18.2 Hiding entirely makes people think the function does not exist · 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.16 Shortcuts and Pinned Items · E5.13 Context Menus
• Search terms: disabled navigation · unauthorized item · permission disclosure