The Command Filter System

The Command filter work: a basic filter drawer, advanced filter panels building rules such as "Tags includes any Buyer, Seller", and design-system specifications for tag chips and menu states.

Following the initial launch of the Contacts application, user feedback indicated a clear need for enhanced search and filter capabilities. Agents required action-oriented views of their database, but the existing filter drawer relied on a patchwork of legacy components that were not built to support advanced rule-building.

When advanced filters became a priority, my PM and I took the opportunity to modernize the entire filtering architecture. With our development team ready to build and our new XDS design system primitives recently published, we had a window to replace the legacy filters with a modern, platform-wide standard.

This study outlines how I defined and designed the filter patterns and components in coordination with the XDS design system.

Designing advanced filters

My goal was to provide access to advanced logic without overcomplicating the basic filtering experience. After benchmarking against other real-estate CRMs and modern enterprise applications, I evaluated three primary approaches:

Two filter drawers side by side. In the first the Advanced toggle is off, showing plain Status checkboxes; in the second it is on, and the same field has become a rule row with an operator menu offering is any of, is all of, is not any of and is not all of. — **Mode-Based** — advanced filtering as a distinct mode, separate from the basic drawer. One or the other.

The Integrated approach, with advanced rule building placed inside the basic filter drawer. — **Integrated** — users create advanced rules from within the basic drawer. Assumes simultaneous application.

The Unified approach, where every filter exposes advanced options and basic logic is simply the default. — **Unified** — filters always offer advanced options. Basic logic chosen by default.

While the Integrated and Unified options offered more visibility, they risked burdening users who only required basic functionality. I recommended the Mode-Based approach. It was the least disruptive path and could evolve into the other approaches later if needed. It also allowed us to ship a standalone basic filters experience across the platform.

Translating complexity

A core design challenge was aligning advanced logic functionality with user mental models. While KW agents had clear use cases for advanced filtering, they (generally) did not operate in code. Early research showed our agents preferred when filters read as natural language.

I opted for a design that allowed the user to construct rules by filling in sentences. A horizontal layout aligned with the reading model and gave the vertical space necessary to stack three or four complex rules without excessive scrolling.

The wide desktop filter layout, with several natural-language rules stacked without scrolling. — A wide layout keeps three or four complex rules readable at once.

I defined the conditional options for every type filter in the Contacts application — from date-based logic (within last/next) to multi-select groupings (includes any, includes all). I maintained comprehensive documentation for reference in stakeholder reviews and as product requirements.

The full conditional-logic specification, defining the operators available to every filter type in Contacts. — I used local Figma components to keep all designs and documentation accurate as we received feedback and updated copy.

Building the system

Component and pattern documentation

While designs for the advanced filters were refined, the Contacts team started building the basic filter components. Beyond delivering filters for Contacts, we committed to creating a component library that other Command teams could use in their applications.

I organized the basic filtering UI into its building blocks and documented requirements for over 15 components, including interaction specs and design rationale. Some examples below:

FilterPanel — multi-selection documentation

Contacts filters

Once the general components were in place, we used those to build the Contacts filters. I provided an additional 22 pages of requirements documentation for each basic filter and the full advanced UI. Some examples below:

System impact

The new Contacts filter experience successfully launched with 90% user satisfaction, but the true impact was the pattern’s adoption across the platform.

We built the components in a separate Storybook while the XDS team gained the capacity to integrate them. Product teams pulled from the Contacts repo for two years before it became an official standard. By the time XDS officially migrated these components into the library, they were already well-established across Command.