Question:
It is common for a user not to be able to use all the elements of the interface. This can be permanent (or semi-permanent, as some setting or permission change can change this) or momentarily. There are usually 3 strategies that can be used:
- Lets the user use it and displays an error message indicating that he can't do that
- prohibits its use and marks the object with any color that differentiates its "prohibited" status
- completely hides the object from the UI.
When and why to use each strategy? Does it matter whether the "prohibition" is (semi)permanent or circumstantial? Does it matter if it's web, mobile or desktop, or another device, I don't know, an industrial panel, for example?
Is there anything important I didn't notice about the subject? Feel free to complement whatever you like.
Answer:
@OnoSendai has already responded very well, but I would like to complement it with some things that I think are important.
1 Lets the user use it and displays an error message indicating that he cannot do this.
This option is potentially the worst for the user experience. If a user has attempted an interaction, one of two things: either he wanted to do it or he was led to believe he needed to do it. Thus, the attempt followed by the non-permission results in frustration in the first case and in unnecessary difficulty in the second (which, at the very least, goes against the usability principle related to efficiency).
3 Completely hides the UI object.
Although better than the previous option, this option also has some problems, mainly according to the usability principles related to learning and memorization. Whether or not an interaction element can be presented according to contextual variations, this requires the user to remember more information ("where did that field go?") and learn more steps so that the interaction can eventually be useful. User tests will have to be done to see if there is a real problem when this form is used, but potentially it will generate more difficulty for the user than it will benefit their security.
2 It prohibits its use and marks the object with any color that differentiates its "forbidden" state.
Among the options placed, this is perhaps the best for the user experience when an interaction should not be allowed. @OnoSendai put it very well that it might be important for the user to know that interaction is possible in another context (ie it exists). In fact, it is also important because it makes it easier for the user to understand why the interaction is not allowed at that moment/context. And the context of the interaction is what makes this understanding easier.
For example, when filling out a form where you choose on a selection button (a radio-button) whether the user is an individual or legal entity (a company), filling in information relating to the company, such as the number of the National Register of Legal Entity (CNPJ, in Brazil) should only be allowed if the choice in the previous selection object is a legal entity. Enabling/disabling the registration number field is in the same context as the selection object and the change in behavior can be observed and learned in the same view (same screen).
It should be possible to see that then other issues begin to be involved that also need to be analyzed in the interaction project. In this particular example, the selector-registry number fields must be placed close enough so that they are easily related by the user.
concluding
Allowing the interaction just to indicate (via text message or error) that the user could not have tried it is commonly exhausting and probably useless. The best options are to hide the action option or simply disable it. If the option to hide seems more appropriate, it might be relevant to consider whether this interaction should not be in a proper/separate context (in another window, for example). Because maybe it makes more sense to let the user use it when they really need it instead of hiding it from them. Finally, disabling interactions can make more sense especially when this impossibility of use stems from an immediate (or very recent) action by the user, and which may be temporary within the current context (in the case of correlated fields, as exemplified).