This case study is about my journey of exploring and re-designing Roles & Permissions for corporate SaaS. Our SaaS basically takes care of the complete life cycle of construction projects (from planning to execution stage).
Users' personas for our SaaS are from clerk level employees to Managers and board members of the company. It was vital for us to design it in such a way so that an employee who use our SaaS on regular basis and a manager who use it just to check on reports and invoice have a smooth and hassle-free experience.
To redefine and re-design intuitive flow of roles & permissions for the BuildSupply dashboard.
Before we get started, I would like to thank everyone in this team where we have worked together so hard for around 2 months. The primary requirements were shared by Sarit Sethi (COO)on the whiteboard. Big thanks to Naveen Jayavel who is head of the customer success team worked on this along with me and was the best source of requirement coming directly from our clients. Also, I would like to thanks the dev team for entertaining their valuable point of view and feedbacks.
The revised Role and Permissions module needs to be self-reliant, not as complex as the current one. It needs to have the level/hierarchy based role and permission system and also have value-driven workflows.
Below are major drawbacks :
- There was no option to assign different permissions to users with the same roles.
- Disconnectivity between the creation of roles and their respective permission.
- Lack of flexibility in terms of changing the permissions of a single user with a certain role without affecting other users with the same role.
- It also failed to address the paradigm of different customers having different hierarchies which in turn affected the roles and permissions structure.
- There is also a dependency from our side since the module is complex and rather difficult to understand.
Since our customer success team directly deals with our users on a daily basis, I asked them what are the challenges currently faced by our client and what are their expectations.
I conducted informal interviews with around 3–4 customer success team members. Questions were pretty much the same and I found that requirements from our different clients were also the same and standard to business.
Software like Farvsison and Kettera is our competitor to some extent So, it was necessary to go through them and have a basic understanding of how they are handling roles & permission on their platform.
I have also gone through some video on how companies like SAP and Oracle handles the same and what approaches are universally accepted. Introducing new approaches in a platform like ours on which users are not as tech-savvy can lead to more problems instead of helping to solve them.
Through our primary and secondary research, we finalized the features we want to have in our system and by sketching low fidelity wireframes we created a basic information architecture for same.
We decided to add some extra features like the Departmental segregation of roles and users. We also introduced the concept of defining permission on multi-levels, for example, users can define permission on the global level, on the project level, and on user level too.
Benefits Of New Design Approach
- Single navigation for Roles and Permissions
In our current system roles and permissions both have a separate navigational route. But if we see closely both are interrelated and fall under the same Taxonomy. By having the same
navigation for both roles & permissions through single navigation makes the intent clear for the user and reduces cognitive load.
- The concept of Global Roles, Project Roles, and User level Roles
Our current system has single level roles and permission concept. This means any change made to permission will reflect for all users. There is no filtering of the same.
Let’s assume a user Alex is assigned the role of Cost Analyst. Now, if admin wants to give some additional permissions to Alex. Admin either will have to create a new role and then assign it to Alex or else all other users who are associated with the Cost Analyst role will have access to the same permissions given to Alex.
Let’s consider another scenario. If Admin wants to assign the same role to a user in multiple projects with minor changes in permissions. In this case, also Admin will have to create multiple duplicates of the same role. This creates redundancy in the system.
To overcome these issues concept of Global Roles, Project Roles, and User level Roles introduced. Through this multilevel permissions model, user experience is enhanced and at the same time, the true intent of roles and permission is achieved.
- Integrated Roles & Permissions
Roles and Permissions are now much more integrated than before. The admin who wants to create a new role with some set of permissions will now have to define permissions at the time of role creation only.
Before in our system, once the role is created there were no indications of defining permission and was not any direct linkage of the same.
Lack of affordance confuses the user. This issue is tackled within new designs by integrating them closely.
- Departmental Tags Added
Information architecture (IA) focuses on organizing, structuring, and labeling content in an effective and sustainable way. The goal is to help users find information and complete tasks. Admin can now create different departments and tag roles with them. This will also allow users to segregate roles and users on the basis of department tags. This specific feature is added to take care need of admin-level users. Admin can easily find out the number of users within a department and roles assigned to them, which was not an option before.
- Introduced Micro-Interactions On CTAs
Interactions focus on creating engaging interfaces with well thought out behaviors. Introducing interactions on call to action is a very basic thing but comes out very affecting and increase user engagement with the system.
Micro — Interactions encourage users to interact with the product and make the system intuitive. For example — a user hovers over a CTA and it gets highlighted. These small interactions embark on encouragement and add livingness to the system.
- Card View Implemented
Cards organize information into chunks of content, and users appreciate chunked content because it aids for scannability. It helps avoid walls of text, which can appear intimidating or time-consuming and allows users to dive deep into their interests quicker.
Cards divide content into meaningful sections, similar to the way text paragraphs group sentences into distinct sections. They can gather various pieces of information to form one coherent piece of content.
Admin can now filter users on the basis of roles as well as projects also. Roles can also be filtered on the basis of department tags assigned to them. Filtering increases the findability of information the user is looking for and enhances the usability of the system.
- Assign N Number Of Users With A Role
Admin can now assign n number of users to a role. This type of flexibility and advantage was not in the system before. Admin either can multiple users to a role from the project roles tab or can assign a role to a user from the project users tab directly.
- Sorted View For Assignment Of BOQ and Packages
By importing roles and users directly at estimate level, the user can now ripe multiple benefits from it. It reduces multiple tractions.
Admin now does not have to select user, role, and estimate. BOQ and Packages can now be managed directly from the project users' page. There is a button to manage BOQ and Packages on the user card itself. Admin just has to select BOQ and packages of which users need to have access.
- User Login Status
Users can now monitor the login status of other team members on the project users' card list itself. If a user has not signed up in the system but onboarding mail is already sent him/her, status for the same will be shown on that particular user’s card. This adds more transparency within the system.
- Side Menu Icons
To maintain consistency within the system all icons of side menu are kept line icons only. Before some of the icons were filled icons and some others were line icons with multiple border widths.
Challenges and Learnings
The biggest challenge was not having a well-defined requirement and scope of work.
In the absence of PRD(Project requirement document) and BRD(Business requirement document) words of Naveen and his earlier experiences with the client were almost Bible to us.
One of the key learning is to take feedback from an early stage and include multiple disciplinary stakeholders in the feedback meeting.
There was a time when from our end we finalized the whole thing and presented them to our whole team just to give them an overview. One of the members from the dev team advised us to add another layer of hierarchy in permissions and it struck us like a lightning bolt. Since we were at closing this requirement, we realized introducing dev team members during the early stage of ideation would have been a better choice. Since all the points shared by dev team were legit So, we incorporated them too.