Information Architecture: Blueprints for the Web

“A guru, in Wodtke’s terms, is nothing more than a critic who prescribes rigid, oversimplified “rules” of website design.”Recently, a website designer friend asked me, “If you had to recommend one book for a non-designer to understand our design process, what would it be?” I thought for a few moments. Then for a few more. And a few more. Strangely, I couldn’t come up with one. While there are many fine books that go into great depth on various aspects of the information architecture and design process, I was unable to think of a single one that provides a concise, 10,000-foot view of what we do. However, if my friend were to ask me this question again today, I would quickly refer her to “Information Architecture: Blueprints for the Web”, Christina Wodtke’s new book targeted at people new to the field.

Formerly a partner at Carbon IQ, a user-experience firm in San Francisco, Christina now leads the user experience efforts on Yahoo Search and Directory and has been a practicing information architect for four years. (She is also the founder of Boxes and Arrows.) Despite her pedigree, Wodtke does not want to be mistaken for a web guru.

A guru, in Wodtke’s terms, is nothing more than a critic who prescribes rigid, oversimplified “rules” of website design. Dictating rules is risky, she implies, because inexperienced site planners and designers tend to take them at face value. They operate under the mistaken assumption that following those rules is all they need to do to create a good site. But there simply aren’t enough well-designed sites out there to justify that approach.

Wodtke argues that good site design is complex, nuanced, and context-specific. You have to look at the problem fundamentally and create a plan that serves the needs of your specific users. You have to create a blueprint based on solid thinking.

So, rather than issue orders, Wodtke strives throughout her book to be more like a good teacher, by providing her readers with useful guidelines, principles, and techniques—what she calls “ways of working.” (13) To illustrate the difference between a guru’s rules and her approach, she spends the first chapter of “Information Architecture” amusingly distilling several well-known “laws of web design” into the more practical principles and guidelines on which they were once based (but have since contorted).

For example, she takes on “Users don’t read. Use as little writing as possible.” She first boils it down to its underlying practical guideline: “Write material to be read onscreen with the understanding that the article may not be read to its completion.” (16) Then she identifies the larger principle on which it’s based: “Consider the situation of the reader and the nature of the content when writing for the web.” (17) Both are much more reliable, and applicable, than the original, erroneous rule.

Next, Wodtke offers a handy list of principles of her own, such as, “Be consistent and consider standards” (i.e., don’t break from convention unless you’ve got a good reason). At first glance, some of these principles bear resemblance to the rules Wodtke is so eager to debunk. But as you read her carefully crafted rationale, it’s clear they serve more as appropriate, realistic goals for website design. They are also general enough that they are unlikely to be confused for specific, one-size-fits-all solutions.

After introducing her principles, Wodtke provides a nicely succinct definition of the role of the information architect: “It’s your job to create a design that balances the users’ desires with the business’s needs.” (62). She then discusses how to tackle the first part of that mission: getting to know your users.

Here she goes over the basics of conducting user research: how to gather real (or potential) users, and how to interview them effectively to learn about their concerns and needs. Skipping ahead a bit in the process, she also gives an overview of prototyping and usability testing techniques. This seems a tad out of place here, but as in much of the book, Wodtke doesn’t dwell unnecessarily on the topic, and the text moves along at a steady clip.

Another key aspect of building an effective site is to understand how its users will approach it—what their mental model of the site will be. Wodtke emphasizes the value of getting inside the user’s head. She contends users have three fundamental questions when they arrive at a website: “Am I in the right place? Do they have what I am looking for? and Do they have anything better?” (90) If you can answer these questions, you’re well on your way toward designing a successful site.

From there, you can begin figuring out how to present your content in a way that will make sense to your users. Wodtke discusses several effective, user-oriented classification schemes and the importance of clear, consistent labeling. Many inexperienced site designers overlook these key issues, so it is reassuring to see their value emphasized here.

Having introduced how to approach the problem itself, Wodtke launches into the real meat of the book: how to solve it. Unexpectedly, she doesn’t begin with a site map. That comes later. Instead, she recommends starting from the bottom up—from users to page design to system architecture.

First, Wodtke says, figure out your metadata—the information that helps users find the content they’re looking for. When you go to a shopping site and have to dig around to find something you know the store offers—a scarf, in the book’s example—it’s a sign of bad metadata. If you get your metadata right, on the other hand, you’ve already cleared the first hurdle of effective site design. Wodtke offers several methods for determining what metadata your users will need. Here again, she does an impressive job of conveying the value of a step that inexperienced information architects often skip.

Next, when your user finds the content he’s seeking, he’ll need to interact with it. To design the most pleasing experience for your users, Wodtke recommends thinking in stories, specifically scenarios featuring personas.

Personas are becoming an increasingly common tool in the interaction design field, yet the process of creating and using them effectively has not been widely documented. Here Wodtke hits one of out of the park by presenting a wonderfully concise and complete summary of the technique, which she calls “The Shirley Maclaine Method” (because, while designing, you “channel” the persona, get it?). Wodtke then provides a quick, clear description of how to use scenarios to visualize your personas using the various functions of your site.

The next chunk of the book is dedicated to creating good interfaces, summed up in Wodtke’s five GUI principles:

  • Simplicity and Elegance
  • Proximity and Relevance
  • Focus and Feedback
  • A Hierarchy of Importance, a Hierarchy of Task
  • The Right Tool for the Right Job

Throughout this section, Wodtke illustrates her text with numerous examples of existing websites, often presenting nicely parallel, but different, applications of a given principle. Refreshingly for a book of this type, and in keeping with her non-guru stance, Wodtke delivers all of this as a collection of guidelines and suggestions, rather than a decree. She evenly lays out the pros and cons of the various design solutions she offers, and makes it clear that the best solution is always the one that is most appropriate for your particular situation.

Finally, after a healthy discussion of site navigation principles and concepts, Wodtke comes to the core of the website: its architecture. Appropriately, she goes into some depth in this area. Your first step: start drawing your site on paper or on a whiteboard—avoid the computer at first. “It’s better to scribble ideas on paper with the full knowledge that this will not and cannot be the final product.” (247)

Wodtke suggests two scribble methods in the section called “Drawing for Thinking:” sitepath diagramming, which maps the site from a human perspective, and topic mapping, which maps the site from a content perspective. She provides helpful definitions and examples of the techniques, and encourages readers to try both to see which works best for them. (She even provides a handy sidebar on how to draw iconic people for sitepath diagrams.)

When you’ve got the site plan figured out, it’s time to share it with your team. To do so, Wodtke recommends several visual and textual techniques: hand-drawn or computer-generated interactive storyboards, wall diagrams and functional specifications, content inventories, site maps, and wireframes. For reasons of brevity, or possibly the author’s personal preference, some of these techniques are treated in more depth than others. For instance, site maps have eleven pages devoted to them, while wall diagrams and functional specifications get only three. But Wodtke addresses them all sufficiently for readers to at least use them as a starting point.

Having covered the site planning and design process from bottom to top, Wodtke employs a clever gambit to sum it all up: she talks about a real project. In the chapter “All Together Now,” she tells the story of her client Nick, who asked her to redesign his online magazine, Digital Web. In-depth, real-world stories like this one are rare in design guidebooks (which tend toward higher-level, abstract discussions), and this section is both entertaining and serves to illustrate, as its title suggests, how to pull all Wodtke’s techniques and principles together. Alas, the story ends somewhat abruptly at the wireframe stage, as it would have been nice to read the whole story through to the site’s relaunch. (Perhaps there will be a sequel.)

Finally, Wodtke shares some general techniques for getting your work done: how to break designer’s block, how to present your ideas effectively, and how to get people to buy into your design. She closes with some ruminations on the future of information architecture: the world will continue to become more and more complex as new technologies are introduced into our lives, and it will be on the shoulders of information architects to “protect human beings from drowning in the sea of information.” (329)

“Information Architecture: Blueprints for the Web” is, essentially, a primer on successful website design. Unlike the many dense manual-like books on the topic, the straightforward, accessible, and often funny prose of Wodtke’s book makes it an effortless read. Novice IAs will find good ideas and techniques flowing into their heads, while experienced designers will find themselves nodding theirs in agreement. And the clear, well-labeled organization of the material makes it a handy reference for both audiences as well. So grab a copy of this guide, and if you find yourself in my situation, in which someone asks you to recommend a book that concisely describes what it is we all do and how to do it, you’ll have an answer.

Read a chapter (PDF) from “Information Architecture: Blueprints for the Web.”


  • Information Architecture: Blueprints for the Web
  • Christina R. Wodtke
  • New Riders Publishing, October 2002
  • ISBN: 0-7357-1250-6
  • Softcover, $29.99
  • Chapters:
    1. Gurus and Rules
    2. First Principles
    3. Balancing Acts—Users, Technology and Business
    4. Those People
    5. Sock Drawers and CD Racks—Everything Must Be Organized
    6. A Bricklayers View of Information Architecture
    7. From A to C by Way of B
    8. Eat Me, Drink Me, Push Me
    9. Making It All Up, Writing It All Down
    10. All Together Now
    11. Being Effective
    12. And In The End
  • Companion website [www.blueprintsfortheweb.com]

Ryan Olshavsky has nearly five years of experience in interaction design and design documentation. He is currently an Interaction Designer at Yahoo! Inc., a small Internet company. Previously, he worked as a design consultant at Cooper.

Posted in Book Reviews, Reviews | 3 Comments »

3 Comments

  • Ramdak

    December 2, 2002 at 3:15 am

    Nice review, but, you could have helped by mentioning how large the sample chapter would be- it took me nearly thirty minutes to download on a dial-up connection. Surprising that Boxes and Arrows fails in this simple element of information design.

    Also, I noticed the mention about the re-designed Audi site with the right navigation and how it reduced scrolling etc. But, would the experience be the same for left-handed users? I daresay they would find the left-navigation more comfortable.

    All this is not to put down Christina’s book, however. I added it to my Amazon wish list even before it was published:-)

    Ramdak

  • christina

    December 4, 2002 at 7:38 am

    Do left handers keep their mouse on the left hand of the screen? Handedness does not always apply to mouse behavior. I mouse left (carpal tunnel in my right arm) and I(and others in the study) find right hand navigation more comfortable because of the reduced travel between the scrollbar and the menu. Sorry if this was less clear in the book, and so very glad you are enjoying it!

  • Doug McDaniel

    January 24, 2003 at 6:08 am

    Agree. Don’t assume handedness and mouse behavior coincide. As a pronounced lefty, I mouse with my mouse on the right of my keyboard. One reason, I presume: this was a learned behavior because of the preponderance of righties in my office and my respect for not moving THEIR mouse to the left of the keyboard. I know that early in my career, when I did mouse left, righties using my machine would disrepectfully, and with some grumbling under their breath, move my mouse to the right of my keyboard when they were using my machineI’m now happier with the mouse on the right. . Hmmm. I believe one would call that adaptation….. but I bet the ACLU would love a case like that. (My libertarian leanings dictate that I just deal with it and not mythologize my injustice.)

    Would that modern ergonomics folks could remove handedness from computers. (And for the record, I detest laptops with versaglide pads square in the center, as well as the stupid blue eraser head mouse.)

    Personally, I’d like to see something that actually “read” my retinal focus and pointed the cursor at the appropriate place on the screen. When I said “click” it should do so. What a concept. It’s probably out there, I’m just not aware of it.

Sorry, comments are closed.