12.1. Guidelines for Diagramming an Information ArchitectureInformation 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.
Still, there are a couple of good guidelines to follow as you document your architecture:
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. |