This is the first in a series of four blog posts about taxonomies. In this one, it’s my job to explain why what sounds like an incredibly dry topic really makes a difference. In succeeding posts, I’ll describe what makes a good taxonomy, provide a step-by-step approach to creating yours, and lay out some common problems we see with taxonomies in the wild.
First off: what are taxonomies and why do they matter? “Taxonomy” is a fancy word for a very familiar thing: any time someone drills down in a series of selections, or navigates down a tree, or browses by category, they’re using a taxonomy. Biologists classify all life forms into a taxonomy of species. The Dewey Decimal system used by many libraries is a taxonomy. Taxonomies are useful because they break up a broad topic area into ever more precise subdivisions or categories.
It used to be that librarians and information architects paid attention to taxonomies, and the rest of us could ignore them. Since the dawning of the Internet and the information age, no more. Most tools that support professionals and their customers use rely on taxonomies:
- Cases, incidents, and tickets are categorized in taxonomies. This helps organizations route cases to the right people, manage queues, and understand what drives their case volumes.
- Knowledge base articles are categorized in taxonomies. This allows users to browse for articles and filter search results. It also helps subject matter experts (“Knowledge Domain Experts” in KCS®) keep track of the content they’re responsible for: a knowledge domain is a taxonomy entry. If a product goes end-of-support and we want to archive its knowledge, we can bulk migrate the content tagged to it. And, taxonomies drive reporting. If I’m looking at the ratio of articles reused to articles created, for example, I want that analysis by product family or business, rather than across the whole KB.
- The self-service experience is driven by taxonomies. Browsing is another name for exploring information in a taxonomy. Options for filtering search results are a taxonomy. Case opening generally requires users to pick from a taxonomy.
- Customer communities comprise a set of forums, often organized into groups. These groups and forums are…you guessed it, a taxonomy.
If you look closely at almost any enterprise application, taxonomies are there, behind the scenes, organizing the work.
“What Could Go Wrong?”
And therein lies the danger. In most organizations, the taxonomies for each of these tools are implemented separately, by separate teams. (Not to even mention that Marketing has their own set, too.) So, case categories can’t easily filter knowledge search, knowledge domains and routing queues aren’t aligned, and you can’t restrict search to a particular community forum. In a recent taxonomy workshop, our client discovered that they had over ten competing taxonomies in play, and more in the works. This way lies a maintenance nightmare…and more importantly, a fractured customer experience.
Speaking of a fractured customer experience, the people who create taxonomies often, with the best of intentions, do so from an “inside-out” perspective. Taxonomies represent the organization: support teams, engineering teams, product components, queues, and the like. The names assigned to categories often reflect internal naming conventions, not the way customers think of things. For example, HR professionals might think of an Employee Stock Savings Plan (ESSP) as part of the Compensation branch of their taxonomy. But to an employee, it’s obviously a Benefit! Hiding ESSP information under Compensation might be technically right, but that’s no help to the employee who needs to enroll.
So taxonomies are ubiquitous, but they’re often inconsistent and don’t map well to customers’ perspectives. This leads to internal friction and a poor customer experience. In our next post, we’ll suggest what a better strategy looks like, and then how to get there.
 As an example of this, when then yahoo.com domain name was registered in 1995, Yahoo! stood for “Yet Another Hierarchically Organized Oracle.” “Hierarchically Organized” is another way of saying it used a taxonomy.
Brian G says
The biggest risk to a taxonomy is not setting a sufficiently high threshold for adding something new . Over time the tree needs to be pruned but it rarely is, so a low threshold means you wind up with a messy bush. I’ve found improvements by looking at all classifications with fewer than X (where X is ~1% of your item count) and forcing myself to merge those items into something more appropriate.
David Kay says
I think you’re 100% right. Kay’s second law of support is “a group of smart people sitting in a room will inevitably overcomplicate things,” and the corollary is, “too complex things will inevitably become more complex over time.”
In posts three and four, we’ll discuss more about how to avoid this, but your proposal is a stellar one.