Choosing Between Hidden and Disabled Controls

Designers often face a tough call: should a feature that doesn’t apply to the current user or state be hidden entirely, or shown but grayed out? Both approaches come with risks. Hiding things can make them impossible to discover, while disabling things without context can frustrate users. The key is knowing when each makes sense — and when a completely different solution would serve users better.

Hidden vs. disabled features in UX
To hide or not to hide? There are very good reasons for hiding or disabling features and options for a user. But we need to be careful when doing so to not harm the UX. (Large preview)

A useful rule of thumb: disable when the user should know the feature exists but can’t use it right now; hide when the value shown is irrelevant and can’t be used at all. One exception: never hide buttons or key filters by default. Users expect these to persist, and their sudden absence breaks trust in the interface.

Disabled controls, unlike hidden ones, can actually help users learn the UI. For example, a disabled option in an upgrade prompt can communicate the benefits of a paid plan. Rather than auto-removing unavailable options, consider disabling them and giving the user a way to choose to hide them, such as a “Hide all unavailable options” toggle. Just remember that any show/hide switch must not cause jarring layout shifts.

Before settling on either approach, weigh alternatives: keeping the button enabled, using a read-only state, improving the empty state, using accordions to reveal content, presenting error messages, or offering customization. The goal is to keep what’s needed visible and declutter the rest. Whenever possible, leave controls enabled, accessible, and legible. When a user interacts with a feature they can’t use, explain why, how to enable it, and how to keep it enabled. Notable exceptions are confirmation codes and loading or processing states, where disabled is the expected pattern.

A Decision Roadmap

If you’re unsure whether to hide or disable, ask yourself: “Will a given user ever be able to interact with this element?” Based on the answer:

  • Yes → Disable it. Use disabled buttons or a read-only state for temporary restrictions, filter incompatibilities, values or statuses that are relevant but not editable, and actions that are not available yet (e.g., “Export in progress…”).
  • No → Hide it. Remove the control from a toolbar or collapse it in an accordion. This applies to restrictions due to permissions, access controls, safety, and security — for example, admin buttons and overrides. Hide such controls by default and reveal them only once a condition is met.

When a disabled state is necessary, don’t leave the user guessing. Explain why it’s disabled and how to re-enable it. Also consider allowing users to hide sections that contain lots of disabled functionality, so they can focus on what they can actually do.

Key Takeaways

  • Hiding important features hurts their discoverability.
  • Disabling features without explanation is frustrating.
  • Some options are irrelevant or unavailable to users, and that’s okay.
  • Users might expect a feature to exist but won’t find it if it’s hidden.
  • Show what’s needed and declutter the rest.
  • Avoid disruptive layout shifts when showing and hiding features.
  • Don’t remove unavailable options or buttons automatically.
  • Instead of removing, disable and provide a “Hide all unavailable options” choice.
  • Explain why a feature is disabled and how to re-enable it.

Real-World Examples in Design Systems

Several design systems offer practical patterns for disabled and read-only states:

Further Reading