Redefining Access Management
My Role
I led a Product Designer and Visual Designer from my team of 5 direct reports to form a project team. I was responsible for planning, requirements gathering, strategy, wireframing, research, customer interviews, and executive presentations. My team also partnered with the UX research team, and Product Managers for research, scope, and roadmap planning. I also partnered with Engineering leads to plan project feasibility, and resource assignments.
I was primarily involved during the discovery and definition phase, and acted in a supportive role as the team carried the project into the development phase.
The landscape is shifting beneath our feet
As businesses move to the cloud, we’ve had to re-evaluate our place in the market.
Old dog, new tricks
The observability landscape is shifting as many customers are increasingly adopting new technologies, and transforming their businesses in the cloud. The legacy Commercial SaaS AppDynamics product was built on a monolithic infrastructure with outdated technologies. It has trouble scaling to meet customer needs, and forces users to map their companies onto a rigid App/Tier/Node model that does not necessarily fit their mental model.
As a result our access management and permissions structure is limited, does not scale to users needs, and in some cases exposes security risks.
The scope of this project was to completely redesign the access management experience.
Persona
Allison the AppDynamics Admin
Allison has been at her company for many years, maintaining and administering IT tools. She got started as a developer, but that was ages ago and now she is used to the many administration panels provided by off-the-shelf commercial software. Even so, her team has to administer many IT apps and they are constantly inundated with requests. She and her teammates know there must be a better way to manage enterprise tooling at scale.
Allison; an Admin’s life isn’t easy
At the start of this project we had a role based access control model. Each role contains a different set of preset permissions. Every time a user onboards a new application to monitor, they have to create and assign permissions and access. They have to do this in each hosting environment, that we call “controllers”. Companies have multiple controllers. Editing these permissions is time consuming, and confusing. Often a permission is presented with an obscure title and a checkbox. Once created there’s no ability to copy and paste across controller environments.
We’ve heard from numerous customers that they are required to generate up to three roles (View, Application Admin, and Super Admin) for every application that is being monitored by AppDynamics. When a customer has 1000+ applications, the amount of time spent in the UI clicking and creating roles can become tedious – and in some instances requires a dedicated team to do just that.
In other cases multiple roles are required to complete the workflow successfully. By requiring multiple roles, we’ve created a challenge for Admins who have to retain this knowledge or manage access by trial-and-error.
It’s a shell game of permissions
Yes, that’s tabs, checkboxes, and hidden menus. In addition to the 12 default roles, with no context as to what these permissions are effecting.
16 steps minimum!
That’s at least 16 steps through multiple menus to create a custom role. Hopefully without exposing access to the wrong thing.
People HATE this
Permissions are overused across the product and lead to confusion, security issues, and escalation tickets.
Major security Risks
There is no breakdown across servers. Users can either have access to ALL servers or NO servers. This has caused some customers to limit the number of servers monitored by AppDynamics or reduced the number of users that have access. Thus reducing the value of AppDynamics.
When granting access to the dashboard edit permission, the end-user also has the ability to share the dashboard. This is a security risk because once shared, it can be accessed with no authentication and no oversight as to who can view it.
Users that only need to view Agents are required to have the "Admin, Agents, Getting Started Wizard" role. Once enabled, the user will have full admin access across the controller.
The Pain is real
“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.”
"I can create a role, but I cannot create any permissions. If we could create permissions and roles from the Rest API, we could probably automate this. Then we wouldn’t have to sit in here and click around."
"There might be a ton of rules behind a role that you assign, so you don’t know exactly what you’ve given out. Making it really clear [in documentation] without having to read war and peace to understand. A good GUI is always helpful.”
Goals
Improve Security; Allow Admins to grant access only as it’s needed
Improve Usability; Reduce error by making permissions clear and granular
Improve Utility; Provide the ability to apply permissions from one environment to another
A standard approach
After hearing from users, I wanted to leverage industry standards and common patterns for managing access control.
Admins use many IT apps in addition to AppDynamics. I wanted to see how competitors and contemporaries were defining access management. During interviews, AWS came up a few times, and I had an engineer walk me and my team through how they set permissions using policies in the AWS interface.
I was compelled – I did a deep dive into the AWS documentation to better understand how AWS approached policies. In addition, I also did a comparative analysis of Google Cloud, Salesforce, Okta and Jira.
I drafted some diagrams to explore a policy model that would allow users to create access permissions at the entity level.
ADX is a fictional company we created to experiment with how the policies might map to an organization.
Assumptions
By leveraging the concept of policies, Admins can manage access for roles, groups, users, and any entity or resource. This would mean any time an administrator onboards a new application, creates a dashboard, or adds a user into the system, they can simply apply an existing policy allowing or denying access, and further refine access from there. This model of access would go beyond confusing role based access control, and allow users to assign permissions more intuitively.
More interviews, more to learn
I needed feedback, so I ran this by a Product Manager I partnered with. He had done some independent discovery research which informed our hypothesis. I wanted to learn more so I did a round of internal interviews during which I talked to Engineers, PMs, Sales Engineers, and Customer Representatives.
Based on what I was hearing I developed a series of user flows and wireframes to help me understand and communicate how these entities mapped.
Task flow
These are some of the basic tasks an administrator might need to accomplish. I initially started from the new user onboarding perspective to find opportunities to improve the experience from the first touch point with Admins. I drafted this after talking with PMs and Customer Sales Representatives to understand where in the flow Admins might need to set permissions.
Motivational insight
Once an application is onboarded, the Admin needs to add people to view it. In the previous model it was done with obscure default roles. I wanted to explore a more flexible model. The concept of groups, copy, and adding permissions to an entity were all things that could not be done in the old system.
I needed to go deeper
After sharing the previous flows with a PM and an Engineer, I got a better understanding of the application onboarding process. I built on the previous flow by exploring the add user, business unit, groups, and roles onboarding flow. This is also where I started looking at access through an API, and adding users through and Identity provider.
Team, assemble!
Once I had the initial round of flows, I pulled in one of the product designers on my team. We started whiteboarding, then moved onto to wireframing, and after we settled on a strategy she led the design, developed the next round of user flows, and built a prototype to demonstrate the future vision of access management.
How might we create policies beyond the application?
We started sketching on the whiteboard to explore how we might create access policies at the entity level. We wanted to look at creating policies beyond the application; what would it look like for organizations, groups, users, dashboards, and pages?
We started at zero
Once we started wireframing, we wanted to explore the first time user experience. We asked ourselves, how did access management look the first time an Admin logs into the system?
An Admin homepage
As part of the first time user onboarding experience, we explored the concept of optimizing the homepage for Admins. I talked to the PM I had partnered with, and some Customer Sales Reps to generate a list of activities Admins would typically be doing on set up. The focus was around adding users, and delegating tasks. We featured permissions prominently because my assumption was that Admins would want access defined before adding people.
We eventually moved away from the idea of having this on the homepage to favor a focus on configuration. This concept evolved into Admin tools, and eventually the Accounts overview page.
We’re gonna need a bigger boat
With the prototype ready, I developed a narrative, and presented it to executive leadership to get buy-in to move forward with additional resources.
The leadership team, including myself took this prototype on a round of customer visits throughout the UK. During these customer visits I presented the prototype as part of larger showcase to explore the future vision of AppDynamics.
We were ready to start cooking
It was time to start developing the vision into a reality. We pulled in engineering resources while the Product Manager began narrowing scope and defining engineering requirements. My team revised the mockups and generated another round of wireframes to account for the narrowed scope.
Another round, another research
With a revised wireframe prototype in hand, the Design team and lead Product Manager partnered with the User Research team and conducted 3 studies with 6 participants.
This included an observational inquiry in which we asked administrators to show us how they managed users and access; this provided insight into the workflows Admins are familiar with.
We conducted a card sorting exercise to identify trends, terminology and behaviors. We also conducted a task based usability study with the prototype.
We learned a little more
The team explored an option with a step wizard, but it didn’t solve the problem of options being hidden within the interface. This actually confused users, but It did help push the terminology discussion forward. The summary section got a much better response. Users liked seeing all the selections they made, they felt that it was much clearer.
Admins want simplicity
“As a sysadmin I go into these tools to do config, and there are definitely systems I feel lost. There are menu options on the left, on the top [...]. I don’t like diving through all these menus to do simple stuff. I’d rather have one simple menu that stays the same and use it that… ”
“We like products that integrate with AD. Instead of being able to import and delete users in one place we had to go through a checklist of things in each application. If this guy gets fired we have to go through a long checklist of actions in different places just to delete them.”
“The more granular the better, everything is least privilege model so you can slowly start adding things they need”
From research to insights
We heard from 4/6 participants that they prefer the “least privileged model”, which validated our assumptions that users needed more granular control and would benefit from our policy model.
This led the team to further explore the least access privilege model, and build the policies on top of that.
The principle of least privilege is an information security concept in which a user is given the minimum levels of access or permissions needed to perform their job functions.
Bringing it all together
As we continue to build the tech stack that will support the future version of the policy experience, the team developed a version that builds on only 3 types of roles; the 3 roles we heard users tell us they used the most. We added a summary section so it’s clear exactly how much access is being granted. We revised the terminology and labels based on what we learned during research and testing sessions. And we brought it all into a single interface.
Where do we go from here?
The team then developed an execution plan. This included refining permission in the legacy controller to support an API, and the least privileged access model. Then breaking down the scope for entity mapping with policies and iteratively redesigning the access management experience within the next generation product experience, built on an entirely new tech stack capable of supporting the entity mapping model.
Some takeaways
We set out to give Administrators more control over how they defined access for their resources. After hearing how users think about setting access control, we settled on the least privileged access model. This model meant that no user would get unnecessary access if it isn’t required for the workflow. This improved security by ensuring users wouldn’t get access where they didn’t need it while providing clarity into how access is granted. By building a foundation for access policies Admins can grant or deny access globally, defining permissions at the entity level. An improvement over the obscure roles.
Testing my assumptions
My assumptions were that people would universally understand policies in the permissions context. After testing we learned that the terminology overall was pretty confusing. We also used policies to define health rules, so it was important to clarify these as access policies.
We also heard that people really wanted an API first, this is something I touched on within with design, but didn’t spend enough time exploring the API first solution. It became an area of focus as the Product Manager began defining scope and requirements.
A point of pride
The designer on my team wanted to build leadership and presentation skills. I encouraged her to share work during design reviews. To prepare, I coached her through presentations and practice runs. During customer visits we had the opportunity for her to present the prototype and collect feedback. She continued to lead the User Management experiences within the Accounts team. This growth contributed to her receiving a promotion from an Associate Designer to Lead Designer.