Why good architecture is important
I recently started working on a long-term project to improve the architecture of the Web site at the company where I work. Looking at this project, I cannot help but wish that the principles of good information architecture were better understood at my company. Unfortunately, as with many companies in Japan, there are often very few guidelines in place to keep projects moving in a consistent direction. All too often, how projects are run is a decision left up to the people who staff them. Given that staff changes are almost inevitably an annual event, this can be quite a gamble as projects grow. Without a set of guidelines to follow, the architecture begins to crumble under the strain of multiple ways of doing essentially the same thing.
It reminds me of a book review I wrote for the Tokyo PC Users Group not long ago, which I have reprinted below. I wish I could find a copy of this book in Japanese. It would be just the thing to hand to my coworkers to explain how we need to structure this project as we move forward.
Update: August 5
I stand corrected. It seems that the company finalized its 200-page “Global Web Style Guide” just last month. I am pleased to report that nearly a quarter of the guide itself is made up of architectural information. This makes me feel a lot better about the long-term project I mentioned earlier.
Information Architecture: Blueprints for the Web
By Christina Wodtke
Published by New Riders Publishing
ISBN: 0-7357-1250-6
Price: USD$29.99
With Information Architecture: Blueprints for the Web, Christina Wodtke has done what few information architects before her have been able to accomplish: Write an IA book that is simultaneously accessible to newcomers and yet still informative even for more experienced
readers.
Over the course of 12 easy-to-read and often lighthearted chapters, Wodtke lays out the case for good information architecture, how to go about it, and where you can go from here (both in the sense of where the field of information architecture is going and in the sense of what other books you might like to read if you want to learn more about the field itself).
Wodtke starts out with a simple, straightforward question: Why blueprint a Web site? (Note how easily this question could be rephrased to make its answer more interesting to freelancers: Why would a client pay you to blueprint a Web site?) The answer, of course, is all about maintaining usability in spite of ever-increasing complexity. It is entirely possible to manage a small site without a pre-planned architecture, but as the site grows it will inevitably become exponentially more difficult to maintain and downright impossible to use and if there is no underlying architecture to guide its growth. Just as you need a blueprint to build a skyscraper, you also need one to build a thriving Web site.
One of the truly nice things about Wodtke’s book is that it avoids the “guru syndrome” that afflicts many books of this sort. (Guru syndrome is what happens when Web-savvy people become too enamored with one way of building sites—so much so that they feel it is the only correct way.) In fact, Wodtke steadfastly refuses to recommend any particular methodology or advocate the use of any particular software. Instead, she advises her readers to develop their own “toolbox” of skills to apply to any situation. Some of what she writes contradicts the “rules” espoused by some experts, but she offers no rules of her own in their place, which is precisely her point: Information Architecture is not about figuring out the One True Formula that can be applied without fail to all usability projects. Each site will have its own needs and will need its own rules. Rather than precise rules, use rules of thumb. Rely on principles, certainly, but avoid the urge to boil them down into axioms. To make sure that the right principles are being used for the right purposes, Wodtke recommends applying proven techniques (or “tools” in the toolbox metaphor), which make up much of the content of the book.
One of the earliest steps in designing the site is the creation and testing of a prototype, but even before that, Wodtke offers practical advice on how to conduct effective, probing interviews that will help the prototype stage yield meaningful information about what your users need and how to help them get it. Armed with this information, Wodtke then offers a few choice tools with which to make sense of this information.
Stuck on how to categorize your content? A card sort could help you discover the most logical organization scheme. Does your content fit into multiple categories? Faceted classification can help your users find what they want in more than one place. Not sure how to reveal the breadth of your content without overwhelming your users? You might want to rethink your labels. Have content that different people are likely to describe in different ways? Careful, consistent use of metadata and controlled vocabularies can help keep everyone on the same page. Finding out that your user demographics are too vague? Design some user personas and walk them through a number of actual-use scenarios. With each of these techniques, the usability of the site improves as the categories, navigation, and workflow are refined. The overall results will inform your choices when it comes time to build the interface and make decisions about issues like global and local navigation and pagination.
In the last quarter of the book, Wodtke focuses on putting those techniques into practice. Whereas the middle section of the book was all about what tools to use and when, this section is about how to deliver the goods to the client—and how to do so with style and professionalism. As you might expect, this is where the heavy-duty “blueprinting” comes in.
Contrary to what you might expect, Wodtke offers compelling reasons to avoid the use of any software for the first steps, the sitepath diagramming or topic mapping, because it may actually inhibit the creative process. Software comes back into play later, when putting the finishing touches on your storyboards, but even those are best written in pencil in the beginning, Wodtke believes. Projects naturally become more software-intensive as you move toward expanding your storyboards into full-fledged wall diagrams with functional specifications. As your project evolves even further still, you will need to rely more on software to manage your content inventory, to arrange your sitemap, and to draft your page schematics (often called “wireframes").
In addition her advice on how to handle the deliverables, Wodtke also offers some very useful suggestions on how to manage the less tangible aspects of large-scale projects, things like how to “jump start your brain” and the creative process, how to present your solutions to the client, how to peruade others, and even how to handle arguments. This section was a thoughtful bonus. In a book already brimming with good advice, it was like finding a digest version of How to Win Friends & Influence People tucked in among the information architecture techniques and how-tos. In closing, Wodtke also offers some insights into the field of information architecture and a “Recommended Reading” section that points readers to some of the best known publications (both books and Web sites) in the business.
Information Architecture: Blueprints for the Web is a breeze to read, is nicely illustrated, and offers loads of sensible advice. It can be read in a few hours and obtained for small amount of money, both well spent. Any serious site-development or project-management bookshelf should have this book on it.
