Hide or Disable

Should we hide or disable a specific element? This is a topic that comes up frequently. Typically, it is resolved in a meeting where engineers, designers and product people present their arguments for treating it one way or another. An agreement is then reached, and a solution is implemented.

The following week, another team faces a similar scenario. They go through the same process, engaging in a spirited debate and reaching an agreement. Sounds familiar, right?

Except this team comes to the exact opposite conclusion. If the visibility discussion is treated ad hoc, it will lead to confusion as similar scenarios will be handled differently in each instance.

To assist in making these decisions, I ask one simple question: will a given user ever be able to interact with this element?

If the answer is yes, disable it. If the answer is no, hide it.

Disable elements when the restriction is temporary or specific to a situation. For example, if a user is marked as “Do Not Contact,” disable the call button instead of hiding it. They are still able to make calls, but it should not be possible for this particular record. As an aside—these elements should be styled as disabled, but still readable by screen readers for accessibility.

Hide an element if a user will never be able to use it. This often applies when dealing with permissions or access controls. Hiding these elements removes noise from the interface and prevents users from being misled into thinking they can use features that are not available to them.

Using this rule as a starting point for discussions can help promote consistency whenever the hide or disable discussion arises.

4 responses

  1. Michael Wilson Avatar
    Michael Wilson

    Hi Sam,

    How would you deal with scenarios when it isn’t clear why a feature is disabled?

    Using your example, what if the person trying to call the user isn’t aware that the user has enabled the ‘Do not contact’ setting?

    Disabling features often makes it very difficult for people to understand why they are disabled, because they don’t allow for feedback

    1. Well, there should be an effort to make it clear. A lot of that will depend on the user’s current context.

      Do Not Contact in Salesloft appears as a status icon next to the person’s name. So we have an indicator that visually represents—you cannot contact this person.

      If the context isn’t obvious enough, alerts or tooltips explaining the current situation may be the best path forward.

  2. lilacshenn Avatar
    lilacshenn

    Thanks for sharing! Could you please give a more specific example of hiding regarding “when dealing with permissions or access controls”?
    Thank you very much!

    1. For sure! Imagine you have a permission called “Edit Template” whatever that might be. You might imagine—on a Templates page—that there is an edit button.

      For users who don’t have the “Edit Template” permission you can either hide the edit button or disable it. The better experience would be to hide it, because that user will never be able to edit templates.

      Does that help?

Comment

Discover more from Sam Solomon

Subscribe now to keep reading and get access to the full archive.

Continue reading