Site navigation based on roles

Question

We have an internal line of business app with a navigation menu at the top. Some users need access to the invoicing sections, others need access to forecasting sections, and admin users need access to both sections and admin pages.

Based on a user's rights is it better to hide menu items, show but disable menu items, or enable the menu items but show an access denied page when clicked?

Is there some another option?

Answer 1

Usually if a menu (or any interactive ui element) can never be enabled by the user it should be hidden. Otherwise, you create a hunting behavior where the user is trying to figure out how the menu could be enabled.

The best approach would be to hide all menus that the user does not have access to.

Answer 2

If an UI control, like a button, represents an action which is only available for users with certain permissions, the control is encouraged to reflect the lack of permissions to execute this action. Options are:

• change nothing in the UI and give a feedback after the user has clicked on the control (in form of a dialog or a warning label being displayed) -> causes the user to do one unnecessary click
• disable the UI of the control -> it's unclear why the button is disabled which is frustrating which can be fixed by displaying a tooltip text after the mouse rests still over the component for a time (might never happen if the user is impatient) or adding information why the button is disabled to the text of the control (e.g. "Save (only admins are allowed to save)") or next to it (e.g. "Save" for the button and a link label next to it reading "Want to become an admin?")
• don't show the button -> might lead to confusion for a user who has different permissions than another user and sees the changed interface by accident - and then lead to unnecessary questions in forums, Q&As and other networks in the form of ("Why is my friend seeing this button and not me? Is it new? Do I have a virus? etc.")

Disabling the control provides the most consistent and helpful feedback for fine grained user permissions. It gives a good overview over the functions of the platform which one might be eager to acchieve (especially if it's a meritocracy-driven reputation-based one). If there're a lot of controls the hint why the control is deactivated and what one needs to do to gain the associated permissions should be formulated more abstract and can refer to the next level permissions or refer to an overview of permissions.

In some situations it's fine to hide the controls in genereal, e.g. for actions which require admin permissions which require the user to be an expert of the system anyway. The UI for admins can thus be much more stuffed.