Hidden vs Disabled

Nothing is wrong. The feature belongs to the enterprise plan and they will never have it on this account. A grey control told them a story about a fault, and it cost a support ticket to correct.

The opposite mistake is just as common. A team hides an admin control from anybody without the permission, and every new manager asks where the setting went, because they were told in training that it exists.

You make this call dozens of times in any real product: permissions, plan tiers, prerequisites, uploads still running. One question settles most of it, and knowing the other states available settles the rest.

Control States

Open the settings screen of any product you pay for and count the controls you cannot use today. There will be more than you expect, and almost all of them will be the same shade of grey.

That one shade is carrying at least three different meanings. Something is temporarily blocked, something belongs to a plan you do not have, and something is there for reference and was never meant to be edited. Grey says none of that.

So before the decision in the next article, it is worth naming what you are choosing between.

The Five States

Each one says something different.

Enabled means this works right now, and it is the state everything should be in unless there is a reason otherwise.

Disabled means something is stopping this, and it could change. It is the honest state for a temporary block: an upload still running, a form that needs one more field, a filter that clashes with another one.

Read-only means this is information you can look at but not change, and unlike a disabled control it is still bound by WCAG 1.4.3, so its text needs 4.5:1 against the background. SAP Fiori keeps read-only and disabled as separate states for exactly this reason, and most design teams collapse them into one grey blob. A field showing an invoice number that nobody edits is read-only, and calling it disabled invites somebody to hunt for the way to turn it on.

Hidden means this is not part of your product. It is the right state when the person will never reach the feature in this role, because a permanently dead control teaches nothing and takes up space.

Absent, with an explanation is the fifth, and it is the one people forget. Rather than a greyed-out Reports button, the screen carries an empty state saying what will appear here and what to do first. The control arrives when it works.

What Each State Costs

Every state has a price, which is why the choice matters.

Disabled costs attention. Somebody has to look at the control, work out that it is not available, and decide whether that is their problem. Do that six times on one screen and the screen reads as broken.

Hidden costs certainty. Anybody who has heard the feature exists now cannot find it, and support hears about it. That is the trade you accept when you hide something, and it is only worth it when the person will never gain access.

Read-only costs almost nothing, which is why it is underused. It answers the question before it gets asked.

Where Teams Get It Wrong

The common mistake is reaching for disabled by reflex, because it looks careful.

A greyed-out control feels like the safe, tidy answer, so it becomes the default for every situation. That is how a screen ends up with a plan-gated feature, a paused upload and a reference field all wearing the same treatment, and none of them explaining themselves.

The second mistake is the opposite reflex, which is hiding anything unavailable to keep the interface clean. Fewer controls on screen is not the goal. Somebody who cannot find a feature they were trained on is worse off than somebody looking at a grey button with a sentence beside it.

Pro tip: Open your design system and see how many of these five it actually defines. Most define enabled and disabled, sometimes read-only, and nothing else. The states a system does not name are the ones every designer improvises separately, which is where the inconsistency starts.