Having said why it’s important to get taxonomies right, and what makes a good taxonomy, I should let you know how you can do taxonomy design on your own. In our taxonomy workshops, we facilitate organizations through this design process:
- Take an inventory. What taxonomies are currently in use by marketing, the marketing website, user communities, the self-service website, case management, knowledge management, content management, downloads, and more? How do they overlap with each other, or how are they co-managed? Are there non-product taxonomies?
- Define business goals. What does success look like? What functional objectives does our taxonomy, or do our taxonomies, need to serve? How will we evaluate our new taxonomies’ performance relative to those objectives?
- Evaluate current taxonomies. In what ways, if any, do our current taxonomies fulfill those business goals? Where, specifically, do they fall short? What is it about the structure or nature of our taxonomies that causes these shortfalls?
- Define the strategy. Will a single taxonomy drive case tracking, KM, communities, and self-service, content, and downloads, or do we need multiple? If so, how are they synchronized? Do we expose different levels to different audiences or through different channels? (For example, we might ask support engineers to select a specific product version in case management, but only enable product name in KM?) Are there multiple orthogonal taxonomies (e.g., product and task?)
- Consider the technology. What technology features or limitations do we need to consider when defining taxonomies? Some popular cloud-based tools have hard restrictions on the number of taxonomies an organization can implement, and how many elements each can have. Since these resources are shared across the enterprise, it’s important to know your constraints.
- Plan for migration. How do we move from today’s model(s) to a common future state? What can be automated? What can be done on demand rather than in advance?
- Bring customers and users into the conversation. How will we test our ideas with support engineers, customers, and other taxonomy stakeholders? How will we use card-sorting and other exercises to make sure that we’re providing an outside-in view to customers, rather than exposing our organization to them?
- Simplify. Our experience is that many organizations, with the best of intentions, overcomplicate taxonomies. How can we defend against adding complexity that doesn’t bring corresponding business value?
- Govern and maintain. What do we do when Marketing changes their taxonomy’s structure, creates new multi-product solutions, or simply changes a product name? What happens after an acquisition? What is the governance model—who has to sign off on changes, and how do those changes get implemented in technology, and in updated metadata for knowledge and other resources? We strongly recommend a Board with final approval (and veto power.)
- Take the next steps. How do we put our decisions into action?
We find two days to be a good length of time to devote to this process, especially if people have done their homework in advance. There’s still work to be done when you leave the room, but you should be aligned on the big picture and ready to execute.
Let us know if you’d like to collaborate on your taxonomies!
