Now that we’ve seen why taxonomies are important, it’s time to discover what makes for a good taxonomy. Effective and useful taxonomies have the following properties.
Common Across Systems. Many enterprise applications require taxonomies to work properly. Since these enterprise applications are managed by different groups, it’s natural that each taxonomy will start out different and evolve to be more different over time. This is a nightmare for usability, reporting, and managing business processes! Create a Control Board that’s charged with governance of taxonomies across teams and systems. Only allow differences across systems when the board agrees there’s an extremely compelling business reason. (I’ve rarely heard one.) However, it’s OK if some systems only implement part of a taxonomy—just the top level, for example, or a subset of top-level items and their children.- User-Centered: Designed Outside In. This is so easy to say, but so hard to do. Because people typically build taxonomies for an enterprise application, they focus on the business processes: teams, organizations, functions, support queues. Unfortunately, those may not mean anything to your customers. So if taxonomies are exposed to your customers (in a web information architecture or browse trees, as search filters, as case topics, in a phone tree, or any other way) they need to be designed from the customer’s perspective. Card sorting is a fantastic approach to getting your customers or other end-users involved in the process and capturing their perspective.
- Maps to Business Needs. Although taxonomies should be designed from the ultimate user’s perspective, they also need to accomplish their business goals…for example, routing a customer case to the right team. This can often be done by carefully mapping the taxonomy elements to an internal structure such as a team or a queue. Ideally, the taxonomy will be detailed enough that the mapping is unambiguous. If not, automation (text analytics), contextual clues (which web page the customer was on), or human intervention will be required.
- As Simple as Possible. Einstein is quoted as saying, “Everything should be made as simple as possible, but no simpler.” This is a good rule for taxonomies. Our observation is that when you get a group of smart people in a room working on taxonomies, they always overcomplicate them. For example, they’ll add a third level (or more), or tens of options that the poor user will have to choose among. Push back! Resist! Challenge any additional level of detail that doesn’t have a compelling purpose. Your taxonomy governance board can really help here, as can an outside expert. A commenter on the previous post noted that he periodically looks for any node that contains fewer than 1% of the total number of items and forces himself to merge that node with another. This is a fantastic practice.
- (Reasonably) Balanced. One sign that something is amiss is if some top-level categories have two or three subcategories, while others have twenty or thirty. The real world (as perceived by customers) doesn’t always map into tidy rules of thumb, like every parent node should have 7±2 children, for example. But very long lists (say, more than 12-15) are hard for users to select from, and very short lists often make navigation harder. There are exceptions, of course…states, and other unambiguous long lists can be presented alphabetically.
- About One Thing. A common challenge we see is taxonomies that mix different kinds of ideas into a single tree. (A confession: when I see this my inner child always wants to sing “One of These Things is Not Like The Others.”) For example, taxonomy might include both subcomponents, like modules in a system, and features. Or a taxonomy might go from product family to product, and then to what the user is trying to do: install, configure, troubleshoot, etc. This inevitably confuses users, even if they don’t consciously know why. The meaning of going from parent to child should be the same everywhere in the tree, and the nature of parents and children should always be the same. A taxonomy with different types of things in it can often be usefully replaced with multiple taxonomies working together.
- Tested. As with any other user-facing design, taxonomies need to be tested with users and refined. Full stop.
Now that we’ve discussed what makes a good taxonomy, in our next post we’ll discuss practices for creating and maintaining one.
