Reducing filter clicks in a data-heavy application

1. The challenge

2. The strategy and selection

To resolve this efficiency bottleneck, I evaluated three distinct architectural patterns:

• Option 1: Batching button.Keep the existing dropdown menus but add an explicit “Apply filters” button to delay network calls. Rejected: this solved the network spam but did not reduce the high click count required to open and close multiple menus.
• Option 2: Advanced visual query builder.Implement a comprehensive, nested boolean drag-and-drop query UI. Rejected: over-engineered for this product. The analysts did not require deeply nested AND/OR grouping logic; they needed speed.
• Option 3: Hybrid search bar (chosen).Introduce a text-based, keyboard-driven query bar underneath the existing visual filter chips.

Why I chose option 3: it offered an advanced express lane for keyboard-proficient power users to type entire multi-filter queries in seconds, while safely preserving the familiar visual dropdown chips for casual users.

3. The implementation

I deployed an inline, text-based search bar that acts as a flexible editing canvas. The frontend architecture functions as follows.

Guided autocomplete and a small grammar

• Commas signify OR operations within a single field.
• Plus signs (+) signify AND operations between different fields.

status: to-do, in-progress + assignee: john

Decoupled parsing and validation

The text string is purely a layout mechanism. The client application instantly converts the text into a strongly typed JSON array of objects, which serves as the uniform source of truth:

[
  {
    "filterName": "status",
    "operator": "is",
    "values": ["to-do", "in-progress"]
  },
  {
    "filterName": "assignee",
    "operator": "is",
    "values": ["john"]
  }
]

Old flow

Open Status → Select → Close (table updates) → Open Assignee → Select → Close (table updates)

New flow

Type query string → Press Enter (table updates exactly once)

Fault-tolerant constraints

• Typos.Typing statuz simply clears the suggestion list and disables submission without wiping out the user’s progress.
• Invalid values.Typing an unrecognised value like status: foo flags the specific token with a warning icon (△), blocking the API request while letting the user cleanly edit the mistake.
• Syntax breakage.Forgetting a separator (for example, missing the +) treats the input as a single unfinished string fragment, safely preventing a broken query submission.

export interface FilterToken {
  filterName: string;
  operator: string;
  values: string[];
  isValid: boolean;
  errorReason?: string;
}

export interface FilterToken {
  filterName: string;
  operator: string;
  values: string[];
  isValid: boolean;
  errorReason?: string;
}

// Simulated valid metadata maps for instant local validation
const VALID_FILTERS = ['status', 'assignee', 'due date', 'activity name'];
const VALID_VALUES_MAP: Record<string, string[]> = {
  status: ['to-do', 'in-progress', 'done'],
  assignee: ['john', 'sarah', 'michael'],
};

export function parseQueryString(input: string): { tokens: FilterToken[]; isQueryValid: boolean } {
  const trimmedInput = input.trim();
  if (!trimmedInput) return { tokens: [], isQueryValid: true };

  // 1. Split into individual blocks by the '+' separator
  const filterBlocks = trimmedInput.split('+');
  const tokens: FilterToken[] = [];
  let isQueryValid = true;

  for (const block of filterBlocks) {
    const cleanBlock = block.trim();
    if (!cleanBlock) continue;

    // 2. Syntax Breakage Check: Catch missing '+' separators
    // If a block contains space-separated key-value pairs without a colon grouping them correctly
    // (e.g., "status: to-do assignee: john"), flag it as a broken syntax token.
    const colonCount = (cleanBlock.match(/:/g) || []).length;
    if (colonCount > 1 || !cleanBlock.includes(':')) {
      tokens.push({
        filterName: cleanBlock,
        operator: 'is',
        values: [],
        isValid: false,
        errorReason: 'Syntax Error: Missing "+" separator or malformed criteria.',
      });
      isQueryValid = false;
      continue;
    }

    // 3. Extract the Filter Name and Raw Values
    const [rawName, rawValues] = cleanBlock.split(':');
    const filterName = rawName.trim().toLowerCase();

    // Check if the filter name itself is valid (e.g., catching typos like 'statuz')
    if (!VALID_FILTERS.includes(filterName)) {
      tokens.push({
        filterName,
        operator: 'is',
        values: [],
        isValid: false,
        errorReason: `Unknown filter column: "${filterName}".`,
      });
      isQueryValid = false;
      continue;
    }

    // 4. Split and clean values using the comma (OR logic)
    const values = rawValues
      ? rawValues.split(',').map(v => v.trim()).filter(Boolean)
      : [];

    if (values.length === 0) {
      tokens.push({
        filterName,
        operator: 'is',
        values: [],
        isValid: false,
        errorReason: 'Filter requires at least one value.',
      });
      isQueryValid = false;
      continue;
    }

    // 5. Value Validation (e.g., catching 'status: foo')
    const allowedValues = VALID_VALUES_MAP[filterName];
    const invalidValues = allowedValues
      ? values.filter(v => !allowedValues.includes(v.toLowerCase()))
      : [];

    if (invalidValues.length > 0) {
      tokens.push({
        filterName,
        operator: 'is',
        values,
        isValid: false,
        errorReason: `Invalid value(s) found: ${invalidValues.join(', ')}`,
      });
      isQueryValid = false;
    } else {
      // Token is perfectly valid
      tokens.push({
        filterName,
        operator: 'is',
        values,
        isValid: true,
      });
    }
  }

  return { tokens, isQueryValid };
}

4. The impact and results

Shifting to a keyboard-driven batch workflow yielded immediate performance and interaction dividends:

• 66% reduction in clicks.Complex queries requiring three distinct filtering criteria dropped from 6 interaction clicks down to just 2 (focusing the bar and hitting Enter).
• 50%+ reduction in API load.Multi-filter query generation dropped from multiple consecutive data requests down to exactly one server request per search sequence.
• Zero disruption to casual workflows.Because the query bar sits parallel to the existing chip menus, standard user adoption remained stable while power user processing speeds accelerated.

5. Key takeaways and lessons

What I learned

Uncoupling the textual "editing surface" from the structured JSON state was a massive win that kept backend processing incredibly clean. However, engineering the search bar to be completely fault-tolerant was a massive technical task.

Allowing users the freedom of an open text area meant my frontend validation layer had to perform heavy lifting. I had to ensure that typos or broken syntax didn't cause destructive UI behaviors like wiping out user progress or prematurely executing broken requests. Writing a resilient tokenizer that gracefully flagged inline errors (like status: foo ⚠) without rewriting or deleting the user's active workspace required meticulous input state isolation and complex verification workflows. Keeping the query grammar flat was the only thing that kept this validation loop maintainable.

What I would do differently next time