Design Considerations for User Roles

We've provided the following user role UI design guidelines to help you make your integration dynamic based on the privileges of the current user. These guidelines discuss how to treat various UI elements if the current user does not have access to the functionality represented by these elements.

Identify the current user's privileges

Make a Get call to the User Privileges endpoint to retrieve the list of privileges for the current user. Reference them whenever the user transitions to a different screen, tab, or other UI element to customize its appearance and show only functionality that the user can access. It's usually best to store user privileges per session. That way, if a user's permissions change, they can log out and log back into your product to obtain changed functionality.

Fundamental design philosophies

1. When possible, set user expectations. If that doesn't make sense for your product, make decisions to meet existing expectations, and prevent users from wasting time, money, and energy.
2. Avoid unnecessary interactions, such as displaying disabled buttons. Showing unavailable actions teaches the user to ignore UI components.
3. When the optimal experience requires removing significant elements in your UI, alert the user about their limitations.

When to modify an action

If the user's privileges indicate that they can perform some, but not all of the functions available in your product, it's best to modify what is available to them. This is often the most laborious option, but also provides the best user experience.

For example, if the user's privileges indicate that they have contacts:read access, but not contacts:write access, you could display a user's contacts to them, and a sync button that would normally modify contacts within both Constant Contact and your database might only pull updates from us and refresh contact tracking data, like sends, opens and clicks.

When to remove an action 

When modification is not feasible, the next best step is to remove a restricted action from the UI, in order to save the user the effort of interpreting the restriction, especially if it’s an action they didn’t expect to have anyway. Showing unusable actions will teach users to ignore portions of the UI.

The greatest risks in removing expected functions are that your user:

• Spends significant time searching for it
• Reaches out to the Account Owner
• Calls Customer Support

This scenario is very problematic: the user’s expectations have not been met, which leads them to waste time and energy. This is a mistake they will only make once, but it is likely to annoy and frustrate the customer. To prevent this hassle for both your customer and your support team, you must educate the user upfront about what they can and can’t do so that they don’t run into any surprises.

You might choose to display a flag to the user upon retrieving their user privileges from us, after you check to see if they have all of the privileges required to take full advantage of your product's integration. You could display that flag in a corner, telling the user that their role has limited functionality and to contact the primary Constant Contact accountholder if they need access to something they don't have.

When to disable functionality

Disabling an action (with or without a tooltip) is the equivalent of installing a non-working light switch in a home. If you want to turn on the light and don’t see a switch at all, you’re going to have a problem. Still, you’re going to prefer a working light switch to a non-working one. Things that users are likely to expect, but not likely to remember, should be displayed to them where they are likely to expect it. Users might expect something but forget why it’s a restriction if it’s something that they don’t need often, or if it’s associated with an action they can perform. For example, they may want to delete a contact, but only have the ability to create or edit one. 

Tooltips should only be provided for disabled, expected actions. Disabled links that are inherently informative, such as metrics and reports, do not need tooltips. 

Specific design recommendations

The following design recommendations are categorized by context.

Batch Edit

Batch edit involves selecting multiple options through checkboxes, and applying some sort of action to all selected items simultaneously. In our products, every incidence of Batch Edit is to used solely for the intent of Delete/Remove/Restore.

The recommendation for restricting Batch Edit patterns is to remove the checkboxes. The user will see, but not be able to modify, the records that are displayed.

Button/Link

Buttons and links are probably the most common design element within our products. It's best to label the button or link depending on its action, not its context. The best user interfaces will omit buttons or actions that are unavailable, and change button labels if the action depends on the user's privileges. For example, change "Update Contacts" to "View Contacts" for a user that can see but not edit their contacts, and remove "Edit" links next to a contact.

Sequential

Sequential design patterns are those in which a step-by-step process is displayed to users. The benefit of this design is a better understanding of the amount of effort involved in completing a specific task. It also helps users prepare to perform specific acts, such as identifying recipient lists or creating content. If users are restricted from these sections, there is no need to prepare for the time or tasks involved in completing them.

Sequential design contexts should be modified to reflect the actual steps involved for the user’s specific flow. Restricted steps should be removed, while accessible steps remain. Any sequential design patterns that consist of one accessible step should be removed altogether.

Tabs

Tabs are similar to the Sequential context in that information and actions are organized into multiple, high-level categories. The difference is that exposure of each section is not required for tabs.

Tabs that contain only restricted content should be removed completely. For tabs that contain some restricted content, consider the possibility of moving the available content to other tabs and updating tab labels to more accurately describe content.

Action Menus

The Actions Menu is a tool of convenience—a design pattern to surface commonly used actions. If an Action item is restricted, its presence on the drop down menu offers no convenience. If all action items are restricted, the entire menu is useless and distracting.

Restricted Action Menu items should be removed. The only exception to this is if the Action Menu offers functionality unavailable anywhere else in the product and that functionality is expected but irregularly used. If all but one Action Menu item is restricted, the allowed functionality should be displayed as a major button or link.

Text

Text-based restrictions refer to information or content that is sensitive, or refers to actions that are restricted to the user.

Text content including information restricted for security reasons (such as payment or contacts information) should be removed. Text content referring to restricted actions should be modified to reflect the actual user experience.

Unauthorized

Unauthorized pages are pages that should be protected, should the user manipulate the URL. All entries to these pages should be hidden from the user.