DESIGN STRATEGY, USER RESEARCH, INFORMATION ARCHITECTURE, PRODUCT DESIGN

Role Based Access Controls

an admin tool to view and manage users' granular access to the AppDynamics Product
Role Based Access Controls
ABOUT
AppDynamics, a Cisco company, is an application performance monitoring company. The controller is our core product- where users can go to view their application data and to troubleshoot when there's an issue. While the Accounts section has majority of the Admin tasks, Role Based Access Controls (rbac) currently lives in the controller, as the permissions granted affect each controller separately.
ROLE
Product Designer:
UX Strategy, User Research, Wireframing, Visual Design, Interaction Design, Prototyping
KEY MEMBERS
2 UX Researchers
Design Manager
Product Manager
5+ Engineers
PROTOTYPE
Fig 1. Create policy prototype
Fig2. Create permission set prototype
OVERVIEW
AppD 2.0 was a design led project that focused on reimagining the entire product experience. It focused on creating better personalized experiences, more powerful search and filtering, better architecture, and moving towards a Flexible Metadata Model (FMM), meaning any ingested data will be modeled using tags and attributes. This will map to a more modern application architecture. For permissioning, you would be able to manage all users and the permissions they have in the context of the rest of the product.
‍
During this process, roles and permissions came up often and seemed to be an area of extreme importance to our users. Our current roles and permissions UI was outdated, clunky, inefficient, and extremely confusing. We also found that granularity was very important to our users.
appd 2.0
appd 2.0
Fig3. AppD 2.0 policies screen
Fig4. AppD2.0 create policy screen
PROBLEM STATEMENT
All of the work done for the RBAC mocks has been in the context of the AppD 2.0 project. But, this project could take years to implement as we are restructuring the entire product. So, where do we go from here, and how does this fit into our current architecture?

While revisiting the current experience, we asked ourselves 2 questions:

1) How can we clean up the UX/UI in the current architecture?
2) How can we set ourselves up to scale this to our future vision?
internal tool
Fig5. Account level permissions in the current experience
RESEARCH AND FINDINGS
Industry Standards
The purpose of this research study was to understand how administrators across organizations typically manage users and access. This helps us to get a baseline on access management and to understand what admins like and dislike about different management systems.
While speaking with admins from different companies, we learned about the most popular access management systems used and what the pros and cons of each were. From this research study, there were 4 things that came up often:

Admins were looking for a clean, intuitive, and simple user interface. Admins like to be in and out of these tools, and the easier an interface is to use, the more efficient an admin can be in their duties.
‍
While some permissions are easy to understand, others can be difficult to interpret. All admins wanted either better documentation that described the permissions or something in the UI that showed the descriptions alongside the permission names.

All the admins we spoke to mentioned that they group users in Active Directory (AD), and they use this to map to the roles. A seamless integration with AD is a must for admins.

Lastly, it is a huge security risk if a user has more access than is needed. The concept of least privileged access was of high importance to admins as well.
metrics
QUOTE FROM AN EXTERNAL 
PARTICIPANT
“I wouldn't want someone getting access to 20 different things, I’d want to assign those 20 things individually. I wouldn't want to make it a one size fits all. We operate on a least privileged basis. It can be restrictive, but in today's environment you need to be.”
Understanding Existing Permissions
The purpose of this research study was to identify trends in our current permissions to reclassify them. Currently, our permissions are listed in alphabetical order with no description attached to them. Without clear hierarchy and adequate information, admins are unsure of what all the permissions do.

Grouping the permissions into related categories can help admins understand the meaning or the underlying concept of the permission. Currently, permissions are just listed in alphabetical order, and it is unclear how the permissions relate to one another.

We conducted a cardsorting exercise with internal employees to understand how people grouped these permissions and by doing so, we can understand what they think the permission does. Through this study, we were able to come to 5 different categories: Application Configuration, Agent Settings, Alert Health Monitoring, Troubleshooting, and Other.

Now that we had a starting point in how to categorize the permissions, we planned to use these categories in the mocks and do testing on actual customers to see if they resonated with their thinking as well.
internal toolcardsorting
Fig6. Current design of application permissions
Fig7. Cardsorting results show how users group these permissions
Redesigned Experience
The purpose of this research study was to gather customer feedback on the reimagined role creation workflow. By getting feedback on the mocks we created, we were able to see if our new flow resonated with our admins and if it gave them the confidence to give the right amount of access to their users.

We spoke to 5 customers to gauge how the new designs resonated with our users. Overall, there was positive sentiment on the designs. While the create role wizard was intuitive, it seemed to be too exhausting for the users. They wanted to be in and out of the system, while making sure to not compromise security and access. For any role that they wanted to create, they would have to go through this process of looking at all 100+ permissions, making it an inefficient use of their time. If there was a way to automate or reuse certain types of permissions, it could make the process simpler and faster for the admins.
wireframes
Fig8. First half of flow that we showed our users
wireframes
Fig9. Second half of flow that we showed users
EXPLORATIONS
mockmock
Fig10. Wizard structure that separates entity selection and permissions
Fig11. Create policy screen, with permissions handled in a separate section
FEEDBACK:
Overall, this version had positive comments. While this version was better than what is currently available, it forced users to get through all the permissions every time they created a role, instead of using reusable sets of permissions.
FEEDBACK:
This version seemed to work both for internal stakeholders and for customers. This allowed admins to quickly create policies without having to get to the granular level every single time.
USER TESTING
We showed our current set of mocks to both customers and to various internal stakeholders. For customers, they could get to the granular level for permissions through permission sets and be efficient in creating multiple policies. For internal stakeholders, this helped set the foundation for future AppD 2.0 work.
FINAL EXPERIENCE
mock
Fig12. Create permission set screen
mockmock
Fig13. Filtered list for create permission screen
Fig14. Create policy screen
WHAT'S NEXT?
Moving forward, our next big step will be to select an RBAC vendor. With many other projects being prioritized, we don't have as many engineers designated to building our the new RBAC experience. By leveraging APIs from a vendor, we won't need to use as many resources from our side, we can get new features such as a preview mode, and we will be able to build this experience out quicker. But, in doing so, the designs may need to be altered based on what our selected vendor's capabilities are.
‍
We will also want to speak with a broader group of people, both internally and externally. Internally, we would want to make sure that our designs fit in with those from other features, making it a cohesive experience. Externally, we would want to speak to a broader range of users to make sure our vision fits in all of our customers' environments.

PREV

BloomTech Portal

NEXT

Centralized Identity
EmailGithubLinkedIn
Copyright © 2024 vasavireddy@gmail.com