Building permissions for Crew's enterprise users

I designed a permission system for Crew’s enterprise product, allowing features to be accessed in the appropriate scope for each user.

Enterprise usage was limited by the lack of permission and roles

Command Center gives company leaders insight into how their teams are using Crew. Its typical user is someone who oversees multiple teams and needs one place to manage them. Over the years, Crew was selling into large enterprises, but Command Center usage remained low. We discovered two reasons for this:
‍
There was no way to invite coworkers
Users couldn't invite coworkers to join Command Center. Instead, everyone had to be manually provisioned by Crew account managers.
‍
There was no way to restrict features
Command Center includes powerful features, such as the ability to post company-wide announcements. Our customers were reluctant to grant Command Center access widely unless those features could be restricted.

Roles and permissions needed to reflect existing front-line hierarchies

For initial inspiration, I looked at other enterprise products, including Google Team Drive, Asana, Zeplin, and Slack. This helped me get a sense of existing paradigms for handling permissions. I also researched different flavors of access models, including role-based access models and rule-based access models.

Inspirational screenshots from Zeplin, Slack, and Asana

Clearly many types of access models exist, but which one would meet our customers' needs? The next step in the design process was talking to customers and their Crew account managers. Through these conversations, I was able to identify three main use cases for permissions:

These use cases gave me a clear idea of the roles and permissions that were needed. I was able to start mapping out a flow for how our enterprise customers might add new people to Command Center.

Mapping out the flow to add a new user to Command Center

I explored different flows, trying to break up the steps and make them digestible for our users. One of the challenges was providing enough context for users without overloading them with information that they might subsequently ignore.

Explorations of UI for setting a user's permissions

I also had to consider how Command Center would appear for someone with limited access. This meant systematically evaluating each page on Command Center and designing the "limited" version of it.

Explorations of the UI for displaying a user's permissions

Finally, I created a clickable prototype that I showed to three enterprise customers, which helped me validate key flows and collect general feedback.

We built a flexible solution so users could have different permissions for each of their teams

The final design was implemented over the course of 2 months with the help of one backend and two web engineers. It included the following features:

‍Settings page
We built a new page that shows everyone with a Command Center account. New users are added and configured from this page.

‍Roles
Individuals in Command Center can be admins or users. Admins have complete access to all features, whereas users have variable access depending on how their admins set them up. I had considered other types of roles (a "super-admin" role, for instance) but ultimately opted for a simpler solution for version one.

‍Access
Admins can restrict a user to only have access to certain teams on Command Center. This feature was designed for middle managers, who only need (and want) to see information relevant to their teams.

‍Permissions
By default, users are granted all “read” permissions on Command Center. Additional “write” permissions must be explicitly granted by an admin.

Interface for restricted actions
‍‍The interface is disabled when users don't have permission to perform an action. A tooltip appears upon hover to help them understand what's happening.

Roles and permissions opened up new enterprise opportunities

We released Command Center user roles and permissions in March 2019. Since then, we've seen a steady number of new users added to Command Center each month. Customers have had generally positive things to say:

We've seen validation in other ways as well. In April, Crew closed its biggest deal yet. Our new customer needed operators to be configured in Command Center in a very specific way. Fortunately, we had built a system flexible enough to accommodate their needs – with almost no changes needed.