Too many facets drown the primary content
Aliases: too many facets · facet crowding · panel dominance
What it is
Faceted navigation turns attributes into walkable edges. When there are too many edges, the result pane is shoved aside until objects can no longer be judged. Facet overload is not “the data model has too many dimensions.” It is the navigation panel consuming the visual and attentional budget that should have gone to the objects: twelve groups of values are scanned before the first item is seen. Hearst keeps repeating that the center of a faceted UI is the results; facets are the roads. When the road is wider than the destination, navigation has taken over.
This is not the same claim as “facets must be orthogonal.” Orthogonality is about whether dimensions entail each other. Overload is about how many edges are on screen now. Perfectly orthogonal metadata still drowns content if every internal field is promoted to a facet.
Why it happens
Each facet is a potential decision, and decisions cost attention. People form information scent from thumbnails, titles, and prices in the result pane; the facet pane offers the next constraint. When the scent source is pushed below the first screen, people start managing constraints—scrolling facets, expanding long lists, guessing which pane is worth a click—instead of comparing objects. The scent question flips from “what are these” to “how else can I cut,” and the task becomes tool operation.
There is a second layer. More facets lower the prior that any one of them will be used, and dilute count and rank signals. People assume “with this many options, the facet I need must be here,” spend on hunting the panel the time that belonged to the results, fail to find it, and conclude the collection has nothing—even when the object sits on page one. The miss is charged to content; the cause is panel width.
Studying it
Measure allocation between panel and results, not whether facets exist in the model.
- Paradigms: the same lookup, varying how many facets are shown at once (say 3 / 7 / 15) or the width ratio of facet pane to result pane; eye tracking or first-click location marks which side took attention. Work on facet selection and display cardinality (Koren, Zhang and others) follows this line.
- Independent variables: number of visible facets, values expanded per facet by default, how many complete result cards fit above the fold.
- Dependent variables: whether the first click lands on a facet or a result, time to the target object, false reports of “nothing here,” subjective “surrounded by options” ratings.
- Methodological note: wide lab monitors hide overload. Use the target viewport. Stashing rare facets behind “more” changes the visible set; score “facets in the model” and “facets on the first screen” separately.
Where it stops holding
Operators of dashboards and warehouse explorers treat facets as a query language; many panes are power, not noise. Overload mainly hits casual lookup, retail, and public collection UIs. Tiny collections (a few dozen items) have a short result pane already, so extra facets cannot drown much; the problem shifts to empty panes and meaningless counts. Speech and screen readers have no fold: overload is how long the facet list takes to speak, and the fix is skippable regions, not a narrower column.
Applying it
- Keep first-screen facets to the few people actually use as a first cut (often 3–7). Put the rest under “more facets,” ordered by query logs, not by the internal field list.
- Guarantee that the target viewport shows several complete objects. The facet pane may collapse; the result pane must not be pushed below the fold.
- Truncate long value lists by default; “show all” beats dumping a hundred brands on open.
- Verify by screenshotting the real device width and counting complete result cards. Zero, or a sliver of one card, means facets have drowned the content. Then watch whether someone uninvolved clicks a facet or an object first.