Goal:
Dental Clinics need to have control over security by assigning or restricting permission to their staff for specific areas and tasks on Curve Hero (Curve Dental cloud software).
*This material is confidential and owned by Curve Dental
Roles Management
Curve Dental
My Role:
Product Design, UX Design, UI Design.
Problem to Solve:
Dental Clinics or practices operate differently from each other. Some clinics are small, with fewer staff roles, and bigger clinics have multiple staff roles, with high staff rotation, shifts, and more specific tasks. Creating a product to fit all is the problem to solve.
Stakeholders direction:
-
Create a design for clinical and administrative staff roles and the availability to select permissions at a granular level to create their costume roles.
-
Each clinic staff member can be assigned a role and modify the permission as needed by the clinic Administrator.
-
Create "Default Main " roles to give default access to clinics new to our software, don't need granular permission for their operations and are ready to assign.
Process:
Site map
Creating a site map helps me understand each product section's elements and functionality. At the same time, all stakeholders are on the same understanding. After reading the requirements and discovery phase, I created this site map.
Goal.
Communicate the two different types of Roles under Roles Management and their behaviours:
-
Default Roles - Curve Dental gives these roles to "New Customers" or "Existing Customers" who don't customize their staff permissions.
-
Custom Roles - The clinic's administrators can create and customize these roles with a granular permission level. Each role and its permissions must be intuitive to set up.
The blue font was the behaviours I needed to clarify with the stakeholders
User flow
After I had cleared the behaviour and functionality of each type of role, I created the user flow.
Goal.
Communicate each role type user flow with the product team (stakeholders, developers, and QA).
Creating this user flow helped the team understand WHY there are two types of roles and WHAT the users can or can’t do.
QA was very thankful for this flow. It was easier to create their test cases.
Wireframes
Challenge:
This part of the design process was challenging, as the team lead already had a design solution in his mind. This project started a few years before I joined the company. It paused until stakeholders had better requirements. After understanding the complexity of selecting roles, assigning permission, and assigning staff to each role, the solution needed to be very simple.
The direction was to create a card (material component) per role and add the permissions. A list approach would be better, allowing users to scroll and search to find the right roles and match the correct permissions. I created the two solutions (card and list) in wireframes to better visualize the product with the two possible solutions to define the best one.
The following image shows the wireframe with the "cards" option—the initial pre-solution.
We understood it took a lot of work to visualize the large number of roles and permissions. As the custom roles are unknown, how many will the users create? So far, the requirements defined seven default roles for main clinic activities and tasks.
The following image shows the wireframe with the "list" option—the newly proposed solution.
List 1. Default Roles List
-
Default roles list - Defined by the Business Analyst.
-
User assigned to each role - The role assignment happens on the directory staff page in Administration.
-
Duplicate a "Default Role" to give the user a starting point and customize as needed with a customer name.
List 2. Custom Roles List
-
Users (clinics) can create their roles. Custom roles list.
-
Select permissions from a permissions list.
-
User assigned to each role - The role assignment happens on the directory staff page in Administration.
-
Edit role and its permissions.
-
Delete the role with a warning if any staff has it assigned.
Permissions List:
I created a new wireframe after learning how Curve Hero sections categorized the Permissions, including category (Curve Hero section), name of the permission, and description.
Final Solution:
After a team discussion, the "List" option is the direction to go. The new approach was:
-
One list for both roles is "Default and Custom."
-
Differentiate these two types from each other so users understand the difference.
-
Permission list next so users can match in one screen Role and Permission.
Prototypes
With the new direction, I started the process of prototyping.
The first task was to define the section in Administration to place the page:
-
The User Management section assigns roles to the staff settings.
A fully functional prototype was created with some added functionalities:
-
Besides the two types of role lists, the ability to activate and inactivate roles the clinic or practices are not using. Eg. They have accountants as 3rd party.
-
Empty states
Add role or Edit role take the user to the same layout page.
Final Solution:
These prototypes felt complete, but this solution was increasing the development time. Based on this, I created a simplified version with the final features. This simplification task took me one week. The developer and I had to communicate to make it happen in one week.
