kentoh - Fotolia
In a recent article on search-based applications and taxonomy, I defined website taxonomy. For those unfamiliar with the term, a taxonomy is a system of classification that enables systems like websites to be categorized according to topics and the like, and enables information retrieval.
In that article, I also explored how taxonomy works as a key information architecture tool to make website content more findable and expand the value of content through search-based applications. If you see the need for such a website architecture in your organization but are unsure how to build a taxonomy, this article outlines an eight-step taxonomy development process. These steps help crystallize the business purpose, the audience you're trying to attract and the kinds of content you need to categorize.
As in all development, it is necessary to understand the scope of the activity. A taxonomy development or taxonomy maintenance activity has three aspects (see Figure 1):
1. Business context. What is the business purpose for the taxonomy? Is it for a specific initiative such as document management or for content management more broadly? If for content management, is the content internally facing only or does the content involve externally facing websites that customers and third parties use? The taxonomy development may differ for internally versus externally facing content.
2. User community. What is the target audience for the content? What are the user profiles, and what are their information usage needs?
3. Content. What is the operational purpose of the content? Is it limited to team or departmental content or specific initiatives, or are there multiple types of content to be considered?
Once the scope has been defined, you can begin the taxonomy development process with these eight steps (see Figure 2):
1. Assemble the team. Typically the core team consists of business representatives who work with the content, an information manager or someone assigned to the information management role, a taxonomy specialist, and a technical subject matter expert who understands the constraints and opportunities of the target technical environment into which the taxonomy will be implemented. Having a representative who understands content governance, such as an information manager, is important.
2. Scope the problem. Which business areas are involved? Is it an enterprise problem or one affecting a specific business area? Where does the taxonomy need to exist? If core business entities are being modeled, such as clients, products and so on, where is the source of truth for those defined -- for example, is it in corporate CRM and ERP systems?
3. Define the problem in detail. Capture examples of content that need to be categorized in the taxonomy with business knowledge, content audit and possibly search logs.
Determine the profiles of those users who will interact with the taxonomy -- findability is a key consideration -- and ask how certain user roles look for content. A paralegal may want to find contracts by legal entity, a design engineer may want to find product specifications by product type, a financial planner may want to find financial forecasts by year. Ultimately the desired results will create a matrix of types of content against metadata characteristics. If the taxonomy is to support a search-based application, the techniques are the same but additional dimensions should be considered, including the relationships among the types of content that are likely to be stored in various content management sources.
4. Design the taxonomy. This involves either completing the matrix of types of content and mapping them with metadata, or defining word tag characteristics, ensuring either that metadata characteristics can be determined automatically by the system(s) as content is uploaded to them or that the user needs to define metadata characteristics from a predefined set of choices.
5. Develop and test the taxonomy. This involves soft testing using card-sorting techniques or hard testing by building out a working prototype and having focus groups interact with it. I recommend the latter. If your organization hasn't implemented a taxonomy, the concepts can be too abstract to visualize how users will interface with it, so seeing is believing.
6. Review your findings. Revisit the definition, design and develop stages, and work through potential changes based on testing. In my experience, building a taxonomy requires an Agile approach with a minimum of three iterations. And observe the 80/20 rule: A taxonomy can't be perfect. Whatever you come up with is part of a journey.
7. Deploy the solution. Once the final iteration is complete, complete the final development of the taxonomy and deploy it in target environments.
8. Transition. Implement governance and change management to support the effectiveness of the taxonomy, including its adoption.
Remember that any changes or updates to the taxonomy will need managing within a governance framework and that formal change requests will reinitiate the process again starting at step one.
In the next article in this series, I will cover some practical analysis and workshop techniques to drive out an initial, high-level taxonomy design.
About the author:
Jonathan Bordoli is a senior manager in Hitachi Consulting's Microsoft Platform Practice. Based in Chicago, he is responsible for architecting and delivering a broad range of solutions based on the Microsoft technology stack. Bordoli has more than 25 years of experience defining, designing and managing technology delivery across the full project lifecycle, with particular emphasis on delivery and adoption of content, collaboration, and process improvement solutions.
How analytics engines could -- finally -- relieve enterprise search pain
Why DAM systems aren't keeping pace with digital tasks
Modern Web content management design keeps context in mind