Faceted Filter

Sorting things into branches stays tidy only when each thing belongs in exactly one place. Real items usually belong in several at once. That's the scene where nobody can decide whether last week's meeting notes go in the team folder or the project folder. Put them in either and whoever looks in the other one comes up empty; copy them into both and which version is current becomes the next problem.

A second problem stacks on top as the count grows. With 1,200 documents, even a well-cut menu leaves 200 items inside the last branch, and from there the user is scrolling. There is a search box, but search assumes you know the name of what you want. "The spec Noa wrote last month that still hasn't been reviewed" is remembered as a set of conditions, and there is no query string for that.

Faceted filtering solves both at once. Instead of assigning an item to one place, it hangs several attributes on the item and lets the user stack whichever conditions matter. Rather than handing people a path, it lets them build one out of what they already remember.

Every item carries several attributes, and the list keeps only what satisfies all the conditions the user has picked. Building the screen means deciding five things.

1. Which attributes to expose. For a document list: author, document type, date range, status, team. Each of these attributes is a facet. Three or four typically get real use, and past seven the picking itself becomes work.
2. How conditions combine. The widely used rule is that values within one facet match if any of them do, while separate facets all have to match. Select both Mia and Theo under author and "in review" under status, and what remains is documents written by either of them that are in review.
3. Whether to show counts. Marking the author list with Mia 180, Theo 64 tells people the size of a result before they commit to it. Values that would yield zero get dimmed or hidden. Without counts, users learn they chose wrong only after the blank screen arrives.
4. How to surface the active conditions. Show them across the top with a way to remove one at a time or clear them all. Three stacked conditions are enough for people to lose track of what they set.
5. Whether conditions live in the URL. They should, so a filtered view can be sent to a colleague as a link, and so opening one document and hitting back returns to the same narrowed list.

The narrowing is stark in numbers. From 1,200 documents, picking an author leaves 180; adding the last 30 days leaves 24; narrowing status to "in review" leaves 6. Three clicks took 1,200 down to 6, and those 6 are a combination no path through a branching menu could ever gather onto one screen.

It fits any list that is long and whose items carry attributes. Product listings are the most familiar case, stacking size, color, price band, and brand. Job boards do the same with role, location, and years of experience; property sites with floor area, price, and floor number. In work tools, document lists and issue lists run on it.

Three things are worth checking before adding one.

1. The item count. At around fifty items, sorting on one screen beats filtering. Picking conditions costs more than scanning does.
2. Whether the attributes are actually populated. This is where the approach fails most often. The screen ships, half the documents have no team value, and that half vanishes every time anyone filters by team. Filling those values usually falls to users, so what has to be decided alongside the screen isn't the filter — it's when and how the value gets captured.
3. The width available. A column running down the left has nowhere to go on a phone, so it typically becomes a button that opens a sheet from the bottom.

None of this competes with navigation or search UX; they sit side by side. A menu gets you into a broad branch, a query jumps you straight across, and filters narrow whatever you landed in. That's why filters so often live next to a results page.

"Let's make these filters faceted and start with just author and date."

A request to move from picking one option at a time to stacking conditions.

"That facet has no values filled in, so shipping it now gives you empty results."

The objection is about the data, not the screen.

"There are nine filters and people use two of them."

Most of what's exposed goes untouched, so trim it.

The conversation came up at Pagedeck during a rework of the document list. Past 1,200 documents, support tickets about not being able to find things went up, and Noa, the product designer, drew a screen stacking four conditions: author, date, status, and team.

Theo flagged the team value. Team isn't chosen while a document is created — it's a tag applied afterward — so only about 30 percent of documents carried one. Ship that and filtering by team drops 70 percent of the library. What the two of them settled on was to leave team out of this round, change document creation so the team gets attached automatically, and revisit in three months.

The most common mistake is assuming more conditions is more helpful. People search by different criteria, so opening everything up feels generous. But on a screen with nine conditions listed, users touch two, and the rest only add scanning cost. More conditions also make zero results easier to reach, so a user three conditions deep hits an empty list and starts over. Expanding the three or four that get used and collapsing the rest works better.

Treating it as a screen component is the other frequent slip, since it does look like standing a few boxes next to a list. Making it work requires every item to carry its attribute values, and those values need the consistent names that labeling settles. Write the same state as "in review" on some documents and "review" on others and a single condition splits the list in two. Most of the work behind this screen is cleaning up data, and shipping without that cleanup means every condition leads to an empty state.