Faceted navigation can be very useful and a valuable part of a good taxonomy. Advances in computing power and CMS capabilities have made it easy to present users with a plethora of choices for narrowing their selections from a large data set. While it’s tempting to expose all the metadata that is available for site navigation, this is typically not the best option.
The same web-based design guidelines that apply to the rest of a site’s contents apply here — prioritizing placement of the most important content, removing information that is rarely needed, using progressive disclosure to reveal additional lesser-used features, matching users’ mental models, and providing users with limited choice sets.
I’ve spent some time recently reviewing/thinking through guidelines for facet usage. I’ve summarized them here.
- Because users typically won’t scroll too far to see a long list of facets, keep them as tight as possible. Some recommend limiting to 3 or 4 groups; others point out that the higher you are in the site hierarchy, the fewer facets you should display. So, let users categorically drill down to a place where they might be more likely to narrow the set by certain desired features before displaying numerous facet options.
- Put the most important facets for the data set in question at the top of your faceted navigation list. While this seems obvious, some e-commerce sites seem to display common facets in the same place throughout the site. For example, customer review ratings may always appear first, but other’s opinions might be much less important for a particular product set than for others.
- Make sure the facet groups you display can provide valuable input to a user’s decision process. For example, several sites that sell computers have a facet group for “Processor Brand”, with the only values being AMD and Intel. This distinction holds virtually no value for shoppers, because the important comparative information about the processor cannot be determined from brand name alone. More relevant metadata about the processor would be the speed, type, or even the full product name. (Note that brand name might be paid-placement by the vendor; if so, an additional, more informative facet would be necessary.)
- Collapse less important facets and facet values. If you have 15 facets for a data set and you feel that all the facets could have some use and don’t want to kill them completely, collapse facets by default and allow users to expand if desired. Do the same thing for facets that have a lot of values; show the most likely to be used values by default and hide the rest under a See All link or a collapsed tree node.
- Regularly assess analytics to see which facets are being used most often. Obviously the ones that are higher on the list and are not hidden will be used more frequently than others, but if you have facets highly placed that are still not used, they are good candidates for removal or demotion.
- Make sure facet values match users’ mental models. For example, check out the odd price ranges on qvc.com (example below). These ranges are obviously driven by some sort of algorithm that would make no sense to a user.
$349.00 – $680.00
$687.00 – $795.00
$799.00 – $940.00
$946.00 – $2276.00
- Indicate the number of results within each facet value next to the option. This helps users to know what to expect when they select a facet value.
- Consider using parametric search vs. faceted navigation when it makes sense for the data set. Parametric search is when users specify multiple search parameters up-front using a variety of UI controls to compose what is essentially a complex Boolean query. Buying a computer is a good example of this. While some shoppers might want to pick one or two facets to narrow their options, many will be interested in the combination of a variety of specifications. Though constructing something like this is possible using the standard left-side filter/facet list, most implementations make this very challenging for users to understand (the best use client-side refresh methods to update the data set without completely reloading the page, along with good state indicators). An in-page element can address this in a more straightforward way, as shown in the example from Amazon.com below.