Basic search and advanced filtering for endpoints
Security admins, my target users, need a way to look up endpoint groups for day-to-day operations. They also need to be able to explore endpoint traffic data to inform business decisions on network segmentation.
Business Background
My Role
I led the design after picking up the project from another designer. I worked very closely with the developers that were driving the project: concept whiteboarding, sketching, wireframing, prototyping, pattern compliance, and detail screens production.
Results
Successful release for beta users
Diving into the attributes breakdown of the database with my developers
The Process
My business unit had been working on this network segmentation product for over 3 years before I joined. The landing page was already developed with 2 main features: search and endpoint analytics visualization. My task was to redesign the search experience so that it allows the user to do both basic search and advanced filtering. The “object” of the search database is an instance of traffic between two endpoints.
The first challenge I encountered was the technical constraint with scale. When a user does a basic search, i.e. text-based search, the results were too large to be displayed. The developers informed me that the design must require the user to narrow down the scope before he submits the search criteria. So our system was not able to achieve what a user would expect for a basic search experience: type something, hit ‘Search’, and see results. I identified that this is a categorical search problem, where the user has to narrow down the scope before the system can return a set of data. So I looked at Amazon and various real estate websites to see how consumer-facing products have solved the issue. After a couple of weeks of brainstorming and iterations, I decided to go with the following solution. The user will type in the search bar, which will bring up potential results in the six categories, and he will need to click on “View All” to see the actual results page.
Users need to save a search to see a particular group or traffic in the future easily. This was tricky because the user had to be able to switch between the basic search to advanced filtering. After he types, the user had to be able to save that search specifying what category the text value he typed belonged to. The previous designer proposed a design that allowed the user to trigger advanced filtering within the dropdown, but the design was rejected in the end due to various pattern compliance reasons. The pattern team already had a filtering solution built into the data tables component, and after several reviews, we decided to use the component for this solution.
Another technical factor was that the returned data was dependent on a given time frame. There was an existing time selector component in our design library, but customization was needed because of different technical constraints. The system is updated with the traffic data at every hour at the top of the hour. The implication is that the user cannot pick specific time, only by the hour. The engineering team responsible for managing the data informed us that they can only allow 1 hour, 12 hour, and 24 hour time frame. This means that the user cannot pick any hours until they decided which time frame they want to view first. Though it was not an ideal way of picking time from a user’s perspective, the design solution was still easy to understand and use.
Learnings
One big takeaway for me was that search design is not as easy as I previously imagined. I came into the project thinking that search has already been thoroughly designed in our world, and though that is true, the type of user, the kind of data, and the underlying search engine still make a big difference in the final design. There were many nuances and technical constraints that presented interesting and brain-numbing design challenges, and it was rewarding to see the final solution in the product.
