🔐 Granular Permissions: Redesigning the Pendo Roles & Permissions Experience

User Permissions Detail Core Permissions

Rethinking Pendo Permissions

This was a giant project and my first when I joined the company in 2019. Prior to joining, I was a customer. At that time, Pendo had very limited permissions. Customers were either Admins or Users. This was fine for smaller companies, but as organizations and products scale, the need for granular permissions becomes increasingly clear. When your product covers extensive ground from product analytics, in-app guidance, and customer feedback, you end up having multiple teammates with unique needs and areas of expertise. A lot of different teams can learn from Pendo's powerful data and we learned that with this comes great responsibility and the need to provide users with a variety of access levels. For example, someone who creates a guide on a marketing team may not want to be able to publish that guide without approval from another team who can publish it. An analyst may need to edit reports, but not guides. A general user may just need to read a report and not be able to edit it. It's essential to keep this experience clean and simple for everyone.

Our project began with a lot of research. A lot. We did not have a Design Research team at the time, so our PM traveled the country and conducted extensive research into our customer needs and current pain points. We began the process of scoping how we could create granular permissions and allow our customers to create custom roles for different users within their organizations.

As a part of our design research, we conducted a variety of assessments from concept testing to user surveys. In one of the larger surveys, we conducted an exercise comprised of a list of potential user roles that surfaced from the PM's initial research and had customers connect those roles to features and actions in the product.

To compile and present this information to our team, I created the interactive visualization below:

👆Connecting Roles to Actions: How do customers see roles and permissions in our product?

Whiteboarding Everywhere

Early whiteboard brainstorming superusers

We made use of every surface in our office, from meeting rooms to windows and collaborating in Figma. We prototyped non-stop. We went back to the drawing board many times over the period of a year and ended up solving a lot of problems facing our ever-growing list of enterprise customers.

Non-stop Prototyping: Single Apps, Multi-Apps, Users & Groups

User Permissions Detail Assign a single role to a single user

We prototyped almost everything we could imagine and tested each iteration:

  • Creating a role
  • Creating a group
  • Assigning a user to a single role
  • Assigning a user to multiple roles
  • Assigning a user to a group
  • Assigning multiple users to multiple groups
  • Assigning a group to a role
  • Assigning multiple groups to multiple roles
  • Assigning a single app in a subscription to a user/group
  • Assigning multiple applications in a subscription to a user/group
User Permissions App Level Detail

👆App Level: Assigning a single app to a Guide Creator

Apply role across multiple applications

👆Multi-App Level: Assigning multiple apps to a user

Apply custom role settings to users and groups

👆Custom Roles & Groups: Applying custom role settings to users and groups

Results

The results of our work were extemely well-received both internally and with our customers. We designed a system that scales well with the product, provided a design pattern for future persmissions considerations, and allows customers to create unique, custom roles for the variety of users they have in their organization.

Slack message from Customer Success. Woohoo!