Taxonomy and Information Architecture Compared

There is considerable overlap between the fields of information taxonomies and information architecture. Both involve information organization, labeling, search, and findability. In some organizations the job roles and titles are combined. I previously blogged on “Information Architecture and Taxonomies,” observing that “information architecture” in name seemed to be declining while aspects of its practice continued to be strong, since it was an underlying theme in several of the talks at major taxonomy conference, Taxonomy Boot Camp in 2013.

Information Architecture Conference opening. Photo Marisela Meskus

This week, for the first time, I am attending in person the Information Architecture Conference, being held in New Orleans March 28 - April 1, so it’s been interesting to hear how information architects consider taxonomies.

How Information Architecture and Taxonomy Overlap

The fields of information architecture and taxonomy are related beyond the stated shared practices of information organization, labeling, search, and findability. 

When I give an introduction to taxonomies, I explain that a taxonomy is an intermediary between users and content to connect users to content by means of terms that the users understand and by the display of the terms in hierarchies, facet-filters, or type-ahead suggestions, which enable users to explore and interact with the taxonomy. This is clearly an aspect of information architecture. 

In my own career path, I discovered taxonomy and information architecture at the same time. I had been working as a “controlled vocabulary editor” and had the opportunity to work on an interdisciplinary team for a newly design information product. A user interface for school library research database included both a hierarchical taxonomy that was designed to fit with a particular user interface. 

At the Information Architecture Conference, I asked for a raise of hands of my session audience of how many had worked with taxonomies, and it seemed to be over 80%. At the conference, I met information architects who specialized in taxonomies, and taxonomists who had an interest and done some work in information architecture. Even though I identify as a taxonomist, I already knew a number of speakers at the Information Architecture conference due to the overlapping communities.

How Information Architecture and Taxonomy Differ

Information architecture is a discipline and a profession that is larger and more established than that of taxonomies. Although taxonomy work is growing, there are still more college courses on information architecture than on taxonomies, more books on information architecture than on taxonomies, and more people with “information architect” than “taxonomist” as a job title (based on LinkedIn searches). 

Listening to sessions at the Information Architecture Conference and having discussions with participants, I began to see a clearer picture on how the fields of information architecture and taxonomies differ.

The Information Architecture Conference brings together a community of professionals who share ideas and experiences. There is no comparable taxonomist community as taxonomy work, compared to information architecture work, tends to be done by those with different professional backgrounds: information architects, librarians, content managers, metadata architects, indexers, ontologists, etc. It’s telling that there is not just one conference at which I present about taxonomies but multiple. (Knowledge management, content strategy, knowledge graphs, and data science are the fields of conferences at which I have spoken about taxonomies in the past year.) The only conference about taxonomies, Taxonomy Boot Camp, is more of specialized track within the KM World conference, and aims to provide taxonomy best practices and case studies to managers and directors of content, product, or knowledge management. It is not really a forum for taxonomists to discuss topics of their profession, as the Information Architecture Conference is.

It seems that information architecture is more of a discipline and a field, whereas taxonomy is more of tool or system (although a very important one). In addition to information architects in organizations in various industries and consultants, the Information Architecture Conference includes professors and students in the field. By contrast taxonomy is not a field of study, research, or focus in academia. It is a focus area only in industry and consulting. Information architecture seems to allow more room for theory than does the taxonomy field. 

How Information Architecture and Taxonomy Are Related

From a "taxonomic" perspective, which is broader? For information architects, taxonomy is narrower than information architecture. There is no doubt that information architecture is broader in various ways, including content/information organization, design, user experience, and even organization of non-digital information spaces. For example, information architects are concerned not only with taxonomies to support searching and browsing for information, but also with content organization and navigation menu structuring in websites and in software user interfaces. 

Taxonomists, on the other hand, do not consider taxonomies as a sub-field of information architecture, but rather consider the two fields as adjacent and closely related. This is because the taxonomies that information architects create tend to be small, such as term lists for metadata properties or facets or as hierarchies to model menu navigation or site maps. Professional taxonomists tend to work on large dynamic taxonomies or thesauri that are used to tag/index and retrieve content or data in one or more systems, often where the user interface is already prescribed.

The related fields or disciplines are also different. Information architecture has a closer relationship with fields of design, user experience, sociology, and psychology. Taxonomy has a closer relationship with indexing/tagging, natural language processing, ontologies, Semantic Web technologies, and knowledge management. One related field shared by both information architecture and taxonomy is structured content, which was also a subject of presentations at this year's Information Architecture conference and the field of my next conference.

Navigation Schemes vs. Taxonomies

A navigation scheme for a website/intranet and a taxonomy are similar, but they are not the same. I had taken an interest in website information architecture, around 16 years ago, about the same time that I became familiar with the term “taxonomy” (although I had already been working for years as a “controlled vocabulary editor”), so I naturally related website navigation and taxonomy. In an earlier version of the online course I teach on taxonomies, I had even presented examples of website navigation schemes as examples of taxonomies. However, I also recall hearing early on in conference presentations of the consultant Seth Earley that a navigation is not a taxonomy. After more years of experience with taxonomies, I came to recognize that as true. Considering a website navigation structure as an example of a taxonomy is an oversimplification and could lead to poor taxonomy design.

I looked more closely into the comparison of website navigation and taxonomies in preparation to present at World IA Day Boston on February 22 (presentation slides PDF, presentation video). IA stands for information architecture. So, now I will continue with that line of observations here. This topic also follows another example of what a taxonomy is not. It is not a classification scheme, which I also discussed in a recent blog post, “Classification Systems vs. Taxonomies.”

A navigation scheme is typically presented as a set of menus and submenus and possibly also a supplemental site map, although the latter has become far less common on websites than it used to be. The navigation scheme of a website, intranet, or portal reflects the structure of the content, which has been designed in a way to serve various sets of users (defined by generic “personas”) with various common kinds of tasks, such as finding people, reports, events, office locations, financial data, etc., submitting requests, providing feedback, and placing orders, among others.

The one area where navigation and taxonomy may overlap is in a website where the content is entirely publication-like articles or documents. In this case, the site navigation is just for finding articles or documents based on their subject matter, so a topical taxonomy for indexing and retrieving documents may appear as the navigation menu for the site.  This is the case for news media sites, for example.

With a background in indexing, I like to compare the index of a book with the taxonomy-enhanced search capabilities of a website, whereas the table of contents of a book is like the navigation scheme. A table of contents or navigation scheme is a higher-level, pre-defined structure of content, that guides users to the general organization of content and tasks. It helps users understand the scope of the content available, provides guidance on where and what content to find, and aids in exploration. An index or search feature, including faceted search, on the other hand, enables to user to find specific information or content items of interest. A taxonomy, regardless of its display type, serves the function of an index, not the table of contents. I have also compared taxonomies with tables of contents in a blog post several years ago, “Taxonomies and Tables of Contents.” 

Even when a taxonomy is hierarchical, it differs from a navigation scheme or table of contents, because it is an arrangement of terms/topics/concepts. By contrast, the navigation (or table of contents) is an arrangement of named content (named pages/sections, etc.). This is key. Terms, topics, or concepts (the distinctions between which are beyond the scope of this discussion), while reflecting the content of the website or intranet, are somewhat generic, can apply to any content in the site, and whose meaning should  be understood independent of the location in taxonomy hierarchy. Think of the tagging aspect of taxonomies.  Any hierarchy that the taxonomy terms are arranged in reflects the meanings of the terms and the relationships of the terms to each other. It does not reflect the arrangement of the content. Navigation menu labels, on the other hand, are short descriptions of pages or sections (with landing pages), which they match one-to-one, and the hierarchy of the menu reflects the hierarchical structure of the content.

The following table lists the various differences between navigation schemes and taxonomies.

Navigation schemes	Taxonomies
Single-site use and implementation	May be re-used in multiple implementations
Reflect the site-map structure	Reflect organic relations of the topics/concept
Labels based on page titles	Labels based on concepts/topics
Designed to be browsed hierarchically, top-down	Designed to be browsed, searched, or may not be fully displayed to users
2-3 level hierarchy limit	Options for deeper hierarchy and/or facets
One-to-one label-to-page	One-to-many label to multiple pages
Do not include or link to all pages	Cover all pages or content
Limited in size	Can be small or large
Biased to emphasize what is important	Neutral to topic importance
Not so flexible for updating	Can grow and adapt without limits
Have paths and links, not metadata	Concepts are often metadata

What may be confusing is if we think of taxonomies purely has hierarchical structures and thus equate them with navigation schemes, which are also hierarchical. The feature of being hierarchical does not make something a taxonomy, as I explained in the “Classification Systems vs. Taxonomies.”  Although a taxonomy may be hierarchical, there are other kinds and displays of taxonomies. Taxonomies may be fully displayed for browsing as hierarchical or alphabetical, displayed in excerpts in facets, displayed as short lists of terms in type-ahead or search-suggest features, or not displayed at all as a search thesaurus (also called a synonym ring).  The idea that taxonomies do not have to be hierarchical will be the topic of my next blog post.

Trends in Hierarchical Taxonomy Displays

Taxonomies connect users to content. So, how a taxonomy is displayed to users is very important in its effectiveness. This is a topic about which I gave a conference presentation back in 2011 and will present again next week. As I update my previous presentation, looking at some of the same public websites with taxonomies, I have observed some changes that might be considered as trends.

While faceted taxonomies (used to filter/refine/limit results by certain criteria with choices of taxonomy terms) have become more common on ecommerce or other database websites, they are not suitable in all circumstances, and when a taxonomy has a large number of topical terms, a hierarchical arrangement of those topics might be better.

Displayed full hierarchical taxonomies, however are more difficult to find. They are not as often the default.  Some have disappeared entirely such as the Yahoo directory, which was discontinued in December 2014 after 20 years. (Admittedly, trying to classify as many websites as possible into a hierarchy, as the web keeps growing, is a never ending task.) In other cases, the search box is more prominent on the page, and the link browse categories needs to be hunted for.

In the past, I had observed two main different kinds of hierarchical displays: one-level-per-page and expandable hierarchies with plus signs. The first has evolved, the second is has become rare, and a third method has emerged.

One level of taxonomy hierarchy per page was the design of the former Yahoo directory and had been early on the style followed on other sites. An example that closely follows the Yahoo Directory, is the dmoz/Open Directory Project. A list of category labels or topics at each level takes up the entire screen/page display, without the display of other content. Displaying additional content on every page has become important, so hierarchical taxonomy categories now tend to be confined to more compact lists to free up space on the web page for content. This works for some taxonomies, not all. Meanwhile, a list of terms at the same level that take up the entire page is a style that is rarely followed anymore.

Expandable hierarchy “trees,” typically with plus signs next to topics to expand a topic’s subcategories has become quite rare, at least in public web sites. An example are the USA Today topics. This hierarchical taxonomy design had been developed based on the recognizable desktop file folder structure, such as in Windows. In the meantime, users have become familiar with different representations of topic hierarchies on the web, so mimicking expandable file menus is no longer the only way to engage users. Expandable topic hierarchies are not as easy to update and change on websites and, it can take a long time to load the web page. Expandable hierarchies allow the users to have more than one hierarchical level expanded at once, which facilitates exploring the taxonomy. As much as we taxonomists might enjoy browsing a taxonomy, the goal is to get users to content rather than have them spend time exploring the taxonomy.

A third method of displaying multiple levels of a hierarchical taxonomy is through “fly-out” subcategory lists. Examples include Lynda.com (under "Browse the Library") and Books & Authors. I had not noticed this method before, so it seems to be a new trend. They are similar to submenus in website navigation, but rather than for website navigation, the topics are linked to indexed content items, which are listed in a result set for each subtopic. Fly-out subcategories allow the users to still see the parent category list, if the user wanted to back out to it, like in an expandable tree hierarchy. But unlike an expandable tree hierarchy, you cannot have multiple parent categories expanded at the same time, which is not that important anyway. The fly-out subcategory style is thus a positive trend in hierarchical taxonomy displays.

Information Architecture and Taxonomies

While interest in “information architecture” by that name has declined in the past decade, interest in what information architecture involves continues to be strong, and perhaps there is some merging of the fields of taxonomy and information architecture.

At one point in my career I wanted to be an information architect, to organize the pages and menus of websites and intranets.  The discipline’s leading professional association, the IA Institute additionally describes the field as “The structural design of shared information environments.” But within a couple of years, I found that interest in my information architecture skills, at least for small websites (“little IA”) was getting squeezed out for skills in either graphic design or technical web development. Over time it also seemed as if information architecture was being replaced by the growing field of user experience design (UXD). Indeed Google search trends show a definite decline in interest in the phrase “information architecture” during the same period of a steady growth in interest in “user experience.”

I was therefore pleasantly surprised to find that information architecture was one of the themes at this year’s Taxonomy Boot Camp (Washington, DC, November 5-6, 2013), the leading conference dedicated to taxonomies.

Information architecture was a central part of the keynote “Taxonomy Is Power: Bringing It All Together,” presented by Bob Boiko. He started off explaining that information systems are a triad of people, information, and technology. But he, too, had observed that information architecture (IA) has often been “captured” by user experience (UX), moving away from technology toward the user, but the “information” piece of the triad sometimes gets lost along the way and needs more attention. Bob defined information architecture as “the art and science of designing information structures” and that information architects live in the space between art (design) and science (technology). Information architecture is also about naming things, and taxonomies can help engineers and designers name things for both the front end and back end of an information system. Bob said that taxonomists should look at and “own” the concept of information architecture.

The conference also featured a session of three presentations under the heading “User Experience (UX) in Taxonomy Design.” Michael Rudy, of  the consultancy Factor, spoke on the benefits of integrating user experience  with information management, and Bram Wessel, also of Factor, presented on how different methods of user research, common in user experience design, such as card sorting, tree testing, personas, and prototyping, are also applicable to taxonomies. Taking a different angle to the issue, Ben Licciardi of PPC presented methods of designing the manual indexing/tagging interface for taxonomy use.

There are various perspectives and approaches to this field, whether stressing structure as in “architecture,” naming, as in “taxonomy,” or meaning, as in “semantics.” Different labels may resonate better with different audiences. The week of the conference I was also indexing a book on user experience design (a small project to do on the plane and to broaden my knowledge of the subject). While “taxonomy” was not mentioned in this light book, “semantic design” was the name of a section which mentioned information architecture, organizing information, and metadata.

Several years ago, perhaps 2007, when I introduced myself as a taxonomist to someone at a professional conference, I was asked what the difference was between taxonomists and information architects. My answer then is the same as it is now: there is definitely a significant area of overlap between the skills, tasks, and responsibilities in both professions, although there are some areas that concern information architects and not most taxonomists, and there are areas that concern taxonomists and not most information architects. So, it may only depend on what kind of information architect or kind of taxonomist you are. I hope one day to also attend the main information architecture conference, the IA Summit and continue this discussion, as interest in taxonomies is remaining strong.

Card Sorting and Taxonomies

Card sorting is a common technique in information architecture for developing the organization of menu labels or categories on websites. It would thus seem to be a very suited methodology for developing all kinds of taxonomies, but in actual practice card sorting is not utilized for most taxonomy projects, at least not in my experience.

Card sorting gets its name from the paper-based approach of having numerous category or concept names written down each on a small index card, and then the cards can be sorted on a table into logical categories. Multiple stakeholders and/or test users are given the opportunity in turn to organize the cards as they deem appropriate, and the person administering the card sort, takes note of the choices and considers them for the actual organization structure. Today, card-sorting software, especially that which is web-based to allow remote access, has largely replaced the physical cards.

There are two variants to card-sorting exercises, the open card sort and the closed card sort. In an open card sort, participants sort the labeled cards in any groupings they see fit and then they assign their category groups with any group name they want. In a closed card sort, the participants are already presented with a set of named top category groups that they cannot change, and are asked to sort the labeled cards into the pre-assigned categories. Each type of card sort has distinct objectives and is suited for different stages of the project.

Open card sorting is a good way to get a new taxonomy from scratch off the ground when you have some concepts (extracted from the content) and don’t know how to organize them. However, this is increasingly no longer the scenario. It’s rare to start creating a taxonomy from scratch with no other reference for top categories. There are so many taxonomies in existence now for all subjects, that it’s easy to find a starting point as a model. Furthermore, the owner of a taxonomy may have already designated the top categories for business reasons.

The aim of closed card sorting is to determine in what broader category narrower categories belong, especially if there is uncertainty. But if a narrower category could rightfully belong under more than one category, rather than force a choice between one or the other based on a card sort, the subcategory could belong under both. This is what taxonomists call “polyhierarchy,” and it acceptable as long as the hierarchy is sound and valid in both locations. Thus, closed card sorting is only needed when you have decided you do not want polyhierarchy.  Polyhierarchy is generally a good thing, because it provides more than one navigation path to the same results, and different people choose different paths. Sometimes, however, polyhierarchy is avoided near the top levels of a taxonomy in order to maintain a sense of tree structure.

Card sorting is most practical for just two levels of hierarchy: concepts and their immediate parent categories. It’s possible but unwieldy to suggest to users that they may create three levels, and some card sorting software does not even allow it. Often it is more reliable to just run a second series of card sort testing for another hierarchical level in the taxonomy. However, running multiple card sort exercises for different hierarchical branches of a taxonomy can be quite impractical, if not also costly and time-consuming.

Finally, card sorting works only for traditionally hierarchical taxonomies. It does not work for faceted taxonomies, where terms from different facets/attributes are selected in combination to limit or filter search results. Faceted taxonomies are becoming increasingly common.

Card sorting continues to be useful for information architecture, though. When designing the structure of a website and its main and submenus, it can be difficult to decide what the categories should be, because the content of  a site can be unique or nonstandard. Additionally, polyhierarchy is not expected in submenus and could be confusing. Finally, website navigation is often not deeper than two or three levels, unlike many taxonomies that are often four or five levels deep and thus impractical to thoroughly design or validate with card sorting.