FORMA.AI | 2022
Permissions Configurator
RESPONSIBILITIES
ROLE AND TEAM
USERS
CONTEXT AND PROBLEM
Directly assigning roles and it's associated permissions to each user was inefficient
Forma.ai is a platform that provides insights into sales compensation and performance. Previously, permissions were configured through an external interface called Django. Admins had to manually assign roles to users and configures the associated permissions. As the app complexity increases, directly assigning roles to each user becomes difficult to manage.
SOLUTION
Introduce RBAC model to improve permission management and to use internally in the app
To address this problem, Permissions Configurator introduces an additional layer of “groups” and allows configuration within the app. It aims to improve the current process of configuring permissions with Role-Based Access Control (RBAC). RBAC allows organizations to assign varying levels of access to employees based on their roles and responsibilities, ensuring data security and limiting access to information and actions relevant to their jobs.
IMPACT
Simplifies management of permissions and provides users with more granular control
Users can assign groups to individuals and define the roles and associated permissions within each group. This new approach simplifies the management of permissions and provides more granular control over user access. It makes permissions management more efficient, reducing the need for developer involvement, and allow for testing of user permissions.
The first release of the configurator required the ability to create groups and roles. Users and permissions were non-editable to start with, using predefined values. The ability to create users and permissions were for a future phase.
DISCOVERY
Research and interviews conducted defined the core user flow and requirements
Visual research was conducted to understand how permissions systems worked in other products. This research, along with user interviews, helped define the core user flows and requirements.
Interviews with the internal team informed us the ways they currently manage permissions – mainly assigning or removing groups to users individually. We also got feedback on abilities they think would be helpful, such as batch assigning roles to users.
Upon introducing the new model, we realized there was some confusion around the groups vs. roles and is something we need to make sure is clear in this feature.
IDEATION
How might we design to ensure users understands the impacts of managing groups and permissions for users?
A design challenge that came up was designing in a way that the user understood the context and impact of their actions of assigning or removing users from groups. The additional layer of groups also increases the complexity of knowing what permissions make up a role, and what roles make up a group. There are risks if a user assigns groups to the wrong users.
DESIGN IDEALS
1. Clear and intuitive user flows for assigning groups, managing roles, and configuring permissions.
2. Flexibility to accommodate future features such as object-level permissions and user creation.
Establishing some key design goals helped shaped explorations of the experience. After some ideation, I narrowed down to two different flows, each with it’s own pros and cons to be considered.
OPTION 1
Using separate pages for users, groups and roles
The first flow had users, groups, and roles all managed in separate pages. It used a common pattern in the app of navigating from a list in a table to a detailed page. It reinforced the concept of permissions being tied to one or more roles, and roles tied to one or more groups. Some cons with this is the user may lose context because of the many pages and lose context of what permissions make a role when looking at a groups page.
OPTION 2
Compiling list of groups and details of a group in one view
Another direction explored was maximizing the space and giving more visibility to the list of groups and the users and roles that belong to them. This brings the context knowledge to the user of what other groups they have. It also makes it easier to switch between them. Some cons are that it can get cluttered, especially when there is a long list of groups.
USER FEEDBACK
Tested two directions with internal users
To inform us on which direction to take, feedback was collected on both flows. We tested with both Customer Ops and developers. A mix of people liked option 1 with having the groups and roles on individual pages, while others liked option 2 of a compiled view.
We identified some areas of improvement based on feedback.
- Users had trouble adding a permission into role, while they are in the groups page
- Confusion on the permissions page on the content and implications of them
CHANGES
Updated flows and last minute changes on permissions page
While collaborating with the PM and developer to see if it was feasible, we discovered that the permissions were a lot more complex than we thought. Permissions could be nested, as well as the actions for each permissions did not fit neatly in the categories we anticipated. The result was going back to a picker design pattern that was efficient and accommodated many permissions and had space for a description.
FINAL SCREENS
Users and Groups
The end result had groups and roles on separate screens, as well as space for permissions.
FINAL SCREENS
Roles and Permissions
