Improving users’ advanced filters operators and interface
Team
Qomon: Back-end developer, front-end developer, customer support, product designer
Role: product designer – feature lead
Context
The Advanced Filters section was outdated and unintuitive.
- Users struggled to achieve their desired filtering results.
- The Customer Support team frequently received related inquiries.
- In many cases, filters had to be manually applied on the backend. Results were exported and sent to users: an inefficient and unsustainable workflow.
Goal
Redesign the filtering experience to:
- Offer a clear and intuitive interface
- Explain filtering logic and behavior
- Empower users to target and exclude data based on their specific needs
Discovery
We gathered insights by going through support tickets and discussions with the Customer Support team. We also conducted a UX audit of the existing filtering system.
From there, we identified key usability issues:
- Users were unsure if filters applied to the data itself or the contacts who matched the data criteria
- Users couldn’t exclude results with null values
- The interface lacked flexibility for different use cases, and affordances were unclear
Defining the new filtering rules
Redefined “Not equal to” behavior:
It now excludes all data that doesn’t match the selected criteria, aligning with user expectations
→ UX heuristic: Jacob’s law – users spend most of their time on other platforms.
This means our design should remain intuitive and align with users’ expectations on filtering behaviors.
Introduced an “Include null values” button: This gives users control when using exclusion filters. The button is only visible when relevant: when the operator “not equal to” is selected.
Added a new “Specify” command: For filters with multiple true values (e.g. donations, memberships), this clarifies whether the filter applies to the data or the contacts list.
- By default, filters apply to the list of contacts
- When “Specify” is selected, the next filter applies to the underlying data directly
Interface design
1
Visually group filters to distinguish between filter sets and individual filters
UX Principle: law of common region – elements are perceived as groups if they are sharing an area with a clearly defined boundary.
Implementation:
- Groups must share a common and bordered area
- Sub-filters share a common and distinct area
- Sub-filters are displayed with a wide padding, visually confirming their main data target
2
Add guidance
UX Principle: help and documentation – it’s best if the design doesn’t need any additional explanation. However, it may be necessary to provide documentation to help users complete their tasks.
Implementation:
- Improved the language guiding users at the start of the filtering journey,
- Added tips to explain how the filtering system works
3
Introduce the new “Specify” and “Include nulls” buttons in a clear but unobtrusive way
UX Principle: recognition rather than recall – minimize the user’s memory load by making elements, actions, and options visible.
Implementation: display these 2 action buttons in a straightforward way.
The question arose whether we should treat “exclude nulls” and “specify” as operators and include them in the list of available operators. However, based on the UX principle Recognition rather than recall, it would be more intuitive for users if these options appear contextually within the interface—only when relevant. This avoids adding to their cognitive load and requiring extra steps to remember that these are separate operators to use.
Outcome and next steps
Our Customer Support team no longer receives inquiries from users about the filtering system. As for the next steps, we’re currently working on introducing AI to translate user prompts into filters, improving multi-selection, and grouping selectors for a more intuitive experience.
