What is it with disable, hidden or obviously active buttons

Sometimes you find yourself thinking which button should I use now. What would give the user the best understanding of what needs to be done and how to make the user feel.

Today, with inline validation, we can show, on the spot if an input is valid or not, if a user attention is needed to correct an error. This solution makes it harder to decide when and what should we used when it comes to Disabled vs. Active button.

I believe we can all agree that it is important to let the user understand why the next step is not accessible, whether the button is disabled or active, we need to weight the pros and cons of each case.

What do these button states mean?

Active button – button should look like a button in a normal state. Windows 8 is a good bad example of such problem — it hard for users to know if things are clickable or not in a Settings menu.

Disabled button  – if an action is not available right now and can be enabled at some point once a user completes a task, it should be disabled till the user finishes that task.

It is commonly used as a visual cue to communicate that an action is required to enable the button.

If a button is disabled and not self-explanatory, make sure to communicate why it is disabled. Another suggestion is to always use inline validation to indicate errors if this is the only way to make the button active.

Hidden button – If there is no action needed to be done or this action will never be available for that user, hide the button because this disabled button will never become active, which will make the user think “what can I do to turn it on”.

Do we need a button?

When is it preferable to hide a button instead of showing it in a disabled state?

Some arguments for using a disabled state

• gives the user the chance to learn that the action is possible but not available right now. You may even have a tooltip explaining the criteria for enabling it.
• Tells the user about what comes next. It really depends on how you label your buttons and this is another topic.

Some arguments for using a hidden button

• It keeps your focus. Show the user what is the main action to be taken and leave the distractions aside.
• It allows you to control which actions to show at what point.

Therefore, it is about context, about what is needed to be done by the user and at what point. We should keep it simple and as designers, we believe that less is sometimes more, but you should never simplify more than necessary.

I find the Occam’s Razor principle a good resource for inspiration and guidance when it comes to making a decision about design elements.

We have a button, now which state – Active or Disabled?

We’ve decided to show the button. Should it be active or disabled?

Arguments for the active state

• Help the user find if and where something is missing. Don’t let the user look for what is missing in order to activate the button
• Avoid mixing validations for button states. What if we need an additional backend validation, in addition to the real-time frontend validation?
• If there might be a disabled state in addition to the active state. Either as a secondary button or while the systems thinks (in the case to avoid rapid clicks)
• Accessibility matters

Arguments for the disabled state

• Tell the user he needs to finish an action before continuing further. All “fields” are mandatory.
• When inline validation is enough alone
• When it is clear what is required from the user

You might argue that real-time validation helps you correct the errors before even clicking on the main button, so why not make it disabled till the user fix them. That anyway there is no way forward. But, what happens if the screen is too long and fields are being missed? If there are optional fields in that form?

On the other end, some might argue that real-time validation distracts the user from the form completion. This means, let the user first complete, then fix. Sorry to break the illusion and we the support of many best practices, the favor is to the inline validation.

Examples of button states:

Hidden buttons

There are few cases I have observed using hidden buttons when a no action from the user is needed but for one input.

Enter code confirmation

One case is familiar with code confirmation, some sites do not show a button as they have a live/inline validation. This means that once the user enters the last digit, the system validates the input immediately and if it is right, redirects to the next page or if it is wrong shows an error message.

Answer as a call to action

When the system requires an action from the user, usually as one selection out of few answers, though, it is not necessary to use an additional button as the user’s answer replaces that call to action and behaves as one.  

In the below example, you can save a click by forwarding the user to the next screen once an answer was chosen.

Disabled buttons

Focus the attention to complete a task. When there is not even the need for real-time validation