Not available actions can create frictions and frustrating experience, most important thing is to make the reason clear and accessible. If you show a button (or any actions) but don’t allow people to interact with it, they will have to interpret why they can’t. We rarely recommend to use disabled elements because they have poor color contrast and have a development cost by adding properties to be seen by screen reader and to display a tooltip.
Actions criticality
Every item in an interface — like button — is competing for attention and straining users’ cognition. Especially in a complex interface, where lots of competing information and controls are inherent, noncritical elements make visual-search tasks more difficult. We recommend anytime it is possible to avoid to display unnecessary buttons and disabled elements.
Zoning
(1) Page's (other) actions: Secondary and third category actions. Display and hide contextually.
(2) (3) Secondary and primary actions: Secondary and primary buttons considered as important. User always need to know instantly if one of these buttons stop working or what is missing in order to perform the action.
Types of buttons
We have 3 levels in buttons hierarchy:
Primary and secondary actions
Default
Always keep normal state for any primary and secondary button from primary actions. Let's keep these buttons clickable (showing a guidance message on mouse-over if needed), and highlight what information is missing/wrong if/after user click if conditions are not completed.
Primary button deactivated
Hide button and inform user. If primary button is not currently functioning (system), this is something that all users should know about it so say it with text.
Secondary button deactivated
There are different usecases (Action not available at this time in the workflow, Incompatibility depending on the type of content..). Secondary button(s) from primary actions must be explained as real text. If you have multiple not available buttons, you can summarise them in one sentence.
Page's (other) actions
Orient design choice to avoid disabled element
There are no deactivated UI component that could not be removed by rethinking the interaction design. You can replace for example checkboxes with radio buttons if you have exclusive choice to do. You can reduce the number of actions in your page. You can guide users by adding more steps in the flow.
Don't be afraid to hide unnecessary buttons
If it’s not valid, then don’t show it. Mostly true for Button links (must be considered case by case):
Say it by text
If it fits with your area and if it will helps user experience, say it by text.
You cannot say it by text
If you cannot say it by text (and if an action on the current screen can enable the button), use disabled state.
Table
Hide buttons dynamically according to item(s) selection. This list of actions is conditional, meaning it can change from noting is selected to a single to a multiple selection.
Special rights / Configuration
Depending to user configuration, certains profils can clearly be limited (or not) to a short list of actions. Hide button as it is not relevant to display action buttons a user do not have permission to perform. In order to not get them confused with something they cannot work with, it is not recommended to list all possible actions the system is able to do with other profiles.
Sources