Should I have a disabled button or no button at all, if the user doesn't have sufficient privileges for the action?
Should I have a disabled button or no button at all, if the user doesn't have sufficient privileges for the action?
I would like advice on whether a disabled button is better than no button for a certain UI.
Basically, the regular (experienced) users can either comment on an issue or close it; the users with restricted access (such as inexperienced developers) can only comment on the issue.
In this case, there's no way to edit the access restriction directly inside the app, as it fetches information from a separate service. And it is very unlikely that the restricted user will be granted access to the action by simply inquiring it.
Is it worth it to display a disabled button even though the user cannot press it or do anything to enable it, or is it kinder to him/her to just not show the "Close" button at all?
PS There's also a chance that they're using the app with a different team where they do have an access to the "Close" action. In that case, I'm afraid hiding the button altogether when they don't have rights might confuse them when they navigate from one team to another.
If the functionality is only available to two website developers (Shhh!) then there is no benefit in letting others know about it. If there is a reasonable population of users who can use it, and it doesn't overly clutter the UI, then I'd go with Pectoralis Major: show it disabled with an appropriate tooltip. Regarding clutter: when you wind up with 30 buttons and no more than six are enabled for any given user then a different design is in order.
– HABO
Sep 10 '18 at 19:39
"is it kinder" Is the goal to be kind or is the goal to be clear and intuitive?
– Mast
Sep 10 '18 at 21:08
Something slightly different: When I look at your screenshot, "close" is the primary button, even when you want to disable it in some situations (and seems to encourage commenting instead). So currently your UX is communicating the wrong primary action and disabling a primary button will make the users believe they did not fill in all required forms or something similar, because a primary is the action you do after filling in the form (or similar actions). So you probably should first swap the close and comment buttons. This may make the rest of your question easier to decide as well.
– allo
Sep 11 '18 at 12:47
Thank you all for the suggestions. The close is the primary button, it is the main action for users to take. The mode where you don't have privilleges to use it is mostly for just browsing the issues. It is definetely not a secret functionality though, right now in other parts of application we do use the disabled button with the tooltip but I was wondering if there's a better way of doing it. Guess not at this point! Again thank you all.
– Ana Kash
Sep 12 '18 at 2:18
9 Answers
9
I suggest displaying the button in its disabled state and adding a tooltip explaining why it is disabled and how users can get the permissions to use this action.
Not displaying the button:
Users will search for this option and will maybe think they don't see it and therefore may spend time looking for it, possibly refreshing the page, restarting the browser, etc.
Displaying the button in its disabled state and explaining why it's disabled:
"Oh, I don't have permissions, but now I know how to get them or whom to speak to."
Adding on to your response, I was thinking the same thing, and another reason why this would be good is because it could even lead to motivating the inexperienced user to earn that privilege
– Philip RH
Sep 10 '18 at 13:35
I think it's important to explain why it's disabled. If you show the button in its disabled state with no explanation, there can be confusion as to why it is disabled. Have mouseover text (or some other way to notify the user) that the user needs more reputation or permissions to use the button (whatever the case may be).
– Doc
Sep 11 '18 at 19:45
The OP mentions that users are "very unlikely" to be granted permissions. Disabling an control that the user cannot take any actions to enable is only going to cause confusion, even with explanatory text/tooltips/etc.
– asgallant
Sep 11 '18 at 22:31
@asgallant I only see where the OP says "And it is very unlikely that the restricted user will be granted access to the action by simply inquiring it." Which is VERY different from saying it's very unlikely to be granted permissions period. I took that to mean that if they don't have permissions already, it's unlikely they will get them when they ask. OP also said that people without permissions will possibly HAVE permissions in another group. I also disagree that disabling something they can't get would be confusing. It is fairly standard on MANY sites. They may get annoyed though
– user118926
Sep 12 '18 at 2:48
Definitely agree with this. I was using a payroll app for my job yesterday (With an absolutely awful UI) and went to edit my home address. All fields were editable on the page, but there was no save button. Turns out I didn't have privileges to edit. Of course, there were two problems there: No button, and editable fields.
– Chris Schneider
Sep 14 '18 at 17:32
From your description, I think the answer is pretty clear. I get your concerns about some users' expectations but this button shouldn't be shown for a few reasons.
A disabled button will only generate negative cognitive load for everybody.
Users will look at the button and think about what it does, how it's disabled, and how to enable it. You're saying the users can't enable it so it will be a question they can't answer or will be negative.
It's not a disabled button because it can't be enabled.
A disabled button indicates to users that there is an action they can take to enable it. By your description, this button can't be enabled. Don't show users a button that can't be used or enabled to be used.
It's a poor way to communicate
The things you want to try to communicate through this disabled button should just be communicated in plain text or through the UI. If there are different levels of control, show the users that and inform them which level they're on.
As explored already by Pectorialis, hiding the button actually increases negative cognitive load. As it is now, it is immediately clear that the Comment feature exists, and where it is, and that it is not available in the current session. By hiding it you lose all three pieces of information for basically no gain. This is not always the case, but in this case it is true.
– Lightness Races in Orbit
Sep 10 '18 at 13:42
I upvoted this answer because i think this can be true on some really packed sites where a lot of information is displayed. In the case of the OP i think not displaying the button increases cognitive load, a good example i have is when our team first started using Jira (Project Management tool), we wanted to close our sprint but the person logged in did not see the option, we were 5 people in the room and all 5 of us started to search for the button, refreshed the site etc. Until the team leader entered the room and logged in just to see the "close sprint" button we all thought we are dumb.
– Pectoralis Major
Sep 10 '18 at 13:53
From a lot of web experience this answer is what you should NOT do. People will expect the button and hiding it only confuses them. By showing it disabled and providing a title or tooltip on why it is disabled will help users understand. Dont hide it.
– JonH
Sep 10 '18 at 14:29
LightnessRacesinOrbit you're assuming there's no other way to communicate this to users except disabling a button. Look at all the thought and analysis you're putting into this button's state and you're saying that's not cognitive load? pectoralis i get that concern but anything like that should be simply and plainly explained in the UI. In your story, your solution would be to have every single user cognitively consume that button every time they use the site so that the 5 users at that one unique situation would wonder where that button is.
– moot
Sep 10 '18 at 14:38
"A disabled button indicates to users that there is an action they can take to enable it." That's a bizarre reaction. If I'm in an airport and see a locked door, my reaction isn't "Gee, there must be some action I can take to get the key." I don't sit around generating "cognitive load" wondering what's behind the door, how it's locked, and how I can unlock it. When I go to the self-checkout at a grocery store and see a "log in as clerk" option, I don't go up to a store employee and ask how I can get permission to log in as a clerk.
– Acccumulation
Sep 11 '18 at 14:52
Is user likely to be aware of functionality?
Can an inexperienced user gain experience and then get the close privilege?
If yes, hide the button.
A button is extremely interactive element of a page. Consider these examples-
In Facebook, if you open a post in which you can only share, like and comments option are not displayed at all. Even though one can send a friend request and then like the post (once request is accepted).
In StackOverflow, if I do not have comment privilege yet, there is no comment option present.
A disabled button works well for empty inputs, i.e., until you have not written sufficient content, button is disabled. Or login button is disabled until captcha is filled. Or even for meetings, a button to join should be shown, but disabled until before 15 minutes. Here, user can come at designated time to join the meeting.
Simply put, showing a disabled button means there should be a way to enable it.
This is how me, or anyone expects them. A button disabled because of privileges should not be shown, because user cannot do anything to enable it.
In all the examples, user expects to get the button enabled after well defined specified time or action. In your case, user does not seem to have any well defined action to get the button enabled.
You can show text as 'You do not have close privilege yet.' It satisfies the curiosity of user, without motivating him to try for something he has no control over i.e. getting privilege.
Your example is exactly why hiding things in Facebook is so infuriating. Why can you share something some times, and not at other times? In these cases, share button is hidden when you can't share - but why?!?!?! When in a group, admin can turn off comments. In this case, comment links are gone, but a title shows why it's gone. Very little of what is in facebook is disabled, creating an inconsistent and very annoying interface causing one to have to google the reason a feature is gone.
– Andrew Jennings
Sep 12 '18 at 17:32
@Wigwam Yes, sometimes it is infuriating. As I said, user is likely to be aware of close issue feature. He knows that an issue can be closed. But showing a disabled button does not serve any purpose. Imagine you look at a list of issues, with two buttons on each- comment and close, with close disabled in multiple issues. You will find it a little more difficult to find issues which you can close. You have to look whether button is disabled or not, instead of whether button is there or not. Also, a disabled button should not be clickable, means you have to add a popover on hover to explain the
– psinaught
Sep 12 '18 at 18:02
(**continuation from my previous comment.) reason. Now popovers are not good for mobile. And instead of a button and popover, simply adding a text displaying reason is more effective. It shows a possible action, the fact that user cannot take the action as well as why, all without user having to click or hover a disabled button.
– psinaught
Sep 12 '18 at 18:08
On Stack Overflow, people with <50 rep still see the "add comment" button, but it is disabled and displays the message "You must have 50 reputation to comment".
– a stone arachnid
Sep 16 '18 at 22:06
@astonearachnid I think it is missing in the app. But still gaining reps is something completely in your hand. You can do something which will grant you the privilege. But OP says that even if they make a request, they won't be granted the permission to close. And I don't think they have some kind of experience points, which means that button will be completely useless to user. Most likely, until they become experienced a according to the admins, they won't have that permission, in which case they can't do anything. That's why button should be hidden.
– psinaught
Sep 23 '18 at 5:49
One massive reason for disabling (with explanation) the button rather than hiding it which has not been mentioned explicitly is that an experienced user will at some point end up using an inexperienced user's account alongside them.
I commonly have a similar issue with a product we use internally that hides an admin button when being used by people with lower privileges. When training the new user or helping them complete their tasks I am sitting with them at their desk using their account and can't find the button to do what I need to. Having the button there but disabled would remind me that I'm using someone else's account who doesn't have access to the action that I want to complete so I need to log in as my own user to fix their issue.
You might say that this is a rather edge case but as people are being on-boarded and need training from and issues resolving by more experienced users the problems will escalate. It may seem like the experienced user should know that permissions are the problem but it is a very good idea to remind them!
Why is there a button that would have functionality useful for the tasks of those with lesser privileges that they do not have access to? Could you not provide a limited version of that functionality that still fits within the privileges they have to make their job more efficient?
– JAB
Sep 12 '18 at 5:57
@JAB I work in financial markets compliance, almost everything they would be able to do if they had any access to that functionality would make the firm liable for very large fines.
– MD-Tech
Sep 12 '18 at 7:45
So it's just a matter of administrative stuff on your end (granting permissions/setting up accounts and things) that you realize you have to set up for them as you work with them, not necessarily things that they themselves have to do? It just seems odd to have to switch over to your own account for that functionality while teaching them how they're supposed to do their own job, unless their job includes making requests to you which you then approve/fulfill.
– JAB
Sep 12 '18 at 7:52
@JAB its a bit of both actually. Although I'm an admin on the system so do stuff like resetting passwords and unlocking accounts, when I'm training people the issue is usually the four-eyes process that we have to go through. No-one (not even a CIO) should be able to sign off on their own trades and every trade needs to be checked and verified but I always forget which tab I'm on (I log in once and they log in once in separate tabs). I've simplified somewhat but that's the crux of it.
– MD-Tech
Sep 12 '18 at 8:25
+1 That's my experience in StackExchange. I use several SE sites with different privileges. Sometimes I end searching for buttons that I don't have, just because I haven't noticed I don't have the privilege. A disabled button would be easier to understand.
– Pere
Sep 16 '18 at 9:53
The main driving force should be user expectation.
If the button is about a functionality that a user might expect to have, it should be there and the disabled state make it clear that it is not available (a hover tooltip can explain why).
If, however, it is a functionality that the user with the reduced access rights would not expect to have or see (or maybe even doesn't realize exists), it should be hidden.
In both cases, you are doing a trade-off.
Showing the disabled button makes it clear that the functionality exists, but is disabled, but could confuse the user who is wondering why you are showing him something that he can't do - and in the case of permissions, is unlikely to ever be able to do, unlike something that is only unavailable for temporary reasons, like, say, a "next" button that becomes enabled once the current wizard page has been filled out. One more advantage of hiding is that the layout of the page is the same for everyone, aiding muscle memory for people who might switch between different accounts or permissions, if there is such a thing in your application. It also allows documentation or help pages to refer to buttons by their position, as the position is invariant.
Hiding the button keeps the interface clean and useful, showing only what is actually available. It prevents "why they show this?" and "what would it do?" wondering by the user. However, if it is functionality a user might except, it replaces it with a different kind of "where is this?" wondering.
+1 yes, it is all about managing user expectations, and unless you test (which you always should) then it is best to apply some common sense and allow for the greatest user needs (if it is sensible to do so).
– Michael Lai♦
Sep 12 '18 at 22:05
StackExchange shows buttons even when the user cannot take that action, and shows an advice if the user lacks the privilege to use it. In this case, the button is neither disabled nor hidden. There is, however, a motivation for SE users to gain reputation and enable buttons so it makes sense to dangle a "this is what you could win" prize in front of them and then tell them what they need to do to get it.. I guess you need to decide if such a behaviour suits you.
Also, perhaps this button can be purposed differently according to permissions, so that it's always usable. Restricted users can only [Close]. Advanced users can [Save and Close]..
This is not strictly true. For example, I can't comment on a post if I haven't joined a site yet or I don't have enough reputation points.
– user128216
Sep 12 '18 at 17:51
+1 good answer although it is always good to consider both examples that apply this design pattern and those that don't just to understand when it is appropriate to 'break' the rules too :)
– Michael Lai♦
Sep 12 '18 at 22:04
@user128216 not sure I agree. I just went and found a random question on a SE site I haven't joined and hit the add comment link button. I saw a modal saying "thanks for your interest, this action requires 30 rep. Join this community" - it's an example of what I'm talking about. On the mobile site I see the link button but nothing happens when I press it. I figure this is more of a bug (the mobile site seems much more overlooked in terms of dev)
– Caius Jard
Sep 13 '18 at 3:29
StackExchange (on desktop) shows buttons you can't use for some core features (such as up/down voting and commenting), but not for many others (delete, close, moderator tools, editing questions, etc...). Which actually points to an important distinction when considering whether to disable a button or hide it: is the button a core part of the product that everyone will become generally aware of, even if they can't use it, or is the button a more specialized task that most people won't concern themselves with?
– Zach Lipton
Sep 14 '18 at 8:34
Generally it's good to display a disabled button to let the user get used to the interface, know that he can perform that action, etc.
The exception to this would be if the user will never be able to use that button, if that's the case just hide it altogether.
It depends on what exactly you mean by "simply inquiring it." "Inquiring" could mean asking for a privilege to perform a given class of action unilaterally, or it could mean asking a senior user to perform a single action on the user's behalf. If requesting an action makes sense for your application, then a button to request an action could replace the button to perform it.
Stack Exchange has several request-and-review flows. These include flagging, voting to close questions, and voting to delete answers. For a quick concrete example, look at suggested edits. Only users with 2000 or more reputation can edit other users' questions or answers. But on main sites and Meta Stack Exchange (not child metas), users can propose revisions that get reviewed by other experienced users. The form for suggesting an edit resembles the ordinary edit form, with the following notice at the top:
Your edit will be placed in a queue until it is peer reviewed.
We welcome all constructive edits, but please make them substantial. Avoid trivial edits unless absolutely necessary.
Once a user has submitted a suggestion, the following notice appears near the suggestion:
Thanks for your edit!
This edit will be visible only to you until it is peer reviewed.
The post's owner can then accept or reject the edit, or other users with edit privilege can vote to accept or reject the edit.
My analogy is this:
Your users are in a closed room. Your users are thirsty but do not have the right to drink the water at the moment.
Do you think having a big picture of a sink will help the situation?
Obviously the answer is no. They will be frustrated that they can see what they need but they cannot interact with it.
Thanks for contributing an answer to User Experience Stack Exchange!
But avoid …
To learn more, see our tips on writing great answers.
Required, but never shown
Required, but never shown
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
How do experienced users learn that the close button exists, and how do they get access to it? I think those would be the deciding factors.
– DoctorDestructo
Sep 10 '18 at 16:57