Limiting Action Due To Permissions

Question

How would you prevent someone from performing an action on the front end (Obviously this would be enforced on the back end, but I'd imagine you don't want the user thinking they can perform an action if they can't) when they are not allowed to perform the action because they don't have the permissions for it? How would this change if they sometimes have permissions to perform the action but not in this specific case.

Two examples:

1. A user may be a limited administrator of an account. Each user has a role that determines what permission they are allowed to perform. As a limit administrator he may be able to create new roles or edit existing ones. However, he obviously can't edit his own role or he would be able to give himself permissions he doesn't have.

2. A user is a standard user of the account and has a role that gives them permission to view something but they cannot edit or delete it.

The way I see it there are 3 possible options:

1. Hide the button so the user can't perform the action. This seems like it would be good if the user can never perform the action, but can be inconsistent if they can only sometimes perform that action as in the first case where they can edit roles but not their own role.

2. Disable the button if the user can't perform the action. This provides consistency, but may confuse the user as to why they can't perform the action (especially if they usually can). This can maybe be fixed with a tool tip explaining why the button is disabled, but this seems strange and un-intuitive.

3. Keep the button enabled, but when it is clicked show a popup explaining the action can't be performed because they don't have permission to do it. This one lets the user know why they can't perform the action, but just seems like I am misleading the user into thinking they can perform the action and that it could get annoying.

These are the 3 options I was able to come up with, is there a better way to do this. Is there any research on how to display an action when the user doesn't have permission to perform it?

Answer 1

Option 2 (disabling buttons and providing hover tips) allows everyone in the organization to see the functionality, but brings to the surface user roles and their limitations. It's explicit about who can do what.

Some personal experience

I've worked in enterprise situations where functionality was hidden for different roles, and it was a bottleneck in terms of coordination between different users.

It's hard to remember who does what, and who has which permissions. This can be a problem when coordinating work.

If I don't even see a button, I assume the functionality doesn't exist.

Caveat: This doesn't apply to most sys admin functions, such as user management and the like. I'm referring to common actions such as CRUD in the normal UI.

Answer 2

Popups are a no-go imho. Most people don't like these things. There is a reason why many modern applications try to integrate the information a popup delivers in their main interface. Extra interaction steps are tedious to undertake. Users are lazy. Don't go against the flow.

Unlike @MikeM I'm more inclined to say - it really depends when it comes to hiding vs. disabling.

Hiding is generally the preferred way to go in case you have a lot of functionality exposed to the user. Putting stuff in deeply nested menus (to hide things) is not such a great user experience. That is why well designed modern applications tend to go for a more flat UI (not the visual style but the hierarchy of how information is presented to the user). It has a huge disadvantage - increased difficulty when it comes to cooperation between users with different permissions. Unless your UI clearly gives a hint what is missing (which defeats the purpose of hiding) two user may land in a situation where one user with more permissions expects from a user with less permissions to have functionality X exposed. Of course as time goes users will learn what their permission level gives them access to (schooling, general experience by working often with the given UI).

Disabling circumvents the disadvantage of the hiding mechanic I've mentioned above however it introduces another problem - exposing too much functionality which the user cannot actually use. If your UI exposes a lot of things through buttons, tables, lists, comboboxes, radio buttons, menus etc. the user will have a difficult time finding the information he needs since that information will be overshadowed by functionality that is disabled, yet present. But of course having things that you can't interact with may have a positive effect on the user, who may actually read the provided documentation to find WHY he is not able to use the specific feature.

Analyze the amount of functionality your UI exposes and then go for hiding or disabling (or perhaps both?).