How to Build Better Disabled Buttons

There is an ever-growing conversation within our design team regarding how useful disabled buttons are. Disabled buttons have been a normal and established design pattern with many web applications, however it seems that they are a divisive practice with its benefits being outweighed by its faults.

A “disabled” button is where a button is intentionally disabled, or cannot be clicked, because a certain action hasn’t been completed. The button’s design is typically greyed out or uses opacity from its enabled state. The user must complete a certain action in order to enable the button.

An example of a greyed disabled button (left), disabled button using opacity (middle) and enabled button states.

What action should be completed? The answer to that question is the core problem with disabled buttons — it’s not always clear what’s needed to move forward and the user is left wondering or frustrated.

The Problem with Disabled Buttons

Disabled buttons are great at pushing users to provide data in a precise format for your application or design. They keep users aligned with how you want receive information and can help steer users actions in specific ways. If certain inputs are required before moving to the next step, providing a disabled button is a way to hold up users until they provide the input required.

The paradox with disabled buttons, however, that its biggest strength is also its biggest weakness. Stopping users from completing certain actions isn’t great for their overall experience and users get frustrated if it’s unclear how to move forward. If there is little feedback about why an action is disabled or why the user can’t move forward, it’s understandable to why this causes friction for the user. Disabled buttons rarely provide users with the opportunity to correct an error or prevent them altogether.

Here is an example of a greyed and opacity adjusted disabled buttons and their color contrast. Even at larger sizes, the button fails to have enough contrast to pass ADA requirements.

Another issue with these type of buttons are that they often lack the contrast needed for accessibility when in a disabled state. They require users to be able to recognize color change alone, which is difficult for some that may have a visual disability or impairment. Without proper contrast, we make the disabled button even more vague for users and obscure what action is required.

How to Build a Better Button

There are many ways to address the problems with disabled buttons, so I’d like to explore some of those solutions as well as provide a unique idea of my own. Let’s state what the issue is with disabled buttons individually, then look at some solutions for them.

Provide Helpful Tooltips

Example of helpful tooltips to provide context as to why a button is disabled along with resources for the user to learn more information if still unclear.

If we isolate instances where the button doesn’t provide context for actions that is needed before they can be active, a straightforward solution would be to provide clear messaging and tooltips to inform the user. These can be a great solution and helpful for users who are new to your product or within the onboarding process.

Here is an example of a very poorly designed tooltip. It provides no context as to why the button has been disabled and doesn’t provide any way for the user to learn more.

It’s important that the tooltip messaging helps users to correct their error, or provide directions on what to do next instead of stating that the button is disabled.

Show In-Line Validation

Another excellent option is to provide in-line validation. This can be helpful when requiring users to complete textfield or dropdown inputs before moving forward. By providing real time validation, users can address formatting issues and correct errors before moving forward. Helping users with in-line messaging helps to provide context for disabled buttons.

Use “Magic” Buttons

The last option I’d like to explore is what I’m calling the magic button. This style button is an enabled button that only appears in the context of a user’s action, rather than showing a disabled button with detailed messaging.

An example of this magic button would be for something like a bulk action. Our magic button would appear as an option when bulk selecting items, but remain off of the UI when items have not been selected. This is because a disabled button doesn’t indicate anything about it being a option only when bulk selecting items.

The benefits of the magic button is that users aren’t reliant on tooltips or in-line messaging for complex actions. They are presented with additional options once an action is taken in a workflow. This can also help clean up your UI and declutter disabled buttons on the screen.

The magic button isn’t a catch-all solution, however, since it would rely on the users learned behavior. Because of this, I don’t recommend the use of the magic button solution in all instances as tooltips or in-line validation may be more helpful.

Let’s Chat!

What are your thoughts on disabled buttons and the solutions presented in this article? Do you use disabled buttons in your design? Let’s talk in the comments below!