It is an anti-pattern to visually disable affordances, functionally disable affordances, or hide affordances. PLEASE don’t do it. I will make a case for all three.
Disabling or hiding affordances is one of my biggest pet peeves, especially since it is a case of over-engineering the solution:
- It’s always extra engineering and design effort to hide or disable anything intermittently.
- The client-side data validation is only one of the myriad ways that saving the data (or other end result) could fail, so even if client-side validation passes, and you now “show” and “enable” your button, there could still be an error when the user clicks Continue, and you still need to handle this error in a nice way. For example, server-side validation could fail, there could be a networking or other server failure, there could be an on-device filesystem error, etc.
- Sometimes the client-side validation is incorrect (outdated or buggy) or simply fails to “show” or “enable” the button at the right time. This would completely block a subset of users, and it’s difficult to detect this kind of error — typically you’re waiting for a user to contact support and for that information to flow all the way back to the people who can fix it.
In summary, your extra design & engineering effort is creating more risk than value. Even if you think you can 100% mitigate the risks, it’s still an anti-pattern, as explained below.
From most-offensive to least-offensive:
Why shouldn’t you hide affordances?
First of all, why should you hide something? You should hide things for privacy or security purposes. Now why is the affordance there? It serves two purposes: communication about the utility of the application, and a mechanism for the user to communicate their intentions and beliefs to the application. So you shouldn’t hide affordances unless you are trying to make the utility of your application private or secure. Let’s assume at this point that you’re not trying keep private or secure the fact that your application has the capability of Continuing, and so you have made the button permanently visible. At this point let’s note the advantages of an affordance being visible:
- The user can discover it — they can learn about the capabilities of the application.
- Knowing the capabilities of the application provides motivation to use it and complete tasks on the way to accomplishing those capabilities. E.g. they are more motivated to fill out the form because they know that at the end they can “continue”.
- Experienced users know where to find it, and — this is a bit funny — but knowing that you’ve found it, even if for some reason you are not allowed to use it right now, is really important and satisfying to the user experience. If you can’t find it, you wonder if it’s moved, or if your memory is failing you, and you usually end up looking around for a while, and eventually losing trust in the application. Did they delete the feature? Is it broken? Are they going to move it around every few months?
Why shouldn’t you functionally disable affordances?
We touched on this in the previous section. This comes down to the second purpose of an affordance: as a mechanism for the user to communicate their intentions and beliefs to the application. This is a major point of confusion. Most designers and developer take the affordance at face value: a button that says “continue” will continue when you click it, or a button that says “delete” will delete when you click it. This is the ultimate goal, but the button is so much more than that. By clicking a button, the user is communicating one or more of the following:
- they intend to perform an action
- Capturing the user’s intention is a downright miracle. You should absolutely use this information to your advantage — you have a ready and willing user on your hands. Guide them through the funnel.
- they believe the action will occur when they click it
- The user just conveyed something to you that they have no other way of conveying other than by clicking the button: they believe they’ve satisfied the criteria for performing this action. If they haven’t, this is the perfect opportunity to guide them, and the best time to communicate with them, because they are actively interacting with the application.
- they believe they’re supposed to click it
- Maybe they’re a new user with a different past experience, or maybe they’re new to the internet (no joke), or maybe they’re a little fuzzy today (or every day). But for some reason they clicked this button thinking it would do the thing. It won’t... but again, this is the perfect opportunity to coach them to success — obviously they already scrolled through all the other communication in the UI to click this button. The button got their attention, so steer their attention to the thing they should actually be doing (whatever they need to fix).
Finally, Why shouldn’t you visually disable the affordance?
Simply because a disabled affordance is not an affordance. Since you went to the trouble to match the visual style of buttons that don’t do anything, you successfully communicated to the user that it doesn’t do anything. Therefore it won’t catch their attention, they won’t believe they’re supposed to click it, they won’t believe it will do anything, and therefore they don’t believe they have a way of communicating their intentions or beliefs (or confusion) to you. They might look around the page for something else, but what if they keep missing it because of some other UX failure or code failure? It would be so much easier and faster to click the button which they believe they are ready to click, and then you could give them clear guidance about what to do next. In other words, the user is “lost” in the interface rather than “early” to click the button.