A couple years ago, I wrote an article called Information Architecture 2.0 on how information architects will need to adapt to the web’s changing landscape. I wrote the article when some people feared the demise of the practice of information architecture, when Web 2.0 was equated with tagging and more-or-less open content spaces like wikis. The hysteria took several guises, but one of the most prominent was that the need for formal structure would diminish if we gave classification functions directly to the information’s consumers. It’s time for me to revisit the idea, especially now that the modern landscape, while still volatile, has matured a bit. The web’s focus remains broad–not every site has become Wikipedia or Flickr–and the challenges for information architects grow increasingly difficult.

Without seeking to open old wounds, I should define information architecture. As information architects, we design structures, meaningful relationships between objects. A site’s interface design exposes these relationships, adding further layers of meaning. But the role of the IA is to define the objects addressed by a site and how those objects relate to each other.

In recent months I’ve had the opportunity to work on content-heavy sites–sites whose primary business is to present content from a variety of sources for specialized audiences. These experiences have given me an opportunity to reflect on what I do and how I do it. To support sites like these (which are hardly extinct or endangered as early Web 2.0 proponents would have us believe) IAs need to build four specific types of structures.

Content Types

A content type is hardly a new concept. Content management systems have been relying on them for years. In short, a content type is the collection of fields that define a piece of content on the site. The “structure,” therefore, is the relationships between these fields. You might define “article,” for example, as having three fields–title, author, and body.

Content types, despite the industry’s best efforts, are not a one-size-fits-all affair. Different projects require looking at content differently, and the information architect must be sensitive to how content will be authored, managed, and consumed. The art of information architecture happens when IAs think about creating a meaningful set of content types that neither require too much management, nor gloss over the important distinctions between different kinds of information. Content types that are too specific are difficult to manage because it can be tough for authors to determine which one to use. Those that are too general don’t have enough structure to be managed or consumed easily.

One benefit to thinking in terms of content types is that it positions information assets as objects of particular classes. Since most programming these days is “object-oriented”, thinking about content as objects can help build a bridge between user experience and development. In addition, modern web experiences leverage well-defined content objects as the focal points for community and participation. An emerging concept (at least for experience designers) is “social object,” the thing that unites people in conversation, connection, and community.

Templates

After defining the structure of the content, I usually think about what kinds of templates the site must support to display the content. For each content type I look at how an instance of the content will be represented in a variety of scenarios. There are two kinds of scenarios: one where the content type has a dedicated template and one where the content type is represented partially as an element of another content type.

For example, on an online magazine for professional musicians, I might have three content types–article, manufacturer, instrument. Manufacturers make certain kinds of instruments. Articles may refer to manufacturers or instruments. As an IA, I need to answer the question: To what extent do each of these content types need representation online? Obviously, I need a template dedicated to articles. I might also have a page for each luthier, and those pages might have references to articles mentioning that manufacturer. Therefore, an article has at least two representations on the site–as a page in and of itself and as a link from a manufacturer’s page. (At EightShapes, we refer to these roughly as views and components, respectively.)

There are lots of nuances to template design. You might, for example, develop views and components that support more than one content type, where the structure is the same regardless of the kind of information behind it. Alternatively, a content type may have multiple views (screens or pages) depending on the scenario or person looking at it. A common distinction, for example, is between a detailed view and a summary view. Some templates are not associated with any particular content type. A search results page, for example, will likely support a variety of content types.

For information architects, designing templates is where we come dangerously close to stepping on the toes of interaction/interface/visual designers. Generating a set of wireframes can be problematic when the overall visual approach to the site has not yet been ironed out, or when you’ve got people on the team who are more qualified to do that. Still, wireframes are the best way to represent (a) what goes on the page and (b) how those elements should be prioritized relative to each other. Each IA has his or her own way of navigating team dynamics.

Wayfinding and Navigation

With the content types and templates defined, I generally turn my attention to navigation. No matter how much the web has evolved, this question won’t go away: how to people get from one piece of information to another? It’s gotten more difficult to answer, too.

While navigation may seem like an antiquated concept in the age of search, pages still have links, and content-rich sites need some structure to help readers with wayfinding. Modern navigation, however, differs from original static sites in several ways.

First, sites generally have multiple navigation schemes. When presenting navigation for a new site to a client, I’m careful to say that sites don’t have just one architecture, one structure within which content sits. Instead, sites have multiple, often interlocking structures that are more dynamic than the simple hierarchies we created in decades past.

Next, at least one of the navigation schemes addresses contextual wayfinding. Recognizing that the home page of a content-rich site is rarely the primary entry point, information architects must create navigation structures on interior pages that paint a broad picture of the site without distracting from the reader’s starting point, which may be several layers inside the site. Again, IAs must walk a fine line between showing the range of content available on the site and keeping the available links meaningful.

Finally, navigation schemes look less like org charts and more like business plans. They aren’t prescriptive in terms of what labels or links appear in the navigation, but instead define a specific strategy for the kinds of links that should be included and why. Navigation, out of necessity, grows and changes over time and an organization must have a guide for putting links in the site’s scheme. Each scheme must have a purpose, criteria for including links, a prioritization relative to the other navigation schemes, hierarchical details (where does each link go?) and functional details (how does each link behave?).

Rules and Assumptions

As information architects deal more with abstracts (content types instead of specific pieces of content, navigation strategies rather than specific links) every abstraction needs a set of rules for governing how it will appear when instantiated. In the form of a question, when the system loads content into a template, how will the system determine what content to load?

The rules establish criteria for identifying appropriate content and what happens when no content meets those criteria. A rule might take the form:

Pull the three latest articles tagged with keyword X, less than 10 days old.
If the system can’t find three articles within this timeframe, hide this element.

As these rules develop, I find that I need to capture some assumptions. The rule above, for example, assumes that articles have an age associated with them and are tagged with keywords. I might capture the second part of this assumption this way:

Given a keyword, the system can identify articles associated with that keyword.

Assumptions, when it comes to content sites, usually take the form of “given input X, the system can retrieve articles”. Back to our music site, one assumption might be that for any given manufacturer, the system can identify articles mentioning the manufacturer. This might seem like a simple idea, but unless configured correctly, this function may be outside the capability of the content management system.

As the web matures, I see information architecture becoming about defining rules and boundaries, systems for information to live in. I’m considerably less concerned with site maps, labeling, taxonomies, controlled vocabularies, and specific navigation hierarchies. Frankly, I feel increasingly less qualified to do that kind of stuff: the dynamic nature of an organization means that a consultant like me can’t swoop in and add much (any?) value to their efforts to define a vocabulary or to anticipate the hot topics in their industry one year from now.

Information architects can add value in a different way. We’re playing at a more abstract level. Given all the content generated by an organization, how can technology invisibly and unobtrusively support the creation, management, and consumption of that information? What tools and structures must technology provide to let organizations realize the most value through its content? None of the web’s evolutionary stages have rendered these questions obsolete, and in fact has made them increasingly interesting.