We also conducted stakeholder interviews with tech leads and other stakeholders across the business to get a better understanding of the technical needs and hear any concerns regarding the project. Myself and my product manager led interviews, constantly asking “why?”. We learned a few things: 

• The permissions logic was a fundamental area of the platform which most of our functionality relied on, and it was also the oldest piece of code.

• The permissions UX was a severe pain point for our data users, often resulting in help desk tickets that needed to be triaged by our client success team on a weekly basis. 

• Different technical stakeholders had differing and strong opinions on the best approach for this work.

We also conducted an ideation workshop with engineers who were very familiar with the permissions experience, and who expressed lots of ideas for improvement. While this workshop would have been more useful to do after a round of user research, it was successful in boosting morale and creating excitement for this work amongst our engineers.

User research

We took all of these learnings and decided to conduct internal user interviews with members of our client success team who frequently worked with users throughout their permissions experience, from the point of onboarding and beyond. We also spoke to a few power users who frequently worked with permissions on the platform and created their own workarounds to functionality pain points. In all, we spoke to about 10 users across two weeks. I created the user interview guide, led the interviews, and worked with my product manager to synthesize insights and outline next steps.

Findings & outcomes

From our research we realized that there were three main user personas who use the permissions experience on the platform: 

1. Organization admins 

2. Team admins 

3. Standard users 

Organization admins oversee their organizations at the highest level and spend the least amount of time on the platform. They need to understand the organization’s permissions structure at a bird’s eye view to ensure their data is secure. Team admins work more frequently on the platform, managing the permission structure for their team and ensuring collaboration is possible within and across teams in the organization. Standard admins work in the platform as frequently as team admins, but they work on more granular data tasks and require the right level of permissions at the task-level. 

I also realized that permissions comes down to two core needs across user personas: visibility and control. By solving these needs we’d resolve significant pain points for our users and reduce the burden on our client success team. However, I knew that we wouldn’t be able to solve both of these needs at the same time, or even in a short amount of time. Because we didn’t have a Director of Product Development at the time, I knew we really needed to champion the idea of taking a strategic and iterative approach to this work. 

I created a data visualization to help communicate the complexity of the problem space and to inspire our tech leads to align on a strategic approach. Ultimately, this helped us gain alignment on solving for “visibility” as the first step. 

Our user personas were also a key piece of this work, helping the most in our conversations with tech leads. We were able to tie individual goals back to the real problems we wanted to solve for users which helped technical and non-technical folks find common ground. The user personas also helped tech leads realize that the existing technical architecture was not designed for end-users which was in turn creating a lot of tech debt. 

Impact

As an immediate outcome of this work the engineering team re-designed the technical architecture based on an understanding of users, essentially removing 30+ unnecessary user roles on the back-end. This also simplified the user experience (users now only saw 3 roles in a dropdown rather than 30+ and could set permissions based on their user persona), creating less confusion and generating less help desk tickets. Eventually we gained a Product Lead who helped us create a longer-term roadmap of work around “permissions visibility”.

Future work

To help with future “permissions visibility” efforts, I created an ideal user flow to shine light on what users need to do in order to accomplish their goal of viewing permissions across the product. This also highlighted multiple parts of the experience that needed to be updated in order to more effectively support users.

Later in the year the team got to work on various permissions visibility efforts, including updating the code from Angular to React and replacing the old UI with a more modern and easy-to-use one. Our internal client success team, and some clients as well, said the new experience was easier to interact with and it generally built excitement for future enhancements, particularly around “permissions control” solutions.