Catalogs with tens of thousands of items are where filter design gets genuinely hard. A user who can’t narrow results to a manageable set will leave, and a filter panel that’s misconfigured will lead them straight to an empty results page. Getting this right is an information architecture problem as much as a UI one.
Why Filter Design Is an Architecture Problem
Most filter failures don’t start in the interface. They start in how the underlying data is organised. A category taxonomy built for internal stock management doesn’t map cleanly onto how buyers think about products. Before touching layout or interaction, the design process needs to answer three questions: which attributes are user-facing versus operational, which attributes actually discriminate the catalog (not just which columns exist in the database), and which filter combinations will produce empty results.
Filters fail in two opposite directions. Too few, and users can’t narrow anything meaningful. Too many, and the panel becomes a form nobody fills in. Both failures look identical in session analytics, both registering as low filter engagement. They have different causes and need different fixes.
The Anatomy of a Faceted System
Faceted search lets users apply multiple independent dimensions simultaneously: category, brand, price, availability, and so on. Each dimension is a separate axis. Active selections narrow the result set, and the count beside each option reflects the narrowed pool, not the full catalog.
That live count is the mechanism that prevents dead ends. A user browsing winter jackets who ticks “waterproof” should see the result count drop to something realistic before they commit. If the count hits zero, either the taxonomy has a gap or that combination doesn’t exist in the inventory. Both are signals worth surfacing, not hiding.
Discrete attributes vs. range filters
Checkboxes are the right control for discrete values: brand, colour, material. Within a single dimension they’re additive (OR logic), and across dimensions they’re restrictive (AND logic). That gives you “Nike or Adidas” AND “waterproof” without requiring any explanation. It’s behaviour users already understand.
Range sliders work for continuous values like price, but they add friction. A dual-handle slider requires precise touch input on mobile and is harder to operate with a keyboard. In most interfaces, two number inputs with clear min and max labels are faster and more accessible. Reserve sliders for contexts where the shape of the range communicates something useful, like a delivery date window.
How Many Filters to Show
Every filter group you expose adds time before the first selection. The question isn’t “how many attributes do we have in the database” but “which attributes drive purchase decisions for this user at this point in the funnel.”
A practical default: show three to five primary filters without any interaction required. Put the rest behind a “More filters” affordance. Order by discrimination power. The filter that reduces a 50,000-item catalog to 2,000 items goes first. For most product catalogs, category and price do that work. Colour and brand come after. Customer rating matters in some categories and barely registers in others.
The filter panel that ships with fourteen open accordion groups is not a complete feature. It is an incomplete decision about what actually matters to users.
Collapsed accordions reduce visual clutter but carry a discovery cost. If a high-value filter is hidden in a collapsed group, a meaningful portion of users will never find it. Audit with session recordings before deciding which groups collapse by default. Assumptions about what users will look for are often wrong.
Active Filter State and Clear Actions
Once a user has applied filters, the interface needs to communicate clearly what’s active and provide a direct path to removing individual selections or clearing everything at once. Chips (removable tags) above the result grid handle this better than relying on the filter panel alone. Users shouldn’t need to reopen the panel to see what’s currently applied.
A “Clear all” control is not optional in a system with more than two active filter dimensions. On mobile, showing a count of active filters on the toggle button (for example, “Filters · 3”) prevents the common confusion where users don’t realise how heavily they’ve narrowed the result set.
This ongoing state feedback mirrors what good form design does: users need to see the effect of their choices as they make them, not only at the end. When someone applies five filters and gets zero results, the system should explain why and offer a path forward. Designing empty states covers that failure surface in detail, and the zero-results case from heavy filtering is one of the most common.
The Mobile Problem
You cannot solve mobile filters by shrinking the desktop sidebar. Three patterns are in common use: a full-screen drawer, a bottom sheet with a scrollable list, and a horizontal chip row pinned above the results.
The drawer or bottom sheet works for catalogs with many filter dimensions. Users tap “Filter”, configure inside the sheet, and apply. Showing the result count update while the sheet is still open previews the outcome and reduces the risk of applying a combination that returns nothing. Applied filters then surface as chips above the result grid once the sheet closes.
The chip row suits catalogs with three to five filters that don’t have sub-options, particularly where repeat users know what they need. It is faster. It fails for first-time users in unfamiliar territory.
Choose based on the actual complexity of your filter surface, not on which pattern looks simpler in a mockup. Simpler-looking UI that conceals necessary controls is not good design. It’s incomplete design with better polish.
Filters Alongside Tables and Navigation
Filters rarely exist in isolation. In dashboards and internal tools, filtered results typically land in data tables, where sort state, column visibility, and pagination all interact with the active filter set. Sort order should reset when a filter substantially changes the result set. Pagination should always return to page one when any filter changes. These edge cases feel like bugs when they’re wrong, and they usually are: they weren’t specced.
Filters also interact with site navigation in category-heavy catalogs, where a top-level nav selection pre-applies a category filter and the filter panel then shows secondary dimensions. That pre-applied filter needs a visible chip just like any user-applied one. Removing the category filter shouldn’t silently break the page.
How Strynal approaches filters and faceted search
Filter design is one of the places where a weak taxonomy becomes expensive to fix at the UI layer. The interaction patterns are well understood. The hard part is the data: which attributes are clean enough to filter on, which values need normalising before they’re surfaced, and which dimensions will generate so many options that they need a search-within-the-filter control.
Before building the panel, we work through the catalog structure with clients. That means identifying which filters map to real decision criteria, not just available database columns. From there, the interaction design follows logically rather than being bolted on top of an ill-suited data model.
Our UI/UX service covers the full scope: taxonomy review, information architecture, interaction design, and front-end implementation of the filter system. We have worked on catalogs across e-commerce and SaaS, and the patterns that cause friction are consistent.
If your catalog is growing and your filters are creating more confusion than they resolve, get in touch and we can identify where the gaps are.