What to do when a UI element cannot be used by a user?

Asked

Viewed 680 times

31

It is common for a user not to be able to use all the elements of the interface. This can occur permanently (or semi-permanent, since some configuration or change of permission can change this) or momentarily. Usually there are 3 strategies that can be used:

  1. Lets the user use it and displays an error message indicating that he cannot do that
  2. prohibits its use and marks the object with some color that differentiates the "forbidden" state from it
  3. completely hides the UI object.

When and why use each strategy? Does it matter if the "ban" is (semi)permanent or if it is circumstantial? Does it matter if it’s web, mobile or desktop, or even another device, I don’t know, an industrial panel, for example?

Is there anything important I didn’t understand about it? Feel free to complement whatever you want.

ux

5 answers

27


@Onosendai has already responded very well, but I would like to complement with some things that I think are important.

1 Lets 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 tried an interaction, of the two: either he wished to do it or he was led to believe that he needed to do it. Thus, the attempt followed by the non-permission results in frustration in the first case and unnecessary difficulty in the second case (which, at the very least, goes against the usability principle related to efficiency).

3 Completely hide the UI object.

Although better than the previous option has also some problems, mainly according to the principles of usability related to learning and memorization. If an interaction element may or may not be presented according to contextual variations, this requires the user to remember more information ("where did that same field end up?") and learn more steps so that the interaction can eventually be useful. There is testing with users to see if there is a real problem when this form is employed, but potentially it will generate more difficulty for the user than benefit to its security.

2 Prohibits its use and marks the object with some color that differentiates the "forbidden" state from it.

Among the options put forward, this may be the best for the user experience when an interaction should not be allowed. Onosendai put it very well that it may be important for the user to know that interaction is possible in another context (i.e., it exists). In fact, it is also important because it makes it easier for the user to understand why interaction is not allowed at that moment/context. And the context of the interaction is what makes that understanding easier.

For example, in filling out a form where you choose on a selection button (a radio button) whether the user is an individual or a legal entity (a company), filling out information related to the company such as the number of the National Register of Legal Entities (CNPJ, in Brazil) should be allowed only if the choice in the previous selection object is a legal entity. Enabling/disabling the register 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 notice that there are other issues that need to be analyzed in the interaction project. In this particular example, the selector-number registration fields should be placed close enough to be easily related by the user.

Concluding

Allowing interaction only 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 hide option seems more appropriate, it may be relevant to consider whether this interaction should not be in a separate/proper context (in another window, for example). Because maybe it makes more sense to let the user use it when it’s really necessary instead of hiding it from him. Finally, disabling interactions can make more sense especially when this impossibility of use arises from an immediate (or fairly recent) action of the user, and that can be temporary within the current context (case of correlated fields, as exemplified).

  • 3

    +1 - Especially 'Allowing interaction only to indicate (via text message or error) that the user could not have tried it is commonly exhausting and probably useless'

16

It depends on the desired user experience philosophy. In general, some rules are used as default[Citation Needed]:

  • Available function: When your procedural validation needs to be atomic and at the end of the action (late validation).
  • Disabled objects: When your goal is to demonstrate a soft block; The user benefits from the knowledge that the function exists, but some context (security, authentication, service availability) does not allow the action at the time.
  • Hidden object: When there are no benefits to the user knowing that functionality is available.

Viewports with visibility restrictions (mobile devices, for example) can cause objects whose behavior was originally worth a Type 2 rating to fall to Type 3.

10

My personal opinion is the same as Joel Spolsky.

Do not hide or disable.

I’ll leave the translation here:

A long time ago, it became fashionable and even recommended to disable menu items that cannot be used.
Don’t do this to me. Users see the menu item they want to use disabled, and have no idea what needs to be done for the menu item to work again.
Instead, leave the item enabled. If there is any reason why the menu action cannot be completed, the item may display a message informed the reason to the user.

I have an alternative approach. If the element is a button large enough for there to be explanatory text below, you can disable the item. In the explanatory text you say the reason.

The most important thing is to always make the user aware of the reason that he cannot use certain functionality. Hiding can confuse users, and disabling without explaining the reason generates frustration. I say this because it’s what I feel when I see a disabled element and I don’t know why.

  • In any situation? This is the central point of the question. If the user never has access to something, should he watch it? Should you leave him drooling to know what’s behind it? The SE really uses this recommendation a lot, but not always. Look at the vows. If you can’t vote right now, you only know if you click. Of course, you could have information indicating the reason for the momentary ban without having to click. On the other hand if you cannot see the positive and negative votes separately this is hidden, and gives no reason.

  • If the user can never use, I think it is the case not to display even.

  • 1

    The key is the phrase: "The most important thing is to always make the user aware of the reason [...]". The question is whether this science is best transmitted before or after an action. In general, requiring additional action only to communicate impossibility of use is not the best alternative, especially when there are "clear" prerequisites in the same context ("Copy" or "Save" menus, for example). But disabling a menu that offers a more atomic function ("Import CSV", for example) will cause confusion. Therefore, the ideal is to evaluate design choices with users.

  • 2

    P.S.: If something is never used, nor should it have been built. :)

  • @Luizvieira I think it varies depending on the case. The bigown has drawn attention to Stack Exchange’s moderation buttons, which will appear as you gain a reputation. Once such a button appears, unless you lose reputation, it no longer disappears.

3

The first point I see in this whole question is that, as much as we add references, the answers still have a tone of opinion (including, this is an opinion[using irony]). Usability is a more human area, which allows different understandings in several cases, not different, on this subject. However, let’s get to the point, to the question.

Going directly to my central point on the subject, different people expect different things from different systems(What did I mean by that!? ). Well, before we think, "am I going to hide the element? I will display the element and if the user interacts warning that he cannot perform that action? I will change the element design indicating that the functionality is 'forbidden' for it?" we have to think, "what does my target user want/expect from the system?". That is, an ERP user expects certain actions of the system while a user of video straming services expect totally different things of the system, whereas a user of a given social network expects even more different things when making use of the system. One "living" example of this is the OS, the OS community, if not all, the majority, is composed of people from the technological areas, such people expect different things from the OS than if they were users of more human areas. Still in the OS example, it uses Gamification to encourage users to ask and answer when we access the privileges, we see everything we can have if we achieve such a score, they are clearly making use of the second option quoted in the question, but they have a purpose behind it which is to urge the user to answer/ask to get to that score and, finally, be able to perform such actions, already in another area of the site, as the analysis queues, are only visible when the user "gains" permission to access that functionality and, again, using the 2nd option of the question, the OS disables what the user cannot do, even with the idea of "provoking" the user to, one day, reach that score and gain access to functionality.

The most direct answer to the question is depends on. Yes, in the question it is already understandable that there is a depends, after all it is asking

When and why to use each strategy? It makes a difference if the "ban" is (semi)permanent or if it is circumstantial?

But, as my approach is "impossible" to answer one of these questions without first thinking, "who is my user and what does he want/expect from the system?" (yes, I’m being redundant)

Lets the user use it and displays an error message indicating that he cannot do that?

No doubt, in every context, this is the worst option of all, it is giving the user the impression that he can do something that actually he cannot. It is undoubtedly a very bad experience. Imagine opening a jar of ice cream and finding beans inside?

prohibits its use and marks the 1object with some color that differentiates the "forbidden" state from it?

Again, "who is the user of my system?". For example, if he is a user of a corporate system and he is an "operator" there is no reason for him to see the button generate financial report, since such an item is of interest to some manager, now, as the example given above, if it is a user who, somehow, he can "reach" the permission to execute that functionality, is extremely valid the use of this option, because the user will be "provoked" to want to do that action, often it can be only by the fact of "I can", but what I see in these situations is the engagement caused.

completely hides the UI object.

Finally, if not the most commonly used option, one of them would be to hide the UI items. And again the question, "Who is my user?" , using the example of the user of a corporate system, will be that hiding the financial report button can not display items of more interest to this user, things that will make much more sense he see, instead of taking up space with something he can’t do and it’s not in his best interest? and in the case of the manager, there is need to see fields where data are "imputed", and who does this is the operator? in most cases the most interesting for the manager is to see very large graphs and numbers on the screen, or maybe in some cases it is not, therefore, "Who is my user and what he wants/expects from the system"

Thinking of something more "technical", I did a short heuristic analysis of the 3 options. For this I used the 10 heuristics of Nielsen:

Lets the user use it and displays an error message indicating that he cannot do that?

Feedback/Visibility of System Status:

  • Upshot: Neutral

  • Description: After the user tries to perform the action is returned error message, stating that he cannot do such action, ie there is feedback, however, there is failure because there is no visibility of the status of the system. A function is being displayed that the user cannot perform.

Freedom and user control

  • Upshot: Negative
  • Description: The user is not given freedom, since the user is allowed to "initiate" an action that he cannot perform. In fact, user control over the system is being removed.

Flexibility and efficiency of use

  • Upshot: Negative

  • Description: The system has to be easy and intuitive, from the moment you have elements on the screen and when the user clicks he does not know whether or not the action is lost all efficiency, generates a doubt, "when I click on the element, what I want will or will not be executed?"

Aesthetics and minimalist design

  • Upshot: Negative

  • Description: It should not be inserted on the screen unnecessary information, items we do not use, we have to think about displaying the best for that particular user.

prohibits its use and marks the 1object with some color that differentiates the "forbidden" state from it?

Feedback/Visibility of System Status:

  • Upshot: Positive

  • Description: Makes visible to the user what the current status, when changing the style of the element to a style that denotes "de-authorization" for that function, is given visibility of the status, as for the feedback, the ideal is to inform the user if one day he will be able to do such action and, if yes, what he needs to do to get.

Aesthetics and minimalist design

  • Upshot: Neutral

  • Description: Item "relative to the future", will the user be able to perform such action? if yes, there is an advantage to knowing about that element in the UI, if not, the element "steals" space from other items.

Flexibility and efficiency of use

  • Upshot: Neutral to positive

  • Description: It is necessary to identify the relevance of displaying an item that the user cannot interact with, if there is gain from it becomes positive and brings efficiency.

Freedom and user control

  • Upshot: Neutral to negative

  • Description: The user can feel without the control of the tool since several elements are displayed in the UI that he cannot interact with.

completely hides the UI object.

Flexibility and efficiency of use

  • Upshot: Positive

  • Description: It is possible to display items of greater user interest in the UI and items, which at that time, will add more value to tasks, if 1 day makes sense the user see a certain extra element in the UI then this one should be added.

Aesthetics and minimalist design

  • Upshot: Positive

  • Description: All UI is geared only to what the user needs to see, not "unnecessary" elements occupying space.

Freedom and user control

  • Upshot: Positive

  • Description: The user feels in the "power" of the application once he can interact with any element on screen.

  • 1

    Very good! I believe that this kind of question should be a off topic. Even believing that she should not be here, I am very interested in the subject. Being interested in the subject, I agree with your position "in gender and equal number". Agreeing, +1!

  • 1

    I liked the answer. Won my +1. : ) Now, I would like to comment that although I totally agree with you as to what the user needs to be at all times considered, I don’t think the answer is really "depends". Many people have been studying this subject for almost 2 decades, so it is possible to have a set of good practices that indicate the best way general. You yourself make an analysis in this sense by using Nielsen’s heuristics. That is, there is certainly a standard solution, which works best in many cases. But it must be adjusted to the context and user.

  • 1

    @Luizvieira, I agree with you, maybe I was very "sensationalist" in my "dependes". As you said, there are studies and more studies on the subject, no doubt there are metrics to be followed for the most diverse cases. My central idea was to put the user first. Later I will try to adjust the answer as to "depends".

1

In my view, it depends a lot on the scenario and the context in which the element lies.

The option to display a message informing the user that he does not have permission

I am not in favor, because in my 5 years in the support sector of a company, I always received calls from customers, outraged by the fact that:

Why is there an option where I’m not allowed?

Dare it be the user visualizes the possibility to perform an action, but can not. This is frustrating and ends up generating a support demand. Even if it turns out that it was the system administrator who blocked the access. Or that the client does not have access because the license does not allow.

Keep the element locked

In the case of a menu item, I am in favor of not displaying, if the user does not have permission, because as colleague Renan said, it would be bad to show something that does not work because it is disabled, for reasons of permission.

The worst is that if the element, is shown but does not perform any action, the user can understand that it is a bug, system, and again will be generated a support demand.

In another scenario

Let’s imagine a customer registration screen. We have the following types of client.

  • Natural person
  • Legal person

Being that for individual we have CPF and for legal entity we have CNPJ.

I have seen the following approaches

  • Create only one element that accepts both information.
  • Include both elements, and disable typing of one when the other is filled.
  • Create a select element, so that the user informs if he is a natural or legal person, so that the appropriate element can be presented

In addition to the CNPJ/CPF field, we have other situations like:

  • State registration that is for legal entity only
  • ID which is for natural persons only

Even several other elements that may arise in this sense.

Based on what I said, I am in favor of creating an independent screen for Individual and a screen for legal person.

Even if they share properties in common, and even can be stored in the same table in the database. I think this way we decrease these controls to enable and disable elements.

What I think can generate several problems, for example:

In case I have to manipulate the registration screen to include a field that will be for legal entity only. In addition to having to include one more condition to enable and disable the element, you run the risk of me forgetting to do this control, or even disturbing something that already works.

  • 1

    In that situation I believe that creating separate screens is unnecessary, will often generate duplicate code or more checks, besides hindering a possible form exchange. About "runs the risk of me forgetting to do this control, or even disturbing something that already works.", intends to make a change to the system and put something into production that may not work? Also, when dividing the screen, the same can occur in other parts. But even so +1 for mentioning the fact of the support

Browser other questions tagged ux

You are not signed in. Login or sign up in order to post.