Custom Roles & Permissions

New Feature

Goal

Allows flexible permissions and custom roles in the app

Methods

Survey, card sort, UI

Contributions

Survey and communication with internal teams
Card sort design and data analysis
Resolved limitations and conflicts.

Overview

The current roles and permissions limited the flexibility that customers have in the app. Some users end up getting too many permissions and some not enough.

Custom roles offers:

Ability to name a custom role to fit a practice's workflow
Ability to limit and give access to certain permissions
Improved HIPPA compliance
Greater practice flexibility

The Process

Overview

Roles and permissions touches every part of the app. Tackling this project included the following:

App and permission mapping
Collaboration between engineering and design
Role and permission grouping
Survey and card sort

1.0 App & Permission Mapping

Discovery

I worked with engineering to map out every part of the app and what roles and permissions were currently associated with each area.

I worked with our data team to take an inventory of the most frequently used roles.

2.0 Engineering & Design Collaboration

Design Sprint Session

I hosted a design sprint session with my engineering team to generate ideas and identify potential problems with the project.

3.0 Role & Permission Grouping

Discovery Validation

For the first round of UI design I quickly realized that there were far too many permissions for a user to easily manage. This meant that I needed to sort them into logical groups that would allow users maximum flexibility for permissions while still reducing the cognitive load associated with creating a new role.

Google Survey

I sent a survey to our customer implementation team and reached out for additional feedback to figure out what permissions customers wanted to be able to customize.

Open Card Sort

I created a card sort in Maze where each card represented a certain permission. Users were asked to organize the permissions into sets that represented certain roles and then to name those roles. Based on these groupings I was able to create sets of permissions that had a higher likelihood of being paired together. There were some features such as chat that although used frequently, were requested as a separate permission.

Limits & Challenges

Limitations

Starting small- The app consists of user roles and practice roles. For this iteration we only focused on practice roles. Some practice roles could not be paired with other user roles, or it would break the system. I had to limit the custom practice roles to certain user roles.
Considering current customers- I had to ensure that customers who were using our current roles would not be effected by any changes. This meant slowly phasing out the current roles while introducing the custom roles.
Lack of engineering resources- Due to a lack of engineering resources this project was put on the back burner.

Challenges

Size & Scope- Because this feature effected every customer and touched every part of the app it was a challenge to create an accurate inventory and map current permission in the UI.

Results &
Reflections

Results

When implemented this feature will offer massive benefits to the users. Instead of being able to choose from x practice roles, they will be able to configure x unique roles to fit their workflow.
This project gave the the opportunity to become very familiar with each part of the app. My innovative use of a card sort helped me to create an effective grouping of permissions that would offer flexibility and easy of use.

I know, the UI is ugly

Because this is an internal tool and the company was a fast-paced startup, the UI for this part of the app was not prioritized. Here is a mockup I was working on for how this portion of the app could look in the future.