Buttons

Why You Shouldn’t Gray Out Disabled Buttons

How should disabled buttons appear in a given context? Removing the button from its native location and revealing it later can surprise users. Instead of doing this, designers will indicate that it’s disabled to avoid displaying a drastic change to the interface.

The way most designers communicate a disabled state is by graying the button out. However, this approach also catches users off-guard because the button’s enabled state has little resemblance to the disabled one.

disabled-button-transparency

A button that turns from gray to fully colored is an unexpected change that makes users wonder what just happened. For a smooth and seamless experience, it’s best to avoid this. Instead of graying out your disabled buttons, you should decrease the opacity to make it transparent.

When the disabled button is transparent, users can see some semblance of the button in its enabled state. Although the button is faded out, some color still bleeds through for users to recognize. As the disabled button transitions to its enabled state, the new appearance won’t catch users off-guard.

A transparent button blends into the background more, while a gray one remains in the foreground (unless the background is gray). Foreground elements are more noticeable to users. They tend to view them as interactive, which means they’re more likely to interact with a grayed out disabled button.

disabled-button-example

Users are less likely to confuse a transparent button with other buttons. 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. Or, worst-case scenario, they can mistake it for a poorly designed button with low color contrast.

When designing disabled buttons, adjust the opacity, not the color. The optimal opacity values will vary based on your background color. A rule of thumb is to aim for an opacity level of 40% or below. Or, until the text label is unreadable. It’s important to make the opacity level low enough, or users may still view the button as enabled.

By following this technique, you’ll make your disabled buttons look disabled without confusing users. Instead, they’ll experience a smooth and seamless transition between button states.


Books

design_vetting-below_article

Toolkits

wireframes-kit
site-flows-kit
user-personas-kit

Article written by anthony

Author and founder of UX Movement. Creating a better digital world for mankind by teaching and evangelizing best practices, standards, and techniques in user experience design.

This Post Has 42 Comments

  1. Gitte Reply

    You have som good points. But if users haven’t seen the enabled btn before they see the disabled btn, they may not know that’s it disabled? Maybe they’ll just think that this is the color for enabled btn?

    Users often see grey btn as a universal diabled btn (in my experince).

  2. Danny Hope Reply

    Screen readers will often skip disabled elements, so I wonder if there’s something to be said for either replacing or augmenting the disabled element with text that explains why the current state prohibits the function.

    What do you think?

  3. Anon Reply

    But your example images demonstrate a clear issue with transparency. If the button’s active color is not clearly being used for other interactive elements then it’s not obvious it’s actually transparent. In the context of your sample image it just looks as if you chosen a muddy yellow-ish color. This makes it just as bad as the greying it out.

  4. Šime Vidas Reply

    I’m not sure that this is good advice. For some people with low vision, the button may already appear blurry and with low contrast even in its enabled state. How are these people supposed to know that the button is less visible because the website made it semi-transparent to indicate that it’s disabled?

    • Sebastian Reply

      I agree.

    • anthony Reply

      By lowering the opacity enough so that it looks disabled rather than low contrast. An opacity of 40% or less is ideal based on my experience.

      You could say the same thing about gray buttons that look like secondary actions.

    • John Leschinski Reply

      It’s absolutely terrible advice.

  5. Alexander Wright Reply

    Please, if you’re going to post claims, please also provide supporting research or tests to back it up. I’m sure it exists and you have it from personal projects and experience, but without, it just comes across as your subjective opinion.

    • anthony Reply

      If you’re going to cast doubt on my claims, please refute the rationale in the article to legitimize your doubt. Without it, it just comes across as your refusal to understand and examine the claim.

      • Wouter Reply

        It doesn’t work that way. You are the one boldly proposing a rather different approach that you claim is much better than the one which is a well established industry standard.

        If I claim the world is round while everyone else says it’s flat, it’s not up to everyone else to provide proof I’m wrong. And if they fail to do so, I am not automatically right either.

        There is merit to what you say, but there are also some questions. Make a case with support based on measurements or at least some observations as a starting point.

        • anthony Reply

          Where is there merit and what are the questions? Make a case by examining and addressing the rationale that supports the claim.

          • Craig

            The above are quite legitimate comments. There’s no need to act defensively when provided with what I thought as a reasonable challenge and critique.

          • anthony

            There’s no need to accuse anyone of acting defensively when what’s provided in return is a reasonable challenge and critique as well.

          • Hing

            Hi, interesting article. Just like the posters of the replies, as fellow UX practitioner, we’re very interested in the research and the data (what type of scenarios is tested, type users, numbers etc. etc.) It would really help to illustrate your point, provide us more insight into this issue and makes duscussions more interesting.

      • Haydyn Phillips Reply

        Hi Anthony, I appreciate it takes a lot of effort to write an article but you’ve made some pretty bold statements here that I think it would be useful for you to expound on to the HCI community

        Specifically here are my questions around some of the statements made in this article:

        – “Users are less likely to confuse a transparent button with other buttons” – I’m presuming you have data to prove or disprove this hypothesis? And that you ran a proper experimental research process and can publish this? Or at least provide some solid user research data, qual/quant, whatever.

        – “But a rule of thumb is to aim for an opacity level of 40% or below.” By saying “a rule of thumb”, you are again implying that research has been done, either yours or a reference to quality studies already done. Could you please point me in the direction of some data around this?

        As we all know, working in practice with interaction design and trying to include cog-psych principles (which appear here to be around perception and action) is really hard and there are years of published research around the micro-usability of states with buttons, etc (NN Group et al.) It’s useful to challenge and be challenged around new ideas and I personally welcome this but I would be grateful as a fellow practitioner if you could provide some real-world data other than your own opinions so that I have a basis to consider, adapt and share this information. Credibility here is really important 🙂

        I’d appreciate a response other than “Make a case by examining and addressing the rationale that supports the claim” to me personally that’s not enough to end a discussion, especially with all the exceptionally intelligent people that read your advice.

        Thanks once again.

        • anthony Reply

          My claim comes from years of experience working with users and clients. If you need research to verify a claim you have doubts about, you should go do research on it and get experience working with users to understand how they behave. Since you’re a HCI practitioner who wants research so badly, I’m sure conducting one on your own wouldn’t be hard to do.

        • Dean Reply

          A perfectly reasonable request, I thought.

          The articles on this website occasionally raise some interesting ideas, but it always bothers me that so much of the content seems to be based entirely on unsupported opinion. In an industry which depends so heavily upon supporting evidence, uxmovement.com’s prescriptive approach seems bizarre. It would be immensely more useful if the author included sufficient rationale behind his assertions.

          However, the site seems intended more as a casual resource for those with a passing interest in UX—and I guess that’s the author’s prerogative.

  6. Chuck Reply

    Disabled states using gray have been in use for decades. Who do you suppose is being surprised by that?

  7. Dana Reply

    As an alternative to disabled buttons, we have chosen to leave them enabled at all times and if the user chooses to click the button before everything has been satisfied to perform the action, we use the opportunity to provide guidance to users when they click the button that something must be done before the action can go through. This eliminates ambiguity caused by disable buttons which give the idea of “click me, but actually don’t”.

    • Dane Troup Reply

      We have also chosen this path. A grayed out button is easier for development but the cognitive load is substantial. I get it has been common practice but our team has decided to move away from it. JMHO

  8. David Reply

    It looks to me like the goal here was to make it clear that the button won’t work when you click on it (as well as making the transition to enabled from disabled more logical).

    In certain colour schemes (oddly enough, like this one), decreasing opacity just ends up making the button look unreadable, muddy and ugly. On the other hand, a grey colour can be part of a colour scheme, depending on the app (for years, grey was the colour of nearly all things in desktop UIs).

    Rather than go tactical, telling designers to decrease opacity for disabled items, I’d instead suggest that designers look at both states of buttons (and other items) and ask the following questions:

    1) Do items you can’t click on look truly unclickable? If you test your app, do users stumble over the UI item or even give it a second look? If so, look at some other variation of a less-saturated/darker/less opaque treatment.

    2) Are there any other cases where your disabled colour is actually something else in your UI? If so, avoid this and choose another disabled colour.

    3) Do the enable and disabled versions of an item look similar enough that one can see one relating to the other? Try flipping the layer/treatment on and off. Does it make sense, or is it an arbitrary swap.

    Thoughtful designers understand the semiotics (meaning) of disabled is different than simply choosing a grey colour or a lower level of opacity.

  9. Cody Reply

    While I understand these points and mostly agree, user testing showed that on our app specifically user were confused by the lower opacity button. We use colors to drive forward progress through the software so when the buttons were the same color only lower opacity users still thought they were active. Many of our users seldom if ever use technology much less software, I would assume this plays a major role in the way these colors are perceived which is why I can only mostly agree with these points.

    • anthony Reply

      What was the opacity value of the button? What color was it and the background? If you don’t have a low enough opacity, users are going to mistake it for enabled.

  10. Aen Reply

    Where are the tests to validate any of the assumptions?

  11. Dean Reply

    This method has many issues that have already been pointed out. Disabled buttons do not need to meet contrast requirements, but that doesn’t mean that we shouldn’t aim to ensure they do. A pattern that I push for is to keep the state enabled, and upon actioning shift the focus to the first field that has been missed (and is required), showing the error. I’ve seen this perform much better than the aforementioned suggestion and works well for screen reader users.

  12. Raj Reply

    I understand your point here.. But I would even disagree with your approach here.. Have an opacity with with the element being active color will some way around think as if it’s an active button rather an disabled one. We have been used by that pattern of disabled button over a period of time if you’re proposing a different approach you need to have an solid research or case study to substantiate it.

    I would rather say why do we even need to disable the button allow the user to click on it and validate with the data provide necessary information. We have tried this approach and it worked..

  13. Živilė Reply

    How did you find that greyed out buttons are “surprising users”? It is actually industry standard and if you claim the other way around then better have some solid proof, which I haven’t found in the article. Also, sweating to reinvent the disabled button? Aren’t there bigger problems in usability than improving the experience of unavailable features?

  14. Nick Reply

    The second image in this story inadvertently helps disprove this idea. In the example on the right, both the “Sign In” and “Continue with Facebook” buttons are low contrast. If this were the first screen the user sees, they aren’t aware of the differing reasons behind why they are low contrast (Sign In because it’s disabled, Facebook because of brand colors), they just see what they see. A gray button would at least be using information they have acquired from other experiences.

    No app/website exists in a vacuum. Using widely held conventions has merit.

  15. Juraj Reply

    Rather than disabling a button, provide a clear error/validation messages, why the form cannot be submitted. Don’t force the user figure what’s wrong, but just tell them what to do in order to continue.

  16. Scott T Reply

    I would like to see the research and numbers around how the classic, greyed-out button style is confusing.

  17. Liz Reply

    From my experience, both confuses users. We’ve tested a disabled button on our submit pages, and consistently users:
    a) Tried to click a disabled/opacity button.
    b) Were not sure how to make the button enabled.

    We resolved this by keeping the button fully enabled, and if they were missing form fields just pop a little old error up there.

    It communicates to the user how to fix something, doesn’t confuse folks, and gets rid of the whole argument.

  18. Didi Reply

    “A transparent button blends into the background more, while a gray one remains in the foreground (unless the background is gray)”

    It’s all depends on the theme, I think. There’s no exact rules whether to use transparent or gray. Also, there’s a lot of factors to think about – the theme, the mood, the concept, the audience, the device, etc. If you have designed plenty enough of projects, I don’t think you can easily say “Why You Shouldn’t Gray Out Disabled Buttons”

    “Users are less likely to confuse a transparent button with other buttons.”

    How did you know that? What kind of interface you tested them with?

  19. UX Designer Reply

    This is the exact article I needed to dunk on my co-workers. Thanks Anthony.

  20. Shoots Reply

    “Greyed out” is often mistakenly used as the term for “Disabled” and can therefore lead to mis-interoperation by designers or developers as to how the button is physically rendered.

  21. Joachim Reply

    Why do you claim that lowering the opacity works better than lowering the saturation, which is the “graying out” effect?

  22. Steve Shaffer Reply

    I think we may be getting into a philosophical thing here… Is a designing an art or a craft? Do we need to test our assumptions? “I’ve done it a hundred times before!” Has tumbled out of my mouth a lot in the last 25 years in design. I would argue that since we can state hypothetical design solutions all day without understanding their actual impact. We would need actual data to understand how far ahead or behind we may be with a design.

    I understand where your head is at when something feels just right. It’s hard when the wisdom of the herd may give you a hard pass on a concept. Experience has taught me the most trite sounding truisms can be more right than I wanted to hear.

  23. UX Unicorn Reply

    Best practice for buttons in general is to enable and display an error message if a user tries to continue without completing a form correctly or leaving required fields blank. I always discourage the use of disabled states for any web component, especially buttons. This post also does not cover web accessibility in which the exception here is that screen-readers do not announce anything with a disabled state so it’s not a WCAG violation to meet color contrast ratio for components that are disabled. It really doesn’t matter what visual style you apply to a disabled button, it will confuse users who are, or who are not visually impaired. I personally think it makes more sense to discuss the visual differences designers and developers should focus on when a component is either enabled or read-only, but I’ll leave it at that for now.

    When in doubt, don’t disable.

  24. Carlos Reyes Reply

    I don’t think users tend to view gray buttons as interactive, rather grey is a well-known convention that means disabled.

  25. Laura Harley Reply

    I don’t see much visual difference between graying out a disabled button versus setting the transparency. As others have said, the gray for the button is a long established UI convention (more than 20 years now) for indicating disabled buttons. It’s the convention that sets the meaning for “disabled,” not the fact that the button blends into the background. I think this is an example of someone proposing a “new rule” based on his own preferences. As others commented, where is the user research data to support the claim? UX designers need to demand the evidence before they condemn a convention to death.

  26. Eetu Komsi Reply

    I agree with the other commentators that this transparency solution will not produce the desired effect to the button. But I agree the orginal idea that there should be resemblance between active and disabled buttons.

    How about if you do not lower the opacity but the color saturation? Maybe not to fully gray (0%), but to yellowish grey.
    e.g.: hsl(59, 100%, 50%) –> hsl(59, 30%, 85%)

  27. Chris Reply

    It’s translucent, not transparent. Users wouldn’t see a transparent button at all.

    Also, this is bad. You can’t tell that a translucent button is in a disabled state at all. And in certain colour palettes, making it translucent enough to be different from the enabled state would make it difficult to even find.

    Don’t do this. The Expedia example even shows why it’s a bad idea: it doesn’t look like it’s disabled at all.

  28. ELIA Reply

    I dare to say that we should avoid disabled elements at all cost, from an usability and, above all, accessibility point view.

    Chris got the point here: https://uxdesign.cc/why-you-shouldnt-include-disabled-interaction-elements-in-your-design-system-76a2d4307faf

Leave a Reply

Your email address will not be published. Required fields are marked *