Filters and Faceted Browse
Narrowing a large set by attributes, without stranding anyone at zero results.
The problem it solves
People often cannot name what they want but can rule things out. Filters let them cut a large set down by the attributes they do have opinions about.
Search takes a description. Filters take a set of constraints. They solve different halves of the same problem, and a catalogue of any size needs both, with the filters reflecting the search and the search respecting the filters.
Rules that prevent most filter failures
- Show counts beside every option. A filter that leads to zero results should say so before it is clicked.
- Never offer an option that would empty the set, unless the count next to it reads zero.
- Apply filters immediately. An Apply button adds a step and makes exploration expensive.
- Keep applied filters visible as removable chips above the results, so state is never a mystery.
- Put the filters people actually use at the top, based on real usage rather than the order of your database columns.
- Encode the filter state in the URL, so a filtered view can be shared, bookmarked, and returned to with the back button.
Combination logic matters more than it looks. Options within one facet should be OR, so picking two colours widens the set. Options across facets should be AND, so colour and size narrow together. Getting this backwards produces results that feel random, and users blame themselves rather than the logic.
Filter state that confuses
- No results found. Try changing your filters.
- Filters (4)
Filter state that guides
- No items are under 50 dollars in Large. 14 items are under 50 dollars in Medium. Clear size filter
- Under 50 dollars x In stock x Large x Blue x Clear all
On small screens, filters compete with results for the whole viewport. A bottom sheet that shows the result count live as options are toggled preserves the feedback loop that makes faceted browse work. A full-screen filter page that hides the count until submission does not.
Worked example
A hypothetical facet cull
A marketplace ships eleven facets. Usage data shows three of them carry nearly all interaction and one has never been opened on mobile. Moving the long tail behind a More filters disclosure would reduce the initial choice load. The risk is that a facet used by a small, valuable segment becomes invisible, so the change is worth checking against segment-level behaviour rather than the average.
When it fits
- Items carry structured attributes that buyers genuinely have preferences about.
- The result set is large enough that narrowing beats scanning.
- You can compute live counts per option without making the page crawl.
- Users come to compare within a category rather than to retrieve one known item.
When it backfires
- Every attribute becomes a facet, which produces choice overload at the exact moment the user wanted things simpler.
- Counts are missing, so people walk into empty result sets and back out again.
- Filter state is lost on back navigation, which punishes exploration and teaches people to open everything in new tabs.
- The underlying data is inconsistent, so filtering by an attribute silently hides items whose field was never filled in.
Products using it
Amazon
Shows live counts next to most facet options and keeps applied filters as removable chips at the top of results.
Zalando
Uses a mobile filter sheet that updates the result count as options are toggled, before the sheet is dismissed.
Linear
Encodes issue filters in the URL, so a filtered view can be pasted into a message and opened in the same state.
The psychology under it
The takeaway
Counts on every option, filters applied instantly, and state in the URL will fix most faceted browse.
Finished the teardown? Bank it and the day counts toward your run.