Disabled states

Overview

Avoid disabled states when possible

Don’t use disabled state for actions that aren’t currently available but will be available if the user does something on the page, ex: completes all form fields and resolves all errors.

Instead, use errors to surface the missing or wrong fields.

The surrounding interface and the hint/tooltip should clearly explain why a component is disabled and what the user needs to do for it to become active.

How to avoid disabled states

Guide the user on the correct path using plain text, inline alerts, hints and tooltips. If you are not sure if you can avoid disabling a component, reach out to the design team to brainstorm alternatives.

Buttons

Example #1

Context: Only 30 days can be chosen at a time

Do: Keep the button enabled and explain what the user can do (added note below “custom”). Reinforce this with disabling the dates that can’t be selected once a first date is chosen.

Don’t: Disable the button and surface an error if over 30 days are chosen.

Do

Do avoid disabled “apply” button by adding a note to “custom.” You can also avoid the inline alert by using this same note. It is ok to disable the dates that are not clickable.

Don’t

Don’t disable the “Apply” button and add an error message.

Example #2

Context: Form to fill out with mandatory fields

Do: Clearly show that a field is mandatory and keep the button enabled. If necessary, surface an error after clicking for the necessary field.

Don’t: Disable the button, not allowing the user to continue without proper context

Do:

Do use error states to show why tapping on a button didn’t move someone forward in a form

Don’t:

Don’t use disabled text input and tooltips to show why a user can’t move forwrard in a form

Text inputs

Context: Linked text field and button to indicate an email was sent, not allowing to send it a second time to avoid spamming.

Do: make the button reflect an in progress state and a success pill. Keep the text field editable.

Don’t: disable the text field after the email has been sent, using the button as a way of showing the action was already done.

Do

Do avoid disabled text fields by updating the related button instead. You can use "in progress" button states to indicate a transition, and a pill to indicate success state, for example.

Don’t

Don’t use disabled text input when there are other options

Checkboxes

In the example below, Text messages are no longer available as a setting in the native phone app. Rather than disabling the checkbox, try using plain text.

Example 1

Do

Do use plain text instead of disabled components when possible.

Don’t

Don’t use disabled checkbox when it can be avoided by simply not showing it.

Example 2

In the example below, settings that are available in a paid plan are disabled. Instead, try grouping paid-for settings in a section called “Advanced Settings” and adding a link to upgrade.

Do

Do use plain text paired with a hyperlink to indicate an upgrade opportunity.

Don’t

Don’t use disabled components to indicate an upgrade opportunity.