Citrix Analytics: Search, filtering
Search, filtering, and ML to help users experience the power of advanced searchOverview
A common frustration of searching for something on Citrix Analytics (CAS) is how challenging it can be to find exactly what you're looking for. Users had to rely on text searches instead of filters; there were very few ways to narrow what they were looking for effectively.
Snapshot of the search interface
ROLE
Product Designer
Interaction design, Visual design, User testing
---
Apr 2019 - June 2019
Background
There are certain standards for a search experience on most sites. You'd expect filters, faceting, and robust tools for narrowing down what you're looking at to find the perfect item. Having quality, structured information for an item being searched isn't an issue for most sites, and filtering is straightforward.
But this was not the case with CAS since the information was largely unstructured.
User testing to define the problem
In the earliest version of Search, I paired with a UX Researcher. I ran usability testing to understand what our users were looking for. We learned filters were incredibly important since they often looked for something specific, such as a particular IP address, Device ID, or a city.
The Approach
I worked with the data team and the content team in grouping the data into meaningful categories.
This translated into:
- Going through the data points that were in excel sheets
- Grouping them based on type and content
- Giving the groups of data meaningful names
Some of the data was already being categorized and had names (very technical names). Still, these categories were not being used in the code and were hence not being displayed meaningfully. In some other cases, there were duplicate names used for data of different descriptions. The terms of categories had to be unified across all our data sets.
Categorizing data
From this exercise, we were able to group the data into meaningful categories. This involved working very closely with Content strategists and engineers to make this change in the codebase.
As a result of restructuring the data in the database, we could have users enter a syntax-based search query to get precise results.
New design with a structured search entry
1. Data was categorized into the main group and a specific value within that group for easier searching.
2. Using complex operators, users were able to look for specific events.
2. Using complex operators, users were able to look for specific events.
Design
Once we had this key:value format search, I saw that most attributes would fall into one of four form field types:
1. Select multiple from a list
2. Select a single from a list
3. Numeric input for ranges
4. Simple selection for ranges
5. Date range
6. Specific value
Contributing patterns to the design system
The filter designs were foundational elements to many other layouts used in products outside of Citrix Analytics. I documented and shared rules and interactions for these elements.
Validating Designs
I tested the filter behavior with users with two goals:
- What drives users to use search?
- Usability of the filters.
The first part of the research focused on the goals and motivations of a user when they used this functionality.
80% of users wanted to search for items that caught their attention on the dashboard. E.g., "Excessive file download" was detected.
Users wanted to get to the bottom of this event - Who downloaded what? From where? How much? When?
They wanted to save their searches so they can repeat the Search the next time they came in.
They wanted to be able to share the search results.
“It is in search that I derive meaning”
Using Machine Learning
From the user testing, it was clear that users wanted to search for items that caught their attention on the dashboard.
I designed an entry point into Search from the dashboard, so users don’t have to type out a search query.
On the search page, I designed a panel for suggested searches which would use intelligence from the dashboard to populate relevant suggestions.
Search allows us to learn about our users' needs
A significant advantage of Search is that the user tells us what they're looking for. We can then capture this information by reviewing our search logs and optimize the product to deliver relevant information to users.
I designed an "Insights" panel that surfaces events relevant to what is happening in the users' organization. We can anticipate what the user might want to search for and present it to them before they explicitly search for it.
A significant advantage of Search is that the user tells us what they're looking for. We can then capture this information by reviewing our search logs and optimize the product to deliver relevant information to users.
I designed an "Insights" panel that surfaces events relevant to what is happening in the users' organization. We can anticipate what the user might want to search for and present it to them before they explicitly search for it.
Read along for more details.
Making Search Easier
There were some more features that users indicated would make their search experience more powerful.
1. Use input widths that are appropriate for the typical query length
Typical query lengths were much longer than what the initial design accommodated. This caused users frustration since they could not view the complex query they were building out.
1. Use input widths that are appropriate for the typical query length
Typical query lengths were much longer than what the initial design accommodated. This caused users frustration since they could not view the complex query they were building out.
I designed a search bar that goes full width and can be expanded and collapsed when not needed to be in view. The collapsing helps because some users have queries that go into more than one line width.
2. Share and send as a report
Users wanted to be able to share the results if they liked what they saw.
They also wanted to send them as a report periodically on a schedule or for one time. They didn't want to have to spend time constructing the query repeatedly.
Users wanted to be able to share the results if they liked what they saw.
They also wanted to send them as a report periodically on a schedule or for one time. They didn't want to have to spend time constructing the query repeatedly.
3. Create Alert
Users wanted to be alerted when there were new results for their search queries.
Users wanted to be alerted when there were new results for their search queries.
4. Save Search
They wanted to be able to save the search and retrieve it to run searches in the future.
They wanted to be able to save the search and retrieve it to run searches in the future.
5. Keep recent user’s search queries
Users want to see this data the next time they search.
Users want to see this data the next time they search.
6. Add and organize columns
Most users wanted to view more columns than what was being presented by default. There is the ability to add columns but no way to group them. This design allows them to add and group columns.
Launch and Reception
Before our launch, we used a prototype test with internal users. They helped us find bugs, refine them.
The positives were:
- The reception of faceted Search.
-
The suggested searches and the shortcut to search from an event. We extended this to some areas in the product, beyond just the dashboard.
-
The insights panel was not launched as the engineering investment in it was immense. I hope that it will be planned for a launch in the near term.
There was mixed feedback from the terminology of the facets.