Role-Based Access Control UX Research
Utilizing UX research to unlock user insights and guide the creation of a role-based access control feature
Partial Scope
Security and Access Control
PROJECT TYPE
8 Engineers
1 Product Manager
1 Product Designer
THE TEAM
User Research
Project Management
MY ROLE
Figma / Figjam
Jira
Zoom
Google Suite
TOOLS
DURATION
3 Months (Q4 2022)
Overview
How might we better our understanding of customers’ interactions with the Esper platform in order to provide customized support that meets their unique roles and responsibilities?
Role-based access control (RBAC) is a feature that allows administrator users to manage the level of access that their organization members have on a platform. This is important for administrator users because information can be sensitive and not necessary for all members to have access to.
In Q4 2022, I conducted UX research alongside my manager to better understand how and when users utilize Esper in order to revamp the RBAC feature framework. It was a known issue that Esper’s existing RBAC roles did not suit its customers. Our research findings validated two roles that we ideated at the beginning of the project, and uncovered three new roles.
The Problem
Esper’s existing RBAC framework offered four roles with differing levels of access, but almost 100% of users were using the role with the highest level of access. At the same time, users were frustrated that this role had too much access for certain individuals of their organization.
The Solution
My manager and I created and executed a UX research plan that uncovered what roles and functions Esper’s users need and how those tasks fit into a customer’s holistic device lifecycle.
Context
As our team was beginning the project, company-wide layoffs and organizational changes occurred, leaving the project without a dedicated PM or engineering team.
With 12% of Esper’s workforce being cut, teams were getting moved around and confusion ensued regarding who was working on what. As a result, the RBAC project got delayed by a few weeks while figuring out who would be dedicated to the project.
During this time, I had two main takeaways:
Project managing is key to continuous project momentum. Even without a dedicated team, I still had ownership for the end RBAC user experience and design delivery. The RBAC project timeline did not change because of layoffs, and so I had to double down to understand what portions of the project I could do without a dedicated team and get it done. As a result, I created a plan for UX research and explored some early design ideas.
Getting buy-in from stakeholders is the name of the game. Esper had a dedicated team of Customer Success Managers (CSMs), who had direct customer contact. While this benefitted the design team through anecdotes that we’d receive about customer frustrations, it also created a gatekeeping sort of culture, where CSMs were wary of designers having direct customer contact because they needed to maintain a fine balance between talking with customers enough and not contacting them too much. I needed to gain buy-in from CSMs to allow me to collaborate and chat with customers directly. This was incredibly important because in order to create new roles and responsibilities that our users needed, I had to understand their business lifecycle as it related to using Esper and gain knowledge about each organization member who used Esper. This is information that CSMs did not know about in detail, so I utilized empathy and negotiation o come to a compromise that allowed me to directly interview customers.
This is just the tip of the iceberg! If you’re interested in learning about my journey from here to my research results, give me a shout at katethanan.13@gmail.com.
Research Results
I interviewed six customers, validated their dissatisfaction with existing roles, and uncovered patterns in the roles and responsibilities they needed.
After each interview, I parsed out quotes, created diagrams of each role and their responsibilities, and mapped out flowcharts of current and ideal state access hierarchy.
After just three interviews, we could already see similar roles and responsibilities that were being talked about again and again.
Below is an example of an analysis that I organized for each customer.
Impacts
The research results validated two roles that the team hypothesized at the start of the project and uncovered three new roles.
Going into the project, our team had an idea of a couple of roles that customers would want, due to the anecdotes that we’d heard from our CSM team. What we did not know, was how a customer’s entire device lifecycle worked, and how many roles were involved in this process and what functions these roles needed. The UX research conducted helped to uncover these insights, and as a result, we found patterns of three new roles that customers needed.
Unfortunately, I was not able to complete the design of this project due to a second round of company-wide layoffs. Even so, my research and analysis created a strong foundation for the future RBAC framework.
Reflections
Some lessons that I’d take for my next project…
Take a broad approach to asking questions.
Despite the project's specific focus on RBAC, I discovered that adopting a broader approach to my questioning yielded more valuable insights. By having the flexibility to selectively delve deeper into certain aspects, I could pinpoint essential information that I needed from users, enabling a more thorough understanding of their needs.
Be flexible and proactive.
To adapt to Esper’s layoff situation, I took the initiative to define my role, identify feasible tasks, and develop a user research plan that could be executed despite the confusion surrounding the project. This proactive approach not only prepared me to begin design work when project direction became clear but also laid a strong foundation for the team to understand the necessary roles and chart our path forward.