Section 12.1. Guidelines for Diagramming an Information Architecture

12.1. Guidelines for Diagramming an Information Architecture

Information architects are under extreme pressure to clearly represent the product of their work. Whether it's to help sell the value of information architecture to a potential client or to explain a design to a colleague, information architects rely upon visual representations to communicate what it is they actually do.

And yet information architectures, as we've mentioned many times, are abstract, conceptual things. Sites themselves are not finite; often you can't tell where one ends and the other begins. Subsites and the "invisible web" of databases further muddy the picture of what should and shouldn't be included in a specific architecture. Digital information itself can be organized and repurposed in an almost infinite number of ways, meaning that an architecture is typically multidimensionaland therefore exceedingly difficult to represent in a two-dimensional space such as a whiteboard or a sheet of paper.

So we're left with a nasty paradox. We are forced to demonstrate the value and essence of our work in a visual medium, though our work itself isn't especially visual.

There really is no ideal solution. The field of information architecture is too young for its practitioners to have figured out how best to visually represent information architectures, much less agree upon a standard set of diagrams that work for all audiences in all situations.^[*] And it's unlikely that the messages we wish to communicate will ever lend themselves easily to 8.5x11 sheets of paper.

^[*] It's worth noting that, while standards for deliverables haven't emerged, the diagrams themselves are maturing. The fall of 2006 saw the publication of Communicating Design: Developing Web Site Documentation for Design and Planning (New Riders), a book focused solely on deliverables, by Dan Brown, an information architect whose work is highly respected by many practitioners.

Still, there are a couple of good guidelines to follow as you document your architecture:

1. Provide multiple "views" of an information architecture. Digital information systems are too complex to show all at once; a diagram that tries to be all things to all people is destined to fail. Instead, consider using a variety of techniques to display different aspects of the architecture. Like the blind men and the elephant in John Godfrey Saxe's fable (see the section "Many Good Ways" in Chapter 18), no single view takes in the whole picture, but the combination of multiple diagrams might come close.

2. Develop those views for specific audiences and needs. You might find that a visually stunning diagram is compelling to client prospects, therefore justifying its expense. However, it probably requires too many resources to use in a production environment where diagrams may change multiple times per day. Whenever possible, determine what others need from your diagrams before creating them. For example, Keith Instone, an information architect at IBM, finds himself developing very different diagrams for communicating "upstream" with stakeholders and executives than for "downstream" communication with designers and developers.

Whenever possible, present information architecture diagrams in person, especially when the audience is unfamiliar with them. (If you can't be there in person, at least be there via telephone.) Again and again, we've witnessed (and suffered from) huge disconnects between what the diagram was intended to communicate and what it was understood to mean. This shouldn't be surprising, because there is no standard visual language to describe information architectures yet. So be there to translate, explain, and, if necessary, defend your work.

Better yet, work with whomever you're presenting your diagrams toclients, managers, designers, programmersto understand in advance what they will need from it. You may find that your assumptions of how they would use your diagrams were quite wrong. We've seen a large, respected firm fired from a huge project because it took too many weeks to produce bound, color-printed, sexy diagrams. The client preferred (and requested) simple, even hand-drawn, sketches because it needed them as soon as possible.

As we've seen in previous chapters, the most frequently used diagrams are blueprints and wireframes. These focus more on the structure of a site's content than its semantic content. Blueprints and wireframes are effective at depicting structure, movement, flow, and relationships between content, but not at conveying the semantic nature of content or labels. We'll discuss both types of diagrams in detail in the following sections, but first it would be helpful to understand the "language" that these diagrams use.