It was a pleasure to work with you, as you and your team made this process a more pleasant experience for our team and the participants.
Karen Perry
While working on a UX strategy for a large enterprise data portal, we recently had an interested conversation with some developers around, based upon permissions, when to show things, when to hide things and when to show things as disabled or “greyed out.”
Of the wonders of Enterprise UX! Based upon the user role, as well as the associated security settings, some users will have access to some features, while others will have access to different features, or more features or less features. Some of these features are dependent upon the settings choices made by the actual users, and some are dependent on choices/permission made by the system administrator.
After considerable discussion, here are some of the guidelines we came up with:
1) When there is no way that an end user will EVER have access to a feature or function, do not show it to them! (This is mostly for system admin features/functions that most end users will not need: e.g. Add/Remove users, etc.)
2) When an end user does have has the permissions to do something, but they have not set some other setting or selection that makes it active, use a “greyed out” approach. This informs the user that the feature is available to them, but that THEY need to do something in order to activate it. Extra credit for a UX that tells them specifically what they need to do!
What about the case when the user does NOT have the permission to do something, and they know that it is an option, but they will need someone else to change a setting for them – again like system admin features like adding a user to a group? Well, like in most situations, it depends. We would like to see a disabled feature with some type of link or “Call to Action” that allows them to request access to the feature or function.