Atlas - User Permissions
Taking multiple constraints and designing visual clarity
Information Architecture | Interaction Design | UX Design
August - September 2020
What is Atlas?
Atlas is an internal developer tool that allows software engineering teams to automate the build and deployment process for their existing applications / software. It is composed of the user interface, and a configuration file where developers can make changes to their build/deployment pipeline.
Atlas is also built on top of existing DevOps tools/services.
Background & Challenge
When an application is onboarded into Atlas, it must be approved. Once approved, a series of permission groups are provisioned, and the onboarder and approver gets added to them. These groups are important, since they give the user permissions to various DevOps tools as part of Atlas. However, other team members will need to add themselves manually to these groups.
Problem 1
Other developers and team members need to figure out which permission groups are needed so they can manually request access outside of Atlas. This can be extremely time consuming and frustrating since users might not know which tools they need, the names of these permission groups, or how to request access.
Problem 2
While the team owner could grant other team members the required permissions, there also isn’t a quick way for them to see which team members are part of these permission groups.
Problem 3
Atlas creates many user permission groups, and wants to streamline the number of user access groups necessary.
“There are so many roles that it’s tough to automate. When I onboard an app code, I know I’m going to spend the afternoon requesting and approving [permission groups].”
Solution
I designed a panel in Atlas that displays users and the various permission groups.
A new access group was created that would provide users read access to a subset of these DevOps tools (Pipeline Tools Viewer). The approver (Group Owner) would be able to go into this page, see who has access to this group, and add additional team members. While there would be some tools that could not consolidated into this Pipeline Tools group, it significantly reduced the number of access groups needed.
What I learned
Initially this name for the new permission group was called "Atlas read-only access" but multiple users were confused as to what this meant
Some did not know if adding or removing members meant removing them completely or from a specific group. Only after interacting with the feature did they understand.
How to dig into feedback and make hard choices. When doing user testing, 5/9 users said they preferred Flow B, however the other 4 users completely missed key
What I did
Renamed the permission group to "'Pipeline Tools' Viewer" to give more clarity into what this group provided permissions for
Added confirmation dialogues when adding and removing users. Aside from the additional friction, it allowed users to learn that adding and removing a user only removed them from a specific group.
Chose to design Flow C due to the usability issues that were pointed out in Flow B. This is despite more users preferring Flow B overall.
Final Output
I created a high-fidelity prototype that displayed users, and the different permissions they are part of. As part of this feature, users can also add and remove members from one group (the 'Pipeline Tools' Viewer group)
Full Design Process
Discovery & Initial Research
For this feature, there were very few unknowns.
After speaking with the developer lead and users who requested this feature, I was able to quickly gather a list of requirements
Everyone should be able to see a list of team members and the permission groups they are associated with
A new permission group will be created that would provide users read-access to a subset of these DevOps tools
The approver (group owner) should be able to add and remove members to the read-access group above
Additional help text and links will be provided to help users add themselves to the other permission groups
Design
Design Goals
The goal of the design was to create a way for people to see the users and associate permission groups, along with an intuitive and clear way for someone to add and remove group members for only this new permission group.
Low-fidelity Sketches
I first started designing some sketches based off of existing design research and user permission pages.
Mid-fidelity Mockups
I created some mid-fidelity designs of some ideas I had and tested V3 and V4.
Creating a request
Testing - Round 1
Testing Goals
I tested two versions with users, and I wanted to see how users would react to the two different flows. My instinct was that Flow A would make more sense to users, since details and actions were explicitly grouped with each individual permission group. However, I knew it might be a nightmare to navigate if a group had a lot of members.
The goal is to determine which version of the two prototypes users preferred, and determine the areas of friction. feature with 5 users to learn if this feature was intuitive, and where friction points existed.
Top Findings
5 out of 7 users strongly preferred Flow B, citing that in Flow A, they would need to scroll a lot to find the information needed. Users wanted to see an employee, and all the groups they are part of in one view and not the other way around. This way they could also determine all the groups a certain user needed to be added to.
However, 3 users were still confused with Flow B. This included:
Thinking that removing a user meant removing them from Atlas in general, and not from a specific group
Not understanding whether you could interact with the different checkmarks for the groups
Not knowing what the Atlas read-access group meant, and thus not knowing what access this group gave.
Someone trying to add and remove a user by toggling the checkbox multiple times
Since more users preferred Flow B, and Flow A could be difficult to navigate, I iterated on Flow B with the given feedback. I then tested this updated Flow B with a new Flow C.
Testing - Round 2
Flow B was updated with a new group name, additional confirmation flows stating exactly what you are removing / adding an user from, and an “in progress” state when adding/removing a member.
Top Findings
4 out of 9 users said they preferred the Updated Flow B, and 5 out of users preferred Flow C.
However, when digging into the reasons, I found that:
3/5 users preferred the new Flow C liked it because of "less clicks".
4/4 users preferred the Updated Flow B because Flow C was even more confusing to them. They all completely missed the interaction to add a new user since it wasn't visually distinct.
Due to the confusing interaction in Flow C, I finalized the design using the Updated Flow B regardless of which version users say they preferred.
Retrospective
This was a straightforward feature to design for, without very many unknowns at the start of the design process. The biggest challenge was to design a clear and straightforward experience that took into account the various constraints and the complicated user permission structure. It was also important for me to take into account contrasting user opinions and read in-between the lines to make the best design decisions.
I know that the feature can still be a bit confusing, and am continuously thinking of a better way to support this feature. I am looking forward the day Atlas can support the add / remove function for all permission groups.