Filter chips that don’t fight you

Data-heavy products live and die by their filters. Ours had a problem: two dashboards each carried their own copy of the filter chips. They had started from the same code and drifted. One closed on Apply, the other didn’t. One returned focus to the chip, the other dropped it on the page. Users noticed, even if they couldn’t say what was wrong.

I moved the chips into our open-source design system so there would be one implementation. Before writing code, we had to agree on behaviour.

The rules

• One chip, one filter. A chip shows the filter’s name and its current value (“Status: Settled, Pending”). You can read the state of the table from the chips alone.
• Apply and Clear both close the chip. A chip is never left open in a half-applied state. If you changed your mind, Clear puts the filter back to “any” and gets out of the way.
• Only one chip open at a time. Opening a chip closes the others. A group component owns which chip is open.
• Focus goes home. After Apply, Clear or Escape, focus returns to the chip that opened, so keyboard users don’t lose their place.
• Escape closes everything.

Here they are over a small table of sample payments:

What went into the library

Seven chip types (select, single select, date range, calendar date, number range, text and month range), a group that manages which chip is open, and the table surface around them: a card with a toolbar and footer, a column manager, copyable cells and a card list for narrow screens that shares the same pagination. Each came with tests.

What changed for the dashboards

Both apps deleted their local copies and imported the shared one. The next new table in either app got the same filters for free, with the same behaviour. That’s the quiet payoff of a design system: not prettier screens, but fewer slightly different versions of the same thing.