1 PM director, team of engineers, 1 researcher, 1 product designer
Product design lead
2021-2022
The Universal Directory EPD team was reactive and had to create design band-aids due to all the performance issues with the UI for customers with hundreds of thousands of users. Some customers were churning or having to build their own solutions with the APIs.
While the design fixes were helpful for unblocking these customers, they weren't enough to make Universal Directory ready to support customers with a large number of users. To address this, I spearheaded a generative research study to better understand how we could redesign the experience to be more scalable.
The Universal Directory service provides a centralized location for businesses to manage user identities and access to resources, including applications and APIs, in a secure and scalable manner. It is designed to simplify identity management, reduce IT burden, and increase security.
I conducted a generative research study to better understand performance issues and customer needs.
Initially, I talked to the ENG team to understand all the performance issues. Here are the findings:
The information provided by the engineering team was insightful, but I also wanted to understand how our admins use our product and what their pain points are. To gather this information, I conducted a survey and received 30 responses.
According to the survey results, the biggest pain point for our customers is the search functionality.
“I find it hard to use UD as a replacement for AD just because of how it’s impossible to search for users”
“search needs improvement. Search doesn't include all users. Add filters, sorting options, search by all characters not just by first three letters”
“The search bar in the UD page does not handle search at scale”
“to be honest, we don’t even look at the initial records since we are there to search and therefore it seems to be a waste of search cycles and data transfer to even list the initial batch of users”
They also asked for more granular filters and better bulk actions:
“Not all statuses are easily filtered by the criteria on left. Would be fantastic to have filtering based on what system a user's profile is mastered by”
“Users created in the past x days, users deactivated in the past x days or show deactivation date for deactivated users.”
“Being able to perform bulk actions the same way as actioning under an individual person record.”
“Bulk actions are useless, I still have to search one by one then perform the action, instead of a better search to narrow down the list of users, then perform the bulk action”
To understand user behavior, the next stage of my research was to examine Pendo metrics.
71% search for users, after searching 83% of admins click on a user, 11% navigate to other parts of the product, 2% clear the search, 3% drop
Based on the research, it was clear that we needed to fix our search functionality, not only because it was causing performance issues, but also because it was the main action admins took when landing on the page.
The PM and I met to discuss our findings, and we realized that we already supported many advanced filtering options in the API.
Less than 1% of users clicked on bulk actions, and customers mentioned that bulk actions are not useful because there is no way to narrow down the list. Including advanced search for bulk actions might solve that pain point, as admins can search for specific users and then perform bulk actions.
To fully understand all the lego pieces that we need to move, I suggested creating a user story map to identify all the steps and different options. This will also help us map the new experience and compare different flows.
The PM and I wrote some user stories, and I used them to start mapping wireframes and possible ways of redesigning this page. Some of the concepts included:
After internal testing, we found that the most scalable pattern for our needs was flexible filtering. I experimented with having it in-line and in a drawer, but we did not have a drawer component at the time, and adding one would have increased the scope of the project. Therefore, we decided to abandon that concept.
Initially, we thought we could simply add the "advanced search pattern" and call it for bulk actions. However, after mapping a quick information architecture, we realized that we would have to implement the advanced search eight times. The ENG team was concerned about the increase in scope.
Using this information, I proposed a different approach and decided to bring bulk actions to the main people page, and the actions would be displayed based on the user's status. ENG approved this design since it was significantly easier to implement, and the advanced search only had to be implemented once.
We conducted an unmoderated usability tests on the new model during Oktane, and the feedback was very positive. Participants were able to complete tasks and commented on how familiar the experience felt.
“Simple and easy to navigate”
“The search is a huge improvement”
“The new bulk actions design is going to save me hours every week“
For phase 1, we only implemented the advanced search in the people page since there were some dependencies on the bulk actions.
Some of the results after launching the Advanced search: