Skip to Content
Personal Insights

Do disabled buttons need to be hidden?

We always hear some opinions from IxD/UX perspective on when it is best to show a button as disabled or remove/hide it completely. And the answer always starts with ‘it depends’. Yes, this is because IxD/UX is inevitably based on context and action.

A disabled button is unusable and un-clickable. A disabled button indicates to users that there is an action they can take to enable it. Whether it is form, complexity management interface, or step-by-step guidance, it is possible to have disabled buttons in these scenarios, and how to properly use disabled buttons to make it a bonus to experience rather than a minus is what designers should constantly think about and practice.

In this blog, I’d like to share some usability considerations I always take into account.

Advantages of showing the button in a disabled state:

  • Many users learn to use an application by exploring and reading labels. It helps teach users what an application is capable of even when the button requires further action to enable.
  • The user can learn where controls and buttons live within the interface. (This assumes on your design that if a lot of buttons are hidden at one time the structure will be unclear.)

Disadvantages of showing the button in a disabled state:

  • Give extra thought for the user about why it is not available and how to enable it. According to Steve Krug’s “Don’t make me think” you should remove elements that make the user think.

 

Advantages of hiding the button:

  • Only showing what is needed for the task at hand. Attention is focused.
  • Save space. It allows you to change the controls, using the same space for different states.

Disadvantages of hiding the button:

  • Constantly hiding and showing buttons may distract because the view changes constantly. (This assumes on your design that if a lot of buttons are hidden at one time the structure will be unclear.)
  • Users will search for this option and will maybe think they don’t see it and therefore may spend time looking for it, possibly refreshing the page, restarting the browser, etc.

 

When it is best to show a button as disabled or hide it?

Below are the questions you should ask yourself before answering this question.

  • What does the user need to know at this point?
  • What does the user need to do at this point?
  • Will the user know about that feature?
  • Will the user spend a lot of time hunting for it?

When should be disabled:

  • If the control is available sometimes but isn’t available right now, it would be better if you provide a hover bubble/tooltip/detail disclosure buttons explaining the criteria for use.
  • If you want the user to know that the control exists, but that it is disabled.
  • If the user could see this feature somewhere that then not be able to find it again if it is now hidden. And there would be no indication why they can’t find it again.

When should be hidden:

  • If the user is not authorized to use the control which means it never available to the user.
  • If it is a control that is only active in very rare situations. Don’t show user a button that can’t be used or enabled to be used.
  • If there is a lot of disabled functionality. (For instance, a whole extra block of form inputs.)

 

Conclusion

The most important thing is to ensure that the core function interaction experience is smooth, and the user will not have understanding confusion, and then according to the specific interface environment for analysis.

  • Displaying the button in its disabled state, let the user know why it’s disabled.
  • Displaying the button in its disabled state, let the user know how to make it becomes enabled.
  • Hiding the button in its disabled state, let user accept smoothly when it appears instead of being “surprised.”
  • Making a clear distinction between disabled and enable button styles. Color contrast is a big thing for web accessibility, crappy contrast can make the web harder to use.
  • Communicating a disabled state button by changing its transparency instead of graying the button out. Because users are less likely to confuse a transparent button with other buttons. Furthermore, gray doesn’t always represent a disabled condition. Sometimes gray is used to communicate a low priority button in a group (e.g., cancel buttons). Users can easily mistake a grayed out disabled button for a secondary call to action.
  • Giving explanations when necessary. If a button change into disabled state is sudden to the user, consider designing a clear and understandable explanatory note.

 

Citations:

  1. iOS Human Interface Guidelines – Buttons

https://developer.apple.com/design/human-interface-guidelines/ios/controls/buttons/

  1. Don’t make me think by Steve Krug

http://www.sensible.com/dmmt.html

  1. Inactive statement of buttons, design explanations by Daidai ULi

http://www.sohu.com/a/341396227_700343

 

1 Comment
You must be Logged on to comment or reply to a post.