FACTUAL: ADMIN INTERNAL TOOL
Redesigning Complex Permission Systems
ROLE Product Designer
WORK Product Strategy, Interaction & Visual Design
TEAM UX Researcher, 4 Front End Engineers, PM
Factual’s Admin Tool was not built with its users in mind.
Factual's account managers use Admin to grant client companies access privileges to Factual's suite of products. The problem, though, is that Admin was shipped exactly the way it was built on the engineering side, making it unintuitive.
The UI design, as seen below, is also dull and lacks visual contrast.
PERMISSIONING WALKTHROUGH
So how does the current permissioning system work?
First, meet Keanu.
He’s an account manager at Factual.
1
KEANU JUST GOT APPLE AS A NEW CLIENT
He adds Apple as an “Org” to the system.
2
THEN, APPLE GIVES HIM A LIST OF EMPLOYEE EMAILS
He enters those emails into the system as “Users.” These users are Apple employees that could be working as data analysts, marketing managers, and many more.
3
AFTERWARDS, HE HAS TO LINK EACH USER TO THE APPLE “ORG”
4
THEN, HE HAS TO GIVE EACH USER THEIR CUSTOM PERMISSIONS, ONE BY ONE
This manual permissioning process can range from from doing it once for the whole org, to customizing it individually for up to 100 users.
DESIGN PROCESS
How might we design a “permissioning” system that saves account managers’ effort and time?
PART 1 SUMMARY OF KEY PROBLEM AREAS
The process is repetitive
Account managers waste a lot of time just doing these overly manual processes
The UI has little contrast
This makes the process much slower for account managers who need to look at their screens all day
The design is not optimized for adding a large amount of users
It takes an insane amount of time for account managers to add companies with lots of employees. On top of that, they will have to repeat the process when setting permissions for these new users.
PART 2 DESIGN PROCESS TIMELINE
The redesign process took 6 weeks, which included user research and multiple sync sessions with Engineering.
1 Research
Sat in user interviews with 3 real clients with our UX Researcher
2 Exploration
Created multiple wireframes in order to test the flow
3 Syncing with Eng
Showed our engineering team the preliminary wireframes
4 Technical Constraints 🚨
Unfortunately, after syncing with Eng, they informed us that some of our designs were not possible because of how the code was structured under the hood.
In simpler terms, the permissioning process didn’t allow for individual permissions to be “negated,” or turned off. It also only allowed for things like “sub-permissions” to be inherited from the parent permission, which was not what we thought.
Though complicated, I was able to understand these technical limitations over time thanks to the Computer Science classes I voluntarily took at UCLA.
5 New Wireframes
With a new understanding of the system, I redesigned the wireframes to fit within the technical constraints, and then tested the approved version with new account managers.
6 High Fidelity Designs
After that final round of testing, I finalized the wireframes and created high fidelity designs.
Final Solution
After weeks of interviews, explorations, and wrong turns, below are the design solutions for the new Admin permissioning system. Please play all videos at max resolution.
STEP 1
Creating an “Org”
STEP 2
Creating “Users”
STEP 3
Permissi-oning
A. GRANTING ONE USER PERMISSIONS
B. GRANTING MULTIPLE USERS PERMISSIONS
C. GRANTING AN ORG-WIDE PERMISSION
Reflection
This is probably the most complex redesign I've ever worked on, even if the prototype videos may seem very straightforward from the get-go (as they’re supposed to be).
Understanding the platform's technical capabilities and how the system was designed and developed was required to execute this redesign. There were so many times that we had to go back and forth in the design process because of lack of context on a technical complexity, a problem regarding scalability, or an emergence of new information at any time.
If not for the patience and guidance of our PM and the awesome Front team, I don't think this would have worked out as smoothly and efficiently as it did. I'm so grateful for the huge learning experience and the trust that was given to me and my co-intern Aneri by the rest of the team.
Thank you!
I'm really grateful to my co-collaborator Aneri, who worked day and night with me to conduct user research tests on this particularly complicated tool, all the way to supporting me as I created about a billion wireframes a week. Together, we reworked our assumptions at every step of the design process. Besides being my partner in crime in this, she also designed the user testing sessions that we used to validate these designs.
I'm also grateful to the Front team: Laura, Edwin, and Forrest, and our PM Mike for being present any time we had questions or needed to clarify something. They were also really supportive and trusting despite this being a huge project meant to be tackled for more than a quarter. They were also very candid with feedback and were very engaged throughout the whole summer.