I’ve given a rule-of-thumb of 3-8 facets to create in a faceted taxonomy, but it’s not that simple, and there are various factors to consider. Creating facets is an assignment in the online taxonomy course I teach, and a student recently submitted good set of facets with sample terms, but there were 12 of them. So, why might that be too many facets?
Consider the users.
Are the users internal trained employees who deal with content, most or all of the employees of an organization, external but repeat users such as partners or researchers, or the general public? Internal employees, especially those who are content managers or digital asset managers, who receive some training to become familiar with the facets, should be able to handle any number of facets. It is their job to classify and/or retrieve content by their facets, so they should have the time and inclination to go through a long list of facets. A broader cross-section of employees or external repeat users may have access to documentation but not read it, will likely not be trained, and are often more rushed when they deal with content, so a shorter list of facets would be more suitable. Finally, the general public is likely to use only facets that are easy to understand and fit into the window display (not requiring scrolling), so a relatively short list of facets is recommended for them.
Consider the content.
In addition to considering the shared attributes of the content, as you cannot create more facets than conceptually exist for the content, you need to consider the volume of the content. A relatively small collection of content items or assets does not need as many facets as filters than a larger collection of content does. If users select a term from each facet, they should not be getting zero results or just one or two items too often. Remember, the main use of facets is to filter and limit results down to a list that can then be easily browsed. If the user retrieves only one or two results, however, they will likely consider the search as too narrow and try again to broaden it.
Consider the user interface.
Sometime the taxonomy has influence over the user interface design, such as when it’s an internally designed research portal, but often content management system do not offer much flexibility in how facets are displayed. The first thing to consider is how many facets will be displayed by default in the initial screen view (without scrolling) in the most commonly used devices. If facets can be collapsed to show only the facet names and not any values/terms within them, then a greater number of facets can more easily be included. Hiding the values, however, might not be desired, since the display of sample values makes it clear to the user what the facets are for.
Consider what constitutes a facet or filter.
What may be considered a “faceted taxonomy” is only a subset of all the possible metadata properties of the content. Some of the other, default non-taxonomy metadata (such as date, creator, file name or title, or file type) may also be desired as end-user filters alongside the taxonomy facets, which then further increases the number of filters or refinements displayed to the user, who sees no difference between taxonomy facts and non-taxonomy filters.
There is no strict definition of a “taxonomy facet.” I would say it is a facet whose values or terms must be created by a person, such as a taxonomist or metadata architect, rather than those that are system-generated. In addition, taxonomy terms are those that must be tagged to the content, rather than already being a part of content. For example, if File Format is based on the file extension, then it is already part of the content and need not be “tagged,” so it’s not a taxonomy facet by my definition.
A faceted taxonomy is more, though, than a single facet of topics alongside other non-taxonomy metadata. The idea behind creating a faceted taxonomy is to split up what could be a large hierarchical taxonomy into different aspects. For example, instead of a term Business service agreements that is in a hierarchy narrower to both Vendor contracts and Business services, you could have just the term Vendor contracts in the Document type facet and Business services in the Business type facet, and the combination of the terms from each facet will suffice.
Faceted taxonomies, more so than hierarchical taxonomies or thesauri, need to consider the factors of users, content, and user interface when it comes to their design.