Section 12.9. Putting It All Together: Information Architecture Style Guides

12.9. Putting It All Together: Information Architecture Style Guides

A web site is always growing and changing. As an information architect, you must help guide its developmenteven after the site launchesor risk architectural drift. It's frustrating to see your carefully and flexibly designed organization, navigation, labeling, and indexing systems get mangled as site maintainers add content without heeding the architectural implications. While it may be impossible to completely prevent the effects of entropy, an information architecture style guide can steer content maintainers in the right direction.

An architecture style guide ^[§] is a document that explains how the site is organized, why it is organized that way, who it's for, and how the architecture should be extended as the site grows. The guide should begin with documentation of the mission and vision for the site, as it's important to understand the original goals. Continue with information about the intended audiences. Who was the site designed for? What are their goals? What assumptions were made about their information needs? Then, follow up with a description of the content development policy. What types of content will and won't be included and why? How often will it be updated? When will it be removed? And who will be responsible for it?

^[§] For an excellent example of a general style guide that includes information architecture and other areas, see the "Best Practices for PBS Member Stations" design guidelines, developed with assistance from Adaptive Path: http://www.pbs.org/remotecontrol/bestpractices.

12.9.1. The "Why" Stuff

Documenting the lessons learned and the decisions made during the research, strategy, and design phases is critical. These underlying philosophies not only drive the design and maintenance of the information architecture, they also guide your site through the zigs and zags of major changes that your organization will surely encounter in the future.

For example, your organization may merge with another or spin off a unit. It may offer new products, or try to reach new markets and go global in the process. Major changes like these often coincide with major organizational changes such as new senior managers, many of whom wish to leave their mark in all areas, including the site's design. But do new requirements and major changes to the organization require major changes to the site's information architecture? Ideally, not; a clearly documented rationale serves to explain an information architecture and demonstrate its flexibility, thereby mitigating against the extremes that plague so many redesigns.

Perhaps the biggest "why" you'll encounter is the one that comes so often from senior vice presidents, marketing managers, and product managers, which, in effect, boils down to: "why can't my favorite feature/my department's content be made more prominent/become your highest priority?" An information architecture style guide provides you with concrete documentation to help you prioritize the many such requests you'll likely encounter. It'll even provide you with cover when you absolutely have to say no.

12.9.2. The "How" Stuff

Your style guide should include some basic nuts-and-bolts components to help various people maintain the site. Consider including such sections as:

Standards

There are usually at least a few rules that must be followed while maintaining and changing the site. For example, newly-created documents must be indexed with terms from the appropriate controlled vocabulary before they are published to the site. Or there may be specific procedures that must be followed to ensure that new content is immediately spidered and indexed by the site's search system. Here's the place to note the rules...

Guidelines

...and distinguish the rules from the guidelines, which suggestbut don't mandatehow the information architecture should be maintained. These may be drawn from information architecture best practices,^[||] and often require interpretation for each situation in which you'll find yourself; examples include advice on how to avoid overly long lists of links and page-titling recommendations.

^[||] For a few examples of IA heuristics, visit the following links: Lou Rosenfeld's "IA heuristics" at http://www.louisrosenfeld.com/home/bloug_archive/000286.html, Lou Rosenfeld's "IA heuristics for search systems" at http://louisrosenfeld.com/home/bloug_archive/000290.html, and James Robertson/StepTwo's "Intranet Review Toolkit" at http://www.intranetreviewtoolkit.org.

Maintenance procedures

Regular tasks that are required for the site's survival should be fully documented, such as when and how to add new terms to a controlled vocabulary.

Pattern library

Consider creating a pattern library^[#] that documents and provides access to reusable aspects of your site's designsuch as a navigation widget that helps users scroll through pages of resultsto cut down on reinventing the wheel.

^[#] To learn how Yahoo! developed its excellent library, read "Implementing a Pattern Library in the Real World: A Yahoo! Case Study," by Erin Malone, Matt Leacock, and Chanel Wheeler (Boxes & Arrows, April 29, 2005): http://www.boxesandarrows.com/view/implementing_a_pattern_library_in_the_real_world_a_yahoo_case_study.

Your style guide should also present both the blueprints, wireframes, controlled vocabulary information, and other documentation that came from the design process and will be reused throughout the site's lifetime. Since you won't always be there to explain these deliverables, it may be necessary to provide written explanations to accompany the blueprints. You also need to create guidelines for adding content to ensure the continued integrity of the organization, labeling, navigation, and indexing systems. This can be a challenge. When should a new level in the hierarchy be added? Under what conditions can new indexing terms be introduced? How should local navigation systems be extended as the web site grows? By thinking ahead and documenting decisions, you can provide much-needed guidancea user's manual, reallyto the site maintainers.

Keep in mind the different audiences that might use the style guide. For example, in a large organization, content authors working from far-flung parts of the globe may not need to know the site's overall strategy so much as the maximum number of characters they should use for a document title. Interaction designers may need to understand the rules that guide construction of the ALT tags that a navigation system's mouse-overs rely upon. Consider an information architecture style guide as a sort of "how and why" document that should be designed for use, just like any other information system. And remember that your organization may already have a style guide for its branding, its content, and other aspects of its online presence; when possible, integrate information architecture guidelines into existing style guides.