Feature

posted 24 Nov 2006 in Volume 10 Issue 3

Masterclass

Business taxonomy, part II

Taxonomies can be powerful tools. But too often, their complexity defeats the users they are supposed to help. The business taxonomy offers a simpler alternative.

By Zach Wahl

In last month’s article, we introduced the concept of the business taxonomy as an alternative to the major usability and maintenance issues that can accompany traditional taxonomies. We discussed how a business taxonomy is less detailed and more flexible. Because of those characteristics it tends to be much more intuitive for the average business user. In short, a business taxonomy sacrifices absolute granularity and rigorous classification for usability and sustainability.

It should be stressed that business taxonomies will not be appropriate for all applications, but the set of tools and systems primarily used or managed by individuals without a specialised background or education in the information sciences could strongly benefit from the business taxonomy concept. I include the vast majority of websites, portals and other content management systems in this category.

With that in mind, the question becomes: How can your organisation begin such a taxonomy design effort without falling into the same traps that others have? We must begin by identifying the primary risks and challenges associated with taxonomy design efforts.

Taxonomy design mistakes

There are three primary mistakes that organisations commonly make when designing a taxonomy. All three are related and result in many of the taxonomy usability, management and maintenance issues examined last month.

The first is failure on the part of the designers to understand why they’re building a taxonomy. It is therefore crucial that the following questions are asked and fully answered at the earliest possible stage:

Will it be used for front-end navigation, back-end metadata application, or both?
Will it be used to organise content in a publicly facing website, an internal document management system, or both?
Will its primary users be a small sampling of information professionals or a wide array of business users?

The potential answers to these simple questions will result in vastly different requirements for a taxonomy.

Unfortunately, as a result of an overarching confusion around what a taxonomy can and should be, many organisations never get to the point of even asking these questions – let alone hearing the answers. The design project often, therefore, fails before it ever really gets started. Why? Because organisations fail to understand the reasons why a taxonomy is required and the value it will provide.

The second mistake, related to the first, is designing a taxonomy without involving the end users – the people who will be expected to make sense of it and use it. Unfortunately, taxonomies are overwhelmingly designed by technologists and information professionals, who have a tendency to produce complex designs that go over the heads of the individuals who are supposed to use them.

Taxonomies are about categorisation, naming and context. Without extracting the viewpoint of the end users, organisations run the risk of misinterpreting not just the case for the taxonomy, but the very nature of it. Put simply, a truly usable taxonomy can only be built by those who will be asked to use it.

The third major mistake that organisations make is to build taxonomies that are too complex. To put it in the context of this article, organisations tend to build traditional taxonomies where business taxonomies are required. This happens largely because organisations rely on the old definition of taxonomies, which involves putting content into detailed and rigorous structures.

Often this occurs as a result of bad advice from traditionalists who would scoff at any taxonomy that is not at least 20-levels deep. As was argued last month, that level of detail will never be usable to most audiences. Even when organisations have asked themselves the appropriate questions, listened to the answers, involved end users and have set forth to build a usable business taxonomy, their efforts are often derailed by the complexity of the design process itself.

Furthermore, once underway, many organisations stymy their own design activities by trying to build for every possible eventuality and future requirement. They spend all their time asking the dreaded ‘what ifs?’ and never develop a product with which to work. Alternatively, they attempt to accommodate every potential topic, user and application and therefore end up with yet another excessively complex taxonomy.

The workshop methodology

The workshop methodology serves to counteract many of the aforementioned issues. It is designed to surface the true business value of a taxonomy, involve end users to the greatest extent and provide a simple starter taxonomy to be used as a jumping-off point for the larger project.

Given the user-driven nature of this effort, much of the success rests on convening the appropriate group of participants. Between 15 and 18 individuals is an ideal number, as the group is small enough to be able to facilitate effectively and ensure that everyone can be heard, but it is large enough to provide a representative cross-section of the various departments and hierarchies within the organisation.

The workshop should ideally be made up of the widest sampling of individuals from the end-user set. Identifying at least one person from each major department and geographical area represented by the organisation is ideal. Though information technology or information science representatives may be invited, it should be clear the effort is being driven by business users.

Much of the initial workshop should be focused on ‘baselining’ all the participants to ensure that everyone is united in their understanding of the project, the design best practices and the associated jargon and technological concepts. Baselining, of course, simply involves training the workshop participants in the basics of taxonomy theory and design so that they can all contribute from the same level of understanding. In short, it ensures that they are ‘all singing from the same page’.

Following the baselining, the focus should fall on four primary exercises. These exercises are intended to step the participants through the taxonomy-design process, getting them primed to take ownership of future design activities and firmly indoctrinating them in end-user focused thinking.

The first exercise is focused on the value of the taxonomy. The real key is to define why the workshop has been convened and what value is expected from the taxonomy once it is actualised. Although this sounds simple, the various workshop participants always have a diverse outlook on goals and justifications. Consequently, the result of this exercise serves as an important tool in bringing the various participants together towards a common goal.

The result of this exercise will also serve as an important ‘scopemanagement tool’ as the project proceeds – as decisions are made throughout the workshop and the project beyond, the initial value statement from this first exercise should always be considered to ensure consistency.

Next steps

In a natural progression, the next exercise concentrates on the end users themselves. No taxonomy-design project can move forward without a clear definition of the audience for that taxonomy. Complexity, naming and even the categorisation approach for the taxonomy are all driven by the type of end user.

It is not sufficient simply to name the corporate functions (for example, human resources, sales and manufacturing) or in terms of the perspectives of your end users (for example, internal or external), you must detail the spectrum of differences between them.

For instance, when asked to define the users for a typical intranet portal, the first response would typically be to name the departments in which these individuals work. This is valuable, but insufficient. We must also define all the other ways these users differ from each other.

These users may differ by the languages they speak, their level of education, their tenure at the company or in terms of their technical savvy. The list of differences is practically unending and thus the goal is not to complete it, but to gain an understanding of the various perspectives that must be considered in defining the taxonomy.

Through this approach, the ‘lowest common denominator’ of user types can be found. That is to say, if the taxonomy is intuitive to this user, then it will make sense to most other users too. In the case of an intranet portal, this may be a new employee on their first day. This exercise will result in firm guidelines around which the taxonomy can be built. Every idea or proposal should be followed by the question, ‘Does this make sense to our end users?’ If not, it needs to be re-done.

The next two exercises focus on finding the actual words that will comprise the business taxonomy. The first of these exercises serves as a gateway to the second. The important aspect of both is to coax individual ideas from each participant, then use the workshop as a forum to find the common themes between those ideas.

Using this approach, the various perspectives in the room can be brought to the surface, while identifying both common themes and lone ideas. Though the process may vary, one simple approach is to have each individual identify between seven and ten verbs that describe what the organisation does. The facilitator can then catalogue all the verbs for the room to discuss.

Typically, such an exercise will yield a number of repeats. Though it may seem monotonous, recording the repeated verbs is an important tool to reinforce themes within the exercise and help the group start to identify trends in thinking. The verb exercise, as a standalone, does not result in taxonomic terms. Instead, it helps users to begin identifying the nouns, or topics, which will comprise the top level of the taxonomy. For each verb identified, users should be able to follow it with various nouns. For instance, an identified verb may be ‘manufacture’, which could be followed by the noun ‘products’. These nouns are the next step in the taxonomy design process.

Throughout these discussions, it is important to remember that the onus falls on the facilitator to keep the discussion moving forward and to ensure that all participants are heard and their ideas are recorded with equal weight.

Using the verbs from the last exercise as a gateway in this step, participants should individually identify seven to ten topics – or nouns – that they define as of primary interest to the identified user groups. This method often helps to keep the workshop participants focused on topics.

As all workshop participants offer their list of topics, various themes should become apparent. For instance, as different participants may define a topic as ‘benefits’, some define it as ‘employee services’ and some define it as ‘human resources’, the core concept is the same and can therefore be pulled from the pile into a single term for the top level of the starter taxonomy.

Through this process of consolidation, typically half of the top-level terms for the taxonomy may be identified. The remainder of topics will come from further discussion around the more individualistic ideas put forth by the workshop participants. This effort will become frustrating and extremely taxing on the participants (and facilitator) but the end results will be worth the effort.

Not only will the participants obtain a top-level taxonomy on which to build, they will have adopted a manner of thinking and a methodology that will enable them to take ownership of the future business taxonomy design efforts. Indeed, this group of business users may evolve into a taxonomy team to drive future design and maintenance efforts. The same topic/noun exercise can be repeated within each category to define sub-categories at increasing levels of detail. The simplicity of this approach is what allows it to be so repeatable and so successful.

Risks

With that in mind, this approach does involve some risks. First, business users tend to think in terms of organisational charts and therefore try to sneak departmental names into the taxonomy of topics.

Users also tend to insert document types into the listing of topics. For instance, ‘forms’ or ‘policies’ are not topics and therefore do not belong in such a taxonomy. “In fact, there can be a form or policy about any topic. Although document types may prove valuable as values in an additional metadata field, they should not be included in a topical taxonomy.”

The workshop participants will also obsess over the naming of each individual taxonomy node. The onus falls on the facilitator to keep the taxonomy purely topical and to keep the discussion moving forward. Future user testing and follow-on methodology will help to solidify specific naming and further metadata strategy, but the greatest value the workshop participants can offer is in the identification of primary concepts from the perspectives they represent.

With the initial workshop complete, the organisation will be left with the top level or two of a taxonomy and a much greater understanding of the challenge that is before them. The final segment of this series will discuss how the organisation may continue to refine its starter taxonomy and, more importantly, how it may be developed over time to better serve end users. The last part of this masterclass will detail the role that governance plays within taxonomy design and maintenance.

About the author

Zach Wahl leads the knowledge management practice at Project Performance Corporation (PPC). He has led a number of major enterprise-information portal deployments for a variety of organisations, including aero-engine maker Pratt & Whitney, Columbia University, the US Department of Defense, the International Monetary Fund and the US Department of Energy.

Wahl has developed his own taxonomy and metadata design methodologies, authored a series of courses on portal knowledge management and development and is an internationally recognised speaker and trainer on the subjects of ‘e-governance’, portals, and taxonomy design.

He can be contacted by e-mailing zwahl@ppc.com.

Founded in 1991, PPC is a management and information-technology consulting firm that focuses on simplifying complex problems for top government and Fortune 500

organisations. PPC’s knowledge management practice has helped more than 120 public and private sector organisations successfully implement the full lifecycle of portals and other KM tools. www.ppc.com.

Best practice advice

Keep your audience in mind

Recognise that users may think about and look for information in different ways;
Understand your business practices and use the most appropriate categorisation method(s);
Use familiar vocabulary and organisational schemas to ensure a logical browsing experience.

Focus on subject-based categorisation

Strive for an instantive, noun-oriented approach
Objective;
Consistent;
Intuitive;
Extensible;
May require cultural change:

Corporate users tend to think along organisational, functional or document lines.

Be consistent

Try to use a single approach;
Use consistent vocabulary, thesauri;
Maintain consistent degree of generality in ‘sibling’ categories.

Make a long-term investment

Taxonomy development is an iterative and ongoing effort:

Respond to change: validate and modify regularly;
Invest in dedicated, long-term resources.

Initial effort must have foresight:

Establish a solid foundation;
Allow extensibility to accommodate new information;
Plan for iterative development.

Establish maintenance and governance processes;
Conduct regular (quarterly) taxonomy and content categorisation reviews.

Control depth and breadth

Depth:

A ‘flat’ taxonomy ensures that users can find information quickly;
Avoid deep taxonomies:

May frustrate users with too many clicks;
May indicate too much specification or too much information.

General guideline: Two-to-three levels deep.

Breadth:

A focused taxonomy ensures that users can easily ‘digest’ the scope of information;
Avoid over-broad taxonomies:

May frustrate users with too many initial options;
May indicate your categories are too specific.

General guideline: Between ten and fifteen top-level categories.