There are multiple examples, so I'll pick a specific one to focus the question.

Let's say a user can have specific characteristics (or permissions):
Admin, Virtual, External, Financial, etc.

To complicate things, users have different licenses too - Premium, Regular, Limited, etc.

You can probably see where this is going:
Let's say a user with a limited license cannot be an Admin or have financial permissions.


  • The admin goes to the profile of, let's say Zack and sees he cannot allow him to have financial permissions.
    The problem is that it's not clear to the admin why that is (the license info and the permissions are not displayed in the same location and even if they were, the admin would have to be aware of the system rule of "no financial permissions for limited users")
  • The admin sees all the permissions (let's assume implemented via checkboxes) enabled and only when clicking gets an error message informing why the operation was denied.
    Now the reason is clear, but the admin had to "waste" a click to find that out.

Is there a way to both prevent the action and also explain why? Would a disabled control with a tooltip work? Any better ideas?

To briefly mention other examples - let's say you have an interactive graph and you can move most of the points on the graph, but some have to be stationary. You could draw them differently to indicate they cannot be moved (without explaining why), or you could let the user try to drag them and then show an error message.

  • 1
    You have so many answers that might not fit you. The one you picked as the correct answer isn't neccessarily the right one. You have to ask yourself: Why? Why do you have different users? Why do you want/don't want them to know about a feature? If it were a game, showing something that isn't there but is attainable is attractive. Otherwise don't show because if someone can't use it then it will only take them more cognitive load to look at the button decide that it is disabled and move on. This affect their experience and is a perfect reason why UI.stackexchange.com is lesser to uxexchange.com Aug 22, 2010 at 7:46

13 Answers 13


Depending on the application, I often just don't display the parts of the page a user doesn't have access to. It sounds like you have users changing other user's rights, so this method may not work. I would recommend displaying an error message whenever you display a disabled input element. Users can become frustrated when they are unable to perform an action they expect to be able to do. If it is just disabled, they probably wont understand why and will just take it out on the program. Likewise, you want to make sure the message is as simple as possible and to the point. Long error messages are often ignored.

  • Thanks. Just disabled, or disabled with a tooltip? Since the user might not even hover on a disabled item, perhaps even adding a small "i" to indicate there's more info there? Or is it too much?
    – Dan Barak
    Aug 15, 2010 at 18:10
  • 2
    I would include at least a tool tip. If you have help docs you could include an asterisk or something similar that links to the topic in the docs. Aug 15, 2010 at 18:15

Before you completely hide a part of the UI for a feature which the user doesn't have access to, consider:

  1. Will the user know about that feature?
  2. Will they spend a lot of time hunting for it?
  3. Would you be better off keeping it around in some kind of "disabled" state along with a tooltip or other indicator so that they can learn why it's not available?

Here's a simple example. Suppose that your application includes the option to print. When there is no printer available, should you completely hide the print menu command? Will this cause confusion and wasted time as the user hunts through all the menus and finally contacts your tech support team trying to find the "print" command? Will your tech support team even understand that this user is not seeing the "print" command? Will there be unintended side effects if, for example, the printer is attached but has turned itself off to save power?

As a general rule, I believe that in many cases, especially cases where an option is sometimes available, users are best served by a disabled option or even an enabled option that brings up an error message explaining WHY the option is not currently available.

  • 12
    Great answer. You should write a book about UI design Aug 16, 2010 at 19:55
  • Thanks, Joel. I completely agree and that's the direction I'm going.
    – Dan Barak
    Aug 17, 2010 at 6:58
  • 1
    I believe that Cooper & Reimann discuss this particular topic extensively in "About Face 2.0" (and probably in "3" as well). If I'm mistaken ... well, everyone should read the book anyway :)
    – jensgram
    Aug 20, 2010 at 7:52

I see two different approaches.

If the actions are disabled because of security I would actually try to remove them if at all possible. Easy with menu items or most toolbar buttons.

If the actions are disabled because you have a cheaper version of the software, I'd keep them present but disabled. This lets the user know "you could have this if you paid more" whereas if it were removed they would not know what they were missing. I view the "you can't do this because of license" popup to be bad UI since the user cannot tell if they can do an action without actually trying to do the action.

  • 2
    "If the actions are disabled because you have a cheaper version of the software, I'd keep them present but disabled." -- Really good point! Aug 16, 2010 at 4:59
  • Thanks - I agree. In this specific case, it's not a cheaper version of the application, but the user itself is limited... and actually it's not the user doing the action (the admin), but rather the user the action is performed upon. :)
    – Dan Barak
    Aug 16, 2010 at 9:38

Another approach is to not show the action at all.

Stack Exchange is a good example of this. If I don't have "edit" rights to other people's posts I don't see an "edit" link at all. This means I don't try to click it and wonder why it doesn't work.

This might not work in all circumstances, but in your example the "admin" and "financial" options/links just wouldn't appear for limited users - even in the admin screens for those users. If the user was changed to a "Regular" or "Premium" user then those options/links would appear.

You might then consider displaying the type of user somewhere semi prominent so that the administrator can be reminded of why certain options/links aren't visible!

  • 2
    Thanks, Chris - it's a very good answer. However, not showing the action is almost equivalent (IMO) to showing it disabled in the sense that the admin still doesn't understand why they have the option for one user and not for another. Do you think that showing the option disabled but with a tooltip wouldn't work better?
    – Dan Barak
    Aug 15, 2010 at 18:07
  • If you display the type of user as Chris has recommended, you can then have an admin FAQ that explains the user types and what access they receive. If an admin is going to be assigning privileges or abilities, it is good for them to understand what the prereqs are. Aug 15, 2010 at 18:12
  • @Dan - you would hope that admins would have an understanding of the application before changing other users privileges :)
    – ChrisF
    Aug 15, 2010 at 18:26
  • @Dan - One could probably make the argument that if it is that difficult to determine why an action is not available in a particular case that the security mechanisms may be overly complex. This is a generalization but I think there is some truth to it. Perhaps it may pay off more to revise the security design and attempt to simplify it in such a way that security restrictions do not overlap unnecessarily and that granted permissions have clear consequences in the software.
    – jpierson
    Feb 4, 2011 at 3:31

As other answers have stated, if the user doesn't have permission to perform an action within the system (as in, no edit/admin privileges), then the action shouldn't be displayed at all.

In cases where actions are disabled because of application state (can't edit a read-only file, can't copy/paste if no text is selected, user has a trial version of software that lacks a few features, etc) I personally think the action should be displayed, with a visual indication that the action can't currently be performed. Note that I don't say "disabled," because if the user tries that action, they should be able to find out why it is not doable. This way a user can see that the action is disabled, but they can also get a message explaining why.

I would be careful with the case where a user has a trial / under-licensed version of an app that lacks features. For instance, if you had an ISO reading/writing app that wouldn't rip CDs unless you paid for it, then you could show the "rip CD" option but not let the user perform it. But if your application has entire suites worth of features in the higher-end versions of them (visual studio for example) then displaying all of those things but not allowing them could get frustrating for the user. I don't want to open my IDE and see database, networking, integrated UML, testing, profiling, etc suites when I know that all I am licensed to do in it is write and build projects.

  • 2
    "if the user tries that action, they should be able to find out why it is not doable" - 100% agreed for single actions, but if the action requires input, making the user input a bunch of stuff and then say "never gonna get this nananana" is bad. Aug 16, 2010 at 5:02
  • @robert of course. I can't think of any examples of what you mean, but I would think generally the message would come before the user is asked for any information Aug 16, 2010 at 5:32
  • Thank you for making the distinction regarding "disabled", it's very true.
    – Dan Barak
    Aug 16, 2010 at 9:36

My rule of thumb is: If an action is not available to a user because of permissions, it is not visible. If an action is not available because of temporary context (this 'Save' button has no meaning until the user has entered something to save), then it is disabled.

"Permissions" covers both "admin user vs regular user" and "premium license vs cheapo license". Unusable UI elements are clutter - not the way to advertise your additional features.

  • Regarding your additional features comment, it really depends on Dan's world. He may be building an enterprise app where a certain job title gets to change user permissions. They would want to see the controls in place whenever they are at the screen that normally provides the controls. Not seeing the controls would only create frustration. It isn't quite the same as say a portal that has anonymous access where users who log in get more features than a user who is anonymous. In that case you wouldn't want to show the login-required controls. Aug 16, 2010 at 16:18
  • mickeyf, you're correct - my situation is a bit more complex, with the permission of someone else effecting the view of the current user.
    – Dan Barak
    Aug 17, 2010 at 7:03
  • I wrote a (Windows, not web) app once in which an admin user could set the availability of features for a non-admin user. In this case, all available features where shown to the admin user on a form with checkboxes to enable/disable them for the regular user. Any that weren't available to the Admin user were shown disabled. They could be changed by a a "super admin" user. A bit tedious, but perhaps roughly analogous to your situation. Aug 17, 2010 at 14:42

Many answers seem to got this right, just wanted to sum it all up with one of Nielsen's heuristics, which points exactly at this. It states:

Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Source: http://www.useit.com/papers/heuristic/heuristic_list.html

  • Great reference.
    – Dan Barak
    Aug 17, 2010 at 6:59
  • I'm unsure if this applies. Perhaps this is not an "error state" we're taking about here, even tho the asker uses the "error message" as an option to communicate to the user that the action is not available. It's like a message or "warning state". I don't think it's an error or exception, to which i believe your quote more applies. As in Joel's answer, the "careful design" is to keep the "message/error" happening. Hope that's clear.
    – cottsak
    Oct 29, 2010 at 10:46

I really like shemnon's answer. I would extend his second case and apply ign's referenced Nielsen commandment; if the user has a cheaper license, I would disable the option and replace the selection object with an icon that further makes plain the option's disabled state.

Something like

  • O Option 1
  • O Option 2
  • alt text Option 3
  • O Option 4

As this suppositional product is still in development, I would also include at least a statement of the user's license level on the same page. That way, the admin sees that the user's license level at the same time that admin is looking at the system variables directly affected by that license.

A beauty of software is that all you have to do is call the information.

Edit: Additionally, I might employ a roles-centric permission scheme, where permissions can be assigned to roles and not individual users. This often mitigates a ton of overhead from needing to micromanage individual user permissions.

  1. Admin opens role-editing screen.
  2. Admin maybe selects a radio button for lowest license to which the role will be applied.
  3. Permissions that aren't available to the selected role are disabled and "x"ed.
  4. Admin selects permissions from remaining active options.
  5. Later, in the user management screen or the user profile, admin sees list of roles that user can have based on license, and the admin selects one or many.

Some of the points above are great, and I don't want to re-iterate, but...

In this case, I would have all available options visible. The options that were not applicable in your rules, should be disabled (grayed out). It is common knowledge for a user of any interface to recognize that if something is grayed out, it typically means it's not applicable for some sort of rule set going on.

A tool tip coincides with a disabled button perfectly. In some special, more advanced cases such as yours above with licenses, if the user without the proper license was viewing an area that required a higher license, completely changing the art of the button to something like "Upgrade Now!" instead of graying it out would be better advertising for the product, and get the point across.

If the admin user was viewing it, they would obviously see that the financial option is grayed out, with a tool tip explaining why.

I do not fully know the context of your issue, there may not even be a product involved. But based on what I understood, that's my reaction to it.


In general, my rule of thumb goes like this (and I need to have a good reason for breaking it): If the reasoning behind the disabled component flows from the context or that understanding it should be easy for the user due to other reason, then blocking is the preferred solution. Else, user might be frustrated trying to figure out why it is like this, and worse, probably will not remember the reason for it (case he figured it out) next time he encounter it.


To answer your specific question, you want to display sufficient information so the users can understand the limitations before they click. In your example, you should list each user with their license as a read-only field visually connected (e.g., by proximity) with the controls to set their permissions. Or you could combine the license field dynamically with the label for the permissions (e.g., “Permissions (with Limited License):”).

Non-applicable permissions probably should be disabled, not enabled and not hidden. If it’s worth the clutter, include in-line text, hover text/ tooltips, or a link for explaining why the permissions not allowed by the license (in-line text may replaced the disabled controls if it lists the permissions; for example “Admin, Financial not allowed for Limited users”).

The general rule is use disabling if the user can do something in the UI to enable the command. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection. Whenever you use disabling, there should be a clear indication so users understand why the associated commands are disabled for some objects.

Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user beforehand assuming they have average knowledge of the domain. Tooltips for disabled controls are a great idea, but may not be sufficient by themselves in all cases.

Use hiding if the user never has the access to the command no matter what they do in the UI given their current position in the organization. For example, actions not authorized by the user given their permissions simply don’t appear. It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the rights for are not their job (otherwise they’d have access), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new customer accounts for you” or “You need Financial permissions to edit accounts; see your administrator for the procedure to get approval to upgrade your permissions.”).

I’ve gory details at Controlling Your Controls.


Do Both: Backend and UI

This really shouldn't be an either or situation. The other answers list good reasons listed for showing unavailable options, and good reasons not to show them. But the thing is, either way, you need to handle it properly on the backend. You still need to properly check user inputs and permissions, even if you think that the only input they can give is a proper one.

This holds doubly true with any web-based application, where the user could artificially enable a disabled control/option/input. Don't let use of Firebug trump your app's ability to control what I can do. And in cases where they try to use an option that shouldn't be available, make sure you log the event.


The Windows UXGuide has quite a bit of resources that may help you decide on whether to show errors or prevent invalid input. Specifically there is a section that makes the below statement about ui.

Don't give error messages when users aren't likely to perform an action or change their behavior as the result of the message. If there is no action users can take, or if the problem isn't significant, suppress the error message.

Also this discussion reminds me a bit of what Karl Shifflett in his blog post titled "Fort Knox Business Objects ( yes / no )" where he weighs the pros and cons of whether to allow business objects to enter into an invalid state or not and how this decision effects user interaction.

Personally, I tend to prevent a user from making invalid entries or disabling controls that perform actions such as buttons most of the time but for some controls that involve complex text entry I tend to show inline warnings which are less obtrusive than message boxes but still get the point across.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.