Faceted navigation is an elegant and popular solution to the needle-in-a-haystack job of finding the information you want on big sites, and one that is widely used in digital publishing interfaces.
A facet is one feature of something that has many aspects. For example a facet of a car might be its colour, its engine size, the year it was manufactured, etc.
So far, so good. But there are significant wrinkles with most implementations that need ironing out. Let’s take a look at some illustrative examples.
1 The real estate problem
Here’s the Ocado shopping interface (click to see a bigger view).
But I can’t see all the facets in a group – and the ‘More’ link is quite weak. This is great news for those products at the top of the list, but lethal for any that fall off. How do we choose what goes at the top?
2 The facet type problem
The facet list gets harder to use the more types (category, temporal, numeric, geographical, etc.) you have in the same interface. And list ordering of the facets can get a little crazy if the same rules are applied to each type.
Here’s how ebay deals with it:
Categories are given priority, and each type of facet selector and display is designed according to its type and the perception of its use. To create space on the interface, other refinement options are collapsed.
3 The labelling problem
OK, so I’ve found a chair in my price range that will fit into my daughter’s dolls house, and the seller is near enough to my home. But did I find the very best chair? Or is it possible that other, relevant results got lost inside a category I didn’t explore?
Faceted navigation is very good at getting users closer to ‘better fit’ results, but it is also very good at losing results.
Because selecting one facet tends to exclude the others, items in categories that users overlook will be hidden – unless a polyhierarchical systems is used (and then each facet’s population grows bigger – see problem 1).
Think about your local telephone directory. You might be looking for a gas plumber under ‘G’ for ‘Gas’, while all the gas plumbers have actually chosen to advertise under ‘P’ for ‘Plumber’ – or even ‘W’ for ‘Water and Sewerage Services’. Telephone directories use ‘see also’ listings extensively to get round this problem.
4 The selection sequence problem
So here comes the big one. Selecting facets affects other facets. How do you design the interaction to cope with this? We can constrain the sequence of selection, but let’s consider the options:
One at a time – Each time a user selects a facet the search is re-executed and the whole interface is updated.
This might represent the best method of presenting users with accurate information, but with big datasets users can be left waiting for a long time and need to be locked out of further interactions while they wait.
One from each group – Users can select one option from each facet group.
This is great for the developers because the results don’t need to combine options or eliminate duplication. It’s great for designers too because the inactive options can just be removed from the display. But for users? What if you like yellow and blue? Users have to manually try out each combination.
Lots of facets, one at a time – Users select facets, in any order, and the interface responds to each choice.
This one looks great in a diagram, but what happens when it is implemented? Users are likely to consider and pick one facet at a time. Their choice restricts the options available at the next facet. This might be OK if they are looking for one particular result, but for browsing it is going to hide lots of results. The sequence of facet selection becomes critical.
Lots of facets, all at once – Users choose the facets to apply, and then apply them all simultaneously.
Not so good either. We are not really browsing by facets at all, just keyword searching with suggested terms. The onus is still on the user to guess which facet combination will yield results.
So there are four big challenges to be aware of with faceted navigation:
- stemmed category lists create a new market for real estate at the top
- presentation of controls on the interface needs care
- labels need to meet users expectations
- selection methods significantly effect the results
Faceted navigation is a great tool for discovery but, as with all tools, you need to be sure you are using the right one for the job. In the case of faceted navigation that means taking the users, the usage, the goals, the content, the budget, the timescales and the technology into consideration for each project and assessing whether this particular tool really makes sense for the objectives you are trying to fulfil.



Nice post. I’ve definitely been trying to deal with all these problems in the design of our new platform.
Another issue I often notice in user testing is that users dont notice the selected facet area, nor how to remove individual items (typically represented with an ‘x’, ‘undo’ or ‘remove’ label). People are quite comfortable using the browser’s back button, but this is lethal for them if they don’t realise that some of the facets are still selected.
Hello Harry,
I agree entirely with your comments about a user’s ability to ‘see’ selected facets and facet controls. Sensitive design and placement can help, of course, but it still feels like there are some movements needed in the way we approach this. I have a feeling that going back under the hood and looking at the way the data is being handled might be the solution.
Seth Early (and friends!) covered some of this ground in one of their recent webinars, Best Practices in Taxonomy Development for Faceted Search (http://www.earley.com/_February2009.asp). Not yet released (missed the live cast) but sure to be a good resource for anyone thinking about these issues.
Let me know how well you succeed with the Madgex build!