B2B Platform: Advanced Filter
role: UX DESIGNER
TOOL: FIGMA
DEVICE: DESKTOP
TIMELINE: 3 SPRINTS
Background
The goal of this project was to improve the search experience for our Rule Management Product to help users more easily search for rules. The users of this feature are our internal AdOps team, who handle the day-to-day programmatic trading for our partners.
There are 3 types of rules (Ad scheduling, Skip, No Ads) sitting on their own subsection under the umbrella of the rule management section. Users won’t be able to search across all rule types today.
There are about 1000 rules within the rule management. A rule is formed by a set of conditions and its command.
For example, a skip rule might look like this: for “country = France” and “video duration < 5 minutes”, then set the rule as “skip at 15 seconds”.
In this case, “Country” and “video duration” are conditions, and “skip at 15 seconds” is a command.
How I started
The PM and I meet with 12 AdOps users to understand how they search for rules and conditions today. We split up the sessions and then upload our recordings to Dovetail, then cross analyze each other’s interviews. In the end, we summarized the findings together and shared them with the core stakeholders.
What we learned
There are two main use cases:
There are two main use cases:
Users will search for the command and see what conditions are applied to this command.
(Above example) They will search for skip rules at 15 seconds with 1 or 2 condition filters to narrow down the results
Users will search for the conditions and see which rules contain these condition sets regardless of the rule types.
(Above example) They will search for all the rules containing “France” and “video duration<5 mins”.
Constraints
3 rule types on their own subsection. Because the rules are spread out in different sections, there is no way for a user to search across all rules.
All the rules have different commands, some commands have a long format
Not all rule types use the same set of conditions
Problems
With the constraints in mind, I summarized the problem as “ How might we support users to filter by both commands and conditions, moreover search across different rule types?”
Goals
Provide AdOps users with the ability to:
Filter by commands and conditions
Search across all rule types
Inspiration
with these challenges in mind, I started by researching indirect competitors that offer an advanced search feature.
I looked into real estate and e-commerce websites that typically have large inventories and complex search functionality.
For StreetEasy, there are a few popular filters that are always displayed. When a user clicks "More", it opens a modal that contains a list of additional filter criteria. This helps users quickly narrow down the search results and the progressive disclosure of additional filter criteria helps ensure a user is not overwhelmed with all filter options.
For Ssense, the filter options display on both the right and left sides of the page. We can display all the condition filters and not take over the real estate of the page. This approach allows for all filter criteria to display on the page, giving a user visibility and easy access to available filters.
Brainstorm & Ideation
Based on these learnings and discussions with the PM and UI engineer, we decided to build a search section to allow a user to search across all rules.
Once we aligned in that direction, I organized a design workshop with another 3 designers to brainstorm ways for how we might display filters for each rule type so that users can either:
Filter by commands and condition on one rule type
Filter by conditions across all rule types
Based on the ideas generated from the workshop, I came up with 3 design variations.
Idea 1
This idea was to show the rule type filter and hide the condition filter under advanced search.
If a user selects “skip” as a rule type, the command field “skip at _ seconds” shows up in the advanced search expansion.
If a user selects one more rule type, the command field will disappear because it is only related to “skip” rule in this case.
Idea 2
This idea was to use a side panel to display rule type with command field and condition filters. If a user clicks the “Rule Type” filter
It opens a side panel that contains condition filters.
If a user selects “skip” as rule type, then the command field will be activated.
Once users close the side filter panel, they can still see the number of filters applied.
Idea 3
This version was a combination of the first and second ideas: the most used filters would display on the screen, but a user could open a side panel to see all the condition filters.
If a user clicks the button next to condition,
It opens a side panel with a list of conditions. The conditions will be changing depends on the rule types that user selects.
If a user selects “skip” as a rule type, the command field “skip at _ seconds” shows up under the filter set.
Design Validation
Before meeting with users, I had a sync with the PM and the engineers to get feedback and understand the technical feasibility.
The PM and I met with 6 AdOps users to share the three design concepts. From their feedback, we learned:
Users want to see all available rules instead of an empty table so they can easily browse the rules
Users would also like to see the last modified date on the screen as this is also a way they identify rules
Users preferred seeing which filters were applied rather than a count of applied filters since they may not remember which filters they selected
Iterations
Based on the user feedback, the slide-in panel wouldn't work because it didn't show which filters were applied. However, we didn't have much space to add a side panel since the navigation menu is on the left so I started to explore ways to display the selected conditions vertically.
If a user clicks “add condition”, it adds a row that allows the user to filter on the conditions.
My concern with this design is scalability: if a user applies more than 5 filters, the search results get pushed down on the screen and are harder to see.
As I continued iterating on the designs, the PM was able to get data on the average number of applied search filters, which is usually 1-2 but a max of three filters. This gave me more confidence in the design direction.
Final Design
After getting approved by the PM and the engineers in the design review meeting, I delivered the final design.
Check out the Figma Prototype.
Next Step
Once the new search improvements were released, adoption was high and users shared positive feedback about this experience. Going forward, we'll look to add more rule types and validate the designs with more complex, yet uncommon, use cases.