12.9. Putting It All Together: Information Architecture Style GuidesA 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?
12.9.1. The "Why" StuffDocumenting 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" StuffYour style guide should include some basic nuts-and-bolts components to help various people maintain the site. Consider including such sections as:
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. |