Overview
This project was for KPA’s Vera Suite platform, which helps auto dealers maintain cultures of safety, streamline operations, and manage risk. It aims to serve the needs of EHS, HR, and F&I managers, and offers comprehensive dealership workforce and workplace compliance solutions.
While Vera Suite is marketed as an All-In-One EHS and Auto Dealership Compliance Software Platform, that wasn’t always the case. Vera Suite is actually the combination of what used to be two separate applications, myKPAonline and KPA HRM, an Environmental Health and Safety compliance application, and Human Resource Management application respectively.
Uniting these applications was accomplished over a series of projects, one of which was the Roles & Permissions project presented here. The goal of the project was to improve and simplify the user experience by developing a single role and permission management system to replace the two systems used by the legacy applications.
My role in this project was UX designer, working alongside a Business Analyst and a Product Manager.
The Challenge
While many steps had been taken to unify the myKPAonline and KPA HRM applications into the Vera Suite platform, such as implementing SSO, common user creation, and a reskin to create a common look and feel, clients with both EHS and HR products were still encountering usability issues due to some areas of the platform that still used the legacy systems. One such area was Roles and Permissions, which was actually two separate roles and permissions systems, each of which worked very differently and offered different experiences. In order to present Vera Suite as one unified platform, the issue of the two permission systems needed to be addressed.
In the long term, the organization wanted to build a single role system that would replace the two existing role systems and manage access to all areas of the platform, but the development team estimated that to be a six month project, so we needed to explore a phased approach, and what we could accomplish in the short term.
The Process
Empathize
The target audience for this project was Client Administrators with both the EHS and HR products. They usually have roles such as Service Managers, Safety Directors, and HR Administrators. Two such personas are shown in part below.
I started my process by interviewing 6 users with those roles. Here are some quotes from those sessions:
“I didn’t know that my employees couldn’t see the Manage Employees tab until I called Support. I was going to have them deactivate all my employees because I didn’t want any PII showing.”
-
“We only use the Admin role and Employee role because I know Employee just gives them access to training, and Admin gives access to everything. I don’t know what the other roles do.”
-
“I like that I can do custom permissions for HR, but I didn’t see a way to do that for EHS.”
-
Define
Based on user interviews, customer feedback collected through our feedback portal, and input from our Support team, I found that:
1. Users were confused that one application had two sets of roles, each of which worked differently.
2. Users did not understand what each of the roles did and everything they granted access to.
3. Users were divided on which existing role system they preferred. Some users liked the increased functionality provided by the HR system, which let them customize the permissions provided by each role. Many of those users wanted additional functionality to let them create additional roles with custom permission sets. Other users preferred the set permissions provided by the EHS role system, and sited situations where employees had unintentionally been given more or less permissions than they should have been. Some of this group indicated that they didn’t use all of the roles, and thought reducing the number of roles would make it easier to use.
2. Users did not understand what each of the roles did and everything they granted access to.
3. Users were divided on which existing role system they preferred. Some users liked the increased functionality provided by the HR system, which let them customize the permissions provided by each role. Many of those users wanted additional functionality to let them create additional roles with custom permission sets. Other users preferred the set permissions provided by the EHS role system, and sited situations where employees had unintentionally been given more or less permissions than they should have been. Some of this group indicated that they didn’t use all of the roles, and thought reducing the number of roles would make it easier to use.
I also conducted research to define current role functionality, including which permissions each had, and what each permission did.
Ideate
Next, I facilitated a group brainstorming session. We first reviewed my findings, then started to brainstorm using the “How might we…” method. Next, we did a few sketching sessions, then finished if off with a dot vote.
How might we create a more consistent role system experience for the user?
-
How might we better communicate to the user what the roles are and the access they grant?
-
How might we simplify the roles for the average user, but still provide the customization our power users want?
-
Prototype, Test, Prototype, Test
During the prototype process, first I created user flows and wireframes based of the the ideas generated during brainstorming. I created wireframes for the top two ideas for each functional area. I reviewed these options with stakeholders and tested with 5 internal users to decide which design direction to take each functional area.
These user flows helped the team understand how various user types would access the new content, and how the experience differed by type of user.
These wireframes show two potential options for reorganizing the Edit Employee page to accommodate a new Roles and Permissions section.
These wireframes represent two potential options for providing users with role information, including the permissions they grant, and detailed descriptions of those permissions.
The image on the left shows the existing UI for assigning roles. The image on the right shows a proposed UI, where descriptions of each role are provided.
Users preferred the matrix with indicators to the the table approach. They preferred the side by side comparison of roles and the quick overview it provided as opposed to having to select a role to view a table that included descriptions.
While changing the functionality of the roles was out of scope for the moment, I explored how we might offer role customization in later phases.
Results
Prior to this project, support tickets recorded as related to roles/permissions/access (excluding login related issues) accounted for, on average, 18% of tickets. In the months following release, that percentage declined to an average of 10% at the end of 2021. Additionally, client feedback was very positive. Here are some quotes from users:
“This is great! It's a lot easier to see how each role compares to each other. I think I'm going to update some of my managers to the mid-level role now that I know exactly what they'll see.”
-
“I like how the new Roles tab looks and that I can click the permission to see what exactly it does.”
-
“Nice. Looking forward to being able to edit EHS permissions.”
-
Although users have an increased understanding of how the permissions work and the access they provide, at this time Vera Suite still uses separate role systems for EHS and HR products. For this reason, and similar issues around the platform's LMSs and DMSs, some joint clients are still unhappy with the differing experiences provided in these areas. In order to address these concerns, the organization will still need to invest significant resources to provide clients with a single, unified role management system.
I also hope to revisit the interfaces created in this project to address some usability issues I uncovered with usage data gathered after release. For example, using our heatmapping tool, I discovered that some users expect the dots in the role matrix (shown below) to be clickable. I'd like to address this by opening the permission description modal when the row is clicked.
This issue illustrates a a confusing part of the UI for some users who expect the dots to be clickable.