Designing Search Experiences: Filters, Facets, and Result Relevance
On a marketplace client project, we initially treated search as a UI problem: build a nice input, show a dropdown of suggestions, done. Usage data told a different story — over 40% of searches returned zero results or ended in the user abandoning the session. The fix wasn't visual, it was structural: we had to work with engineering on fuzzy matching, synonym handling, and typo tolerance before any interface change mattered.
Once relevance was solid, facets became the real design problem. Too many filter categories up front overwhelmed first-time users; too few frustrated power users doing repeat searches. We settled on a progressive pattern: five common filters shown by default (price, category, availability, rating, location), with an 'more filters' expansion for the long tail of attributes that only a subset of users need. This came from watching session recordings, where most users touched at most two filters per search.
We also learned to show active filter state persistently, as removable chips above the results, rather than tucked inside a collapsed filter panel. Early versions required opening the panel to see or change what was applied, and users frequently forgot a filter was on, got confused by low result counts, and gave up. Chips made the applied state visible at a glance and let people remove one filter without resetting all of them.
Empty search results deserved as much design attention as populated ones. Instead of a flat 'no results found,' we show the nearest broader match — 'no exact matches for waterproof size 9, but here are waterproof boots in nearby sizes' — which recovered a meaningful share of what would have otherwise been dead-end searches. Result relevance and result framing turned out to be equally important; neither alone fixed the abandonment problem.
