A good professional book, besides making your bookshelf impressive, can:
- Offer a good brush-up on the basics
- Help put into words ideas you’ve had
- Suggest introductions for topics you’re not familiar with
- Provide alternate perspectives on topics you are familiar with
It’s this last reason that I like having these books around. Even when I’m not working on an information architecture problem, I like picking up Blueprints or Polar Bear and browsing through it. More often than not, I find something that gets my creative juices flowing.
On the other hand, it’s when I’m stuck on an IA problem that I really need these books to help me find a way out of it. And when I’m stuck on a problem, I hardly have time to kick my feet up on my desk and browse idly through. That’s where this issue’s Special Deliverable column comes in. In this column, you’ll find an overview of three IA books from a deliverables point of view. The purpose of this article is not to say whether one book is better than another, or even to comment on the overall quality of the books, but to provide a guide to what kind of deliverables information you can find in each book, and where.
The three books reviewed are:
Information Architecture: Blueprints for the Web. Christina Wodtke. New Riders, New York: 2002.
Information Architecture for the World Wide Web. Louis Rosenfeld and Peter Morville. O’Reilly and Associates, Boston: 2002.
Practical Information Architecture: A Hands-On Approach to Structuring Successful Web Sites. Eric L Reiss. Addison-Wesley, New York: 2000.
In the course of this article, I will abbreviate these references as Blueprints, Polar Bear, and Practical IA, respectively.
Author’s Disclaimer: Some of my work appears in Blueprints.
The three books represent a variety of attitudes toward deliverables, and these distinctions highlight that the product of information architecture is intangible. No book flat-out states that only “professional” or “formal” deliverables are preferable to informal ones. Of the three, however, Blueprints discusses documents that are geared toward thinking through problems and those geared toward communicating ideas to non-IAs. Practical IA offers almost no advice on the “formal” IA deliverable, but does suggest several pen-and-paper methods for thinking through ideas. In contrast, Polar Bear seems much more focused on formal documentation.
Only Polar Bear and Blueprints have full chapters dedicated to documentation. Practical IA does have a chapter entitled “Getting it down on paper,” but the intent of this chapter is not to demonstrate or explain formal deliverables.
Your preference on preparing “formal” or “client-ready” deliverables depends entirely on your working style, and the demands of your client.
All three books define wireframes similarly–as representations of a single screen or page–and acknowledge that they can “cross the line” between information architecture and visual design. Polar Bear has an entire section dedicated to wireframes (pp. 283-289) in its chapter on deliverables (chapter 13, pp. 270-304). Blueprints’ section on wireframes (pp. 284-289) also appears in its chapter on deliverables (chapter 9, pp. 246-290). Practical IA never goes beyond a brief definition in the glossary in the first chapter.
Blueprints dives right in and offers a crash course on building wireframes. The approach is terse, but includes several detailed examples. Blueprints also shows the final screen design that came out of the sample wireframes. For addressing the potential conflict with visual designers, Blueprints offers three suggestions. Blueprints Chapter 10 includes a case study which illustrates how a wireframe fits into the overall IA process.
Polar Bear offers a more detailed look at the definition of wireframes and spins them as architectural tools. By creating these scratch layouts, suggests Polar Bear, the IA can identify structural or navigation issues. Polar Bear also explains that wireframes can vary in fidelity, and presents low, medium, and high fidelity examples. (The examples in Blueprints, however, do a better job illustrating annotated wireframes.) Although Polar Bear does not offer any sort of troubleshooting or basic process for creating wireframes, it does list five guidelines for creating them.
None of the books go into any detail about how to use tools to create wireframes, so if you’re looking for tips on Visio, PowerPoint, or OmniGraffle, you’ll have to look elsewhere.
The table below summarizes the three books’ treatment of wireframes. For some topics, a book with an XX indicates that it is an exceptional source of information.
|Process for creating||X|
|Pros and Cons||X|
|Shown in context of IA process||X (through case study)||X|
What Blueprints calls Site Maps, Polar Bear calls “blueprints,” and Practical IA calls “written outlines.” All three books offer comprehensive definition of this essential deliverable, but there are slight variations in each book. The practicing IA would do well to look at all three sources when preparing a sitemap.
Blueprints treats sitemaps (pp. 272-283) in its chapter on deliverables. While it spins sitemaps as a method for showing relationships between pages, Blueprints indicates that a sitemap can show other aspects of a website, including whether pages are static or dynamic. Blueprints discusses two main components of the sitemap: the layout and the “visual vocabulary.” For the layout, Blueprints offers four alternatives and provides simple examples of each. For visual vocabulary, Blueprints offers several typical shapes. The section on sitemaps concludes with three examples, meant to show the variation between the approaches of three information architects.
While Blueprints focuses on the layout-vocabulary distinction, Polar Bear distinguishes high-level from detailed blueprints. For high-level sitemaps (pp. 272-278), Polar Bear spells out the process for creating them, showing how the purpose of a high-level sitemap is to explain the abstract concepts that form the foundation of the information architecture. Although it does not provide a step-by-step approach, Polar Bear does walk through examples of high-level and detailed sitemaps (pp. 279-280). Since information architects face so many different scenarios, Polar Bear provides a nice array of examples. Polar Bear advocates simplicity in sitemaps (a point which I would do well to take) and offers strategies for keeping sitemaps in check.
Practical IA begins its section on “written outlines” (pp. 99-100) with: “A surprising amount can be accomplished using an ordinary word processor.” Ultimately, Practical IA advocates using an outline to begin the sitemapping process, but concludes that a diagram is preferable when presenting it.
Once again, none of the books offered any documentation on specific tools.
As controversial as wireframes are, the three books disagreed more on the purpose and implementation of sitemaps. Perhaps there is a tacit understanding in the IA community that sitemaps are “owned” by the information architect, which is why the controversy focuses on wireframes. With the community’s assumption about wireframes, however, comes the unfortunate side effect that none of the books address sitemaps’ pros or cons or typical pitfalls.
|Process for creating||X|
|Pros and Cons||X|
|Shown in context of IA process||X (through case study)||X||X|
Each book has a different take on content inventories, although each uses them to get their arms around the domain of information. In Blueprints, a content inventory is a tool for analyzing each page of the site. On the other hand, Polar Bear uses content inventories to catalog the “chunks” as content gets migrated from one medium to your information architecture. The distinction is subtle, but does significantly alter the spin of content inventories in each section.
Blueprints calls content inventories the “single most painful job of information architecture.” (Also, a “Sisyphean task,” for those SAT word freaks.) As difficult as Blueprints’ introduction to Content Inventories makes them out to be, its advice for creating one (pp. 267-271) is pragmatic and helpful. The book describes a three-step process for creating content inventories and gives a nice example of a few rows from a content inventory spreadsheet.
Polar Bear combines its account of Content Inventories with content mapping–the process of reconciling the content inventory with an information architecture. Polar Bear’s account of content inventories is much more generous (no references to tragic Greek myths), but does not offer a process for understanding the scope and range of content. Within the context of content mapping, a content inventory is a “byproduct.”
With no specific deliverable to speak of, Practical IA nonetheless dedicates an entire chapter (pp. 31-40) to the process of cataloging content. The book offers ingenious ways of keeping track of countless pieces of information. Practical IA also explores methods for brainstorming content to flesh out the breadth and depth.
|Process for creating||XX||X|
|Pros and Cons|
|Shown in context of IA process||X|
From a deliverables perspective, each book has different strengths.
Blueprints includes several deliverables I had never even heard of, like Sitepath Diagramming (pp. 248-252), which is meant to show the relationship between a site’s users and its information architecture. Unlike most other documentation techniques, this approach includes users as a critical piece, which can help information architects ensure that they’ve addressed all user needs. Blueprints spins Sitepath Diagramming as a brainstorming technique, but turning it into a formal deliverable should be a fairly straightforward exercise.
Polar Bear is by far the most comprehensive, detailed account of information architecture available. Even the most advanced IAs will find something new in here. From a deliverables perspective, Polar Bear is strongest on client relationship issues. Whatever deliverable you are working on, Polar Bear offers explicit advice on how to explain and present it to clients. This book is useful for client relationships implicitly as well, by providing complete descriptions of the deliverables and their purpose in the IA process. Such language is begging to be referenced for those of us who get tongue-tied in front of clients.
The strength of Practical IA is in its simplicity. While it may not account for the depth of IA activities, it does show the breadth. It is the perfect book for lending to people new to the field. When your own deliverables become complex, Practical IA offers a common foundation for people generally unfamiliar with IA concepts.
If there is a single book that offers a comprehensive view of IA deliverables, complete with descriptions, samples, guidelines, and tool tips, it has not yet been written. (Given demand, we may never see such a volume on our shelves.) With these three staples in an IA’s library, however, no information architect should be lacking inspiration.
For the next column, Special Deliverables will look at the relationship between deliverables and IA methodologies.