High-level blueprints are often created by information architects as part of a top-down information architecture process (and, it’s worth noting, they may also be produced during a project’s strategy phase) Starting with the main page, the information architect might use the process of developing a blueprint to iteratively flesh out more and more of the architecture, adding subsidiary pages, increasing levels of detail, and working out the navigation from the top down. (Blueprints can also support bottom-up design, such as displaying a content model’s content chunks and relationships; we discuss these uses later in the chapter.)

The very act of shaping ideas into the more formal structure of a blueprint forces you to become realistic and practical. If brainstorming takes you to the top of the mountain, blueprinting can bring you back down to the valley of reality. Ideas that seemed brilliant on the whiteboard may not pan out when you attempt to organize them in a practical manner. It’s easy to throw around concepts such as “personalization” and “adaptive information architectures.” It’s not so easy to define on paper exactly how these concepts will be applied to a specific web site.

During the design phase, high-level blueprints are most useful for exploring primary organization schemes and approaches. High-level blueprints map out the organization and labeling of major areas, usually beginning with a bird’s-eye view from the main page of the web site. This exploration may involve several iterations as you further define the information architecture.

High-level blueprints are great for stimulating discussions focused on the organization and management of content as well as on the desired access pathways for users. These blueprints can be drawn by hand, but we prefer to use diagramming software such as Visio or OmniGraffle. These tools not only help you to quickly layout your architecture blueprints, but can also help with site implementation and administration. They also lend your work a more professional look, which, sadly, will be more important at times than the quality your actual design.

Figure 12-1 shows a high-level blueprint that includes components within pages, groups of pages, and relationships between pages. The grouping of pages can inform page layout. For example, this blueprint dictates that the three guides should be presented together, whereas Search & Browse, Feedback, and News should be presented separately.

Figure 12-1. A high-level blueprint

Let’s walk through the blueprint in Figure 12-1 as if we were presenting it to clients or colleagues. The building block of this architecture is the subsite. Within this company, the ownership and management of content is distributed among many individuals in different departments. There are already dozens of small and large web sites, each with its own graphic identity and information architecture. Rather than try to enforce one standard across this collection of sites, this blueprint suggests an “umbrella architecture” approach that allows for the existence of lots of heterogeneous subsites.

Moving up from the subsites, we see a directory of subsite records. This directory serves as a “card catalog” that provides easy access to the subsites. There is a record for each subsite; each record consists of fields such as title, description, keywords, audience, format, and topic, which describe the contents of that subsite.

By creating a standardized record for each subsite, we are actually creating a database of subsite records. This database approach enables both powerful known-item searching and exploratory browsing. As you can see from the Search & Browse page, users can search and browse by title, audience, format, and topic.

The blueprint also shows three guides. These guides take the form of simple narratives or “stories” that introduce new users to the site’s sponsor and selected areas with the web site.

Finally, we see a dynamic news billboard (perhaps implemented through Java or JavaScript) that rotates the display of featured news headlines and announcements. In addition to bringing some action to the main page, this billboard provides yet another way to access important content that might otherwise be buried within a subsite.

At this point in the discussion of the high-level blueprint, you are sure to face some questions. As you can see, the blueprints don’t completely speak for themselves, and that’s exactly what you want. High-level blueprints are an excellent tool for explaining your architectural approaches and making sure that they’re challenged by your client or manager. Questions such as “Do those guides really make sense, considering the company’s new plans to target customers by region?” will surface, and present an excellent opportunity to gain buy-in from the client and to fire-proof your design from similar questions much later in the process, when it’ll be more expensive to make changes.

Presenting blueprints in person allows you to immediately answer questions and address concerns, as well as to explore new ideas while they’re still fresh. You might also consider augmenting your blueprints with a brief text document to explain your thinking and answer the most likely questions right on the spot. At the very least, consider providing a “Notes” area (as we do in this example) to briefly explain basic concepts.

As you create blueprints, it’s important to avoid getting locked into a particular type of layout. Instead, let form follow function. Notice the difference between Figures 12-2 and 12-3.

Figure 12-2. This blueprint illustrates the big picture for a consulting firm’s public site

Figure 12-2 provides a holistic view of the information architecture for a global consulting firm. It’s part of an initiative to build support for the overall vision of unified access to member firms’ content and services. In contrast, Figure 12-3 focuses on a single aspect of navigation for the Weather Channel web site, aiming to show how users will be able to move between local and national weather reports and news. Both blueprints are high level and conceptual in nature, yet each takes on a unique form to suit its purpose.

Figure 12-3. while this one focuses on geographic hub navigation for the Weather Channel site

In Figure 12-4, we see a high-level blueprint for the online greeting card web site Egreetings.com. This blueprint focuses on the user’s ability to filter cards based on format or tone at any level while navigating the primary taxonomy.

Figure 12-4. and this one demonstrates how filtering might work at Egreetings.com

It’s important for information architects (particularly those of us with library science backgrounds) to remind ourselves that web sites aren’t just about content; we can also contribute to the design of online applications and e-services. This work requires task-oriented blueprints, which are similar to the process flow diagrams often created by interaction designers.

For example, Figure 12-5 presents a user-centered view of the card-sending process at Egreetings.com prior to a redesign project. It allows the project team to walk through each step along the web- and email-enabled process, looking for opportunities to improve the user experience.

Figure 12-5. A task-oriented blueprint of the card-sending process

In Figure 12-6, information architect Austin Govella’s blueprint demonstrates how casual browsers may become engaged in a political campaign over time by interacting with the site’s content. This blueprint is as much about changes in the user’s mind as it is descriptive of the site’s content and navigation.

Figure 12-6. A blueprint depicting growing levels of engagement in a political candidate’s campaign

You’ll notice that as we dug deeper, we moved from high-level blueprints toward diagrams that isolated specific aspects of the architecture, rather than communicating the overall direction of the site. Blueprints are incredibly flexible; while boxes and connectors can’t communicate everything about a design, they are simple enough that just about anyone can both develop and understand them.

You should also note that all of these blueprints leave out quite a bit of information. They focus on the major areas and structures of the site, ignoring many navigation elements and page-level details. These omissions are by design, not by accident. For blueprints, as with the web sites you design, remember the rule of thumb that less is more.

As a project moves from strategy to design to implementation, blueprints become more utilitarian—enabling the information architect to communicate to others involved in design and development—and less geared toward strategy and product definition. “Lower-level” blueprints need to be produced and modified quickly and iteratively, and often draw input from an increasing number of perspectives, ranging from visual designers to editors to programmers. Those team members need to be able to understand the architecture, so it’s important to develop a simple, condensed vocabulary of objects that can be explained in a brief legend. See Figure 12-7 for an example.

Figure 12-7. This blueprint legend describes an intentionally simple vocabulary

In this figure, the legend describes three levels of content granularity. The coarsest are content groups (made up of pages); these are followed by the pages themselves. Content components are the finest-grained content that makes sense to represent in a blueprint. The arrow describes a link between content objects; these can be one-way or bidirectional links.

This is a minimal set of objects; we’ve found that retaining a limited vocabulary helps the information architect avoid the temptation of overloading the diagram with too much information. After all, other diagrams can be used to convey other views of the architecture more effectively.

As you move deeper into the implementation stage, your focus naturally shifts from external to internal. Rather than communicating high-level architectural concepts to the client, your job is now to communicate detailed organization, labeling, and navigation decisions to your colleagues on the site development team. In the world of “physical” architecture, this shift can be likened to architecture versus construction. The architect may work closely with the client to make big-picture decisions about the layout of rooms and the location of windows; however, decisions regarding the size of nails or the routing of the plumbing typically do not involve the client. And in fact, such minutiae often need not involve the architect either.

Detailed architecture blueprints serve a very practical purpose. They map out the entire site so that the production team can implement your plans to the letter without requiring your involvement during production. The blueprints must present the complete information hierarchy from the main page to the destination pages. They must also detail the labeling and navigation systems to be implemented in each area of the site.

The blueprints will vary from project to project, depending upon the scope. On smaller projects, the primary audience for your blueprints may be one or two graphic designers responsible for integrating the architecture, design, and content. On larger projects, the primary audience may be a technical team responsible for integrating the architecture, design, and content through a database-driven process. Let’s consider a few examples to see what blueprints communicate and how they might vary.

Figure 12-8 shows a blueprint from the SIGGRAPH 96 Conference that introduces several concepts (yes, we know it’s an old example, but it remains useful and valid).By assigning a unique identification number (e.g., 2.2.5.1) to each component (e.g., pages and content chunks), the architect lays the groundwork for an organized production process, ideally involving a database system that populates the web site structure with content.

Figure 12-8. A blueprint of a major section of the SIGGRAPH conference web site

There is a distinction between a local and a remote page in Figure 12-8. A local page is a child of the main page on that blueprint, and inherits characteristics such as graphic identity and navigation elements from its parent. In this example, the Papers Committee page inherits its color scheme and navigation system from the Papers main page. On the other hand, a remote page belongs to another branch of the information hierarchy. The Session Room Layout page has a graphic identity and navigation system that are unique to the Maps area of the web site.

Another important concept is that of content components or chunks. To meet the needs of the production process, it is often necessary to separate the content (i.e., chunks) from the container (i.e., pages). Content chunks such as “Contact Us About Papers” and “Contact Us About This Web Site” are sections of content composed of one or more paragraphs that can stand alone as independent packages of information. (We’ll discuss content chunking in more detail later in this chapter.) The rectangle that surrounds these content chunks indicates that they are closely related. By taking this approach, the architect provides the designer with flexibility in defining the layout. Depending upon the space each content chunk requires, the designer may choose to present all of these chunks on one page, or create a closely knit collection of pages.

You may also decide to communicate the navigation system using these detailed blueprints. In some cases, arrows can be used to show navigation, but these can be confusing and are easily missed by the production staff. A sidebar is often the best way of communicating both global and local navigation systems, as shown in Figure 12-8. The sidebar in the upper right of this blueprint explains how the global and local navigation systems apply to this area of the web site.

As the architecture is developed, it needs to accommodate more than just the site’s top-level pages. The same simple notation can be used, but how can you squeeze all of these documents onto one sheet of paper? Many applications will allow you to print on multiple sheets, but you’ll find yourself spending more time taping sheets together than designing. And if a diagram is too large to print on a single sheet, it’s probably also too large to reasonably view and edit on a standard monitor.

Figure 12-9. A detailed blueprint illustrating several concepts

In this case, we suggest modularizing the blueprint. The top-level blueprint links to subsidiary blueprints, and so on, and so on. These diagrams are tied together through a scheme of unique IDs. For example, in the top-level diagram in Figure 12-9, major pages, such as the one representing “Committees and officers,” are numbered 4.0. That page becomes the “lead page” on a new diagram (Figure 12-10), where it is also numbered 4.0. Its subsidiary pages and content components use codes starting with 4.0 in order to link them with their parent.

Figure 12-10. This subsidiary blueprint continues from the top-level blueprint

Using a unique identification scheme to tie together multiple diagrams helps us to somewhat mitigate the tyranny of the 8.5×11 sheet of paper. (Although you may still find that your architecture requires dozens of individual sheets of paper.) This scheme can also be helpful for bridging a content inventory to the architectural process—content components can share the same IDs in both content inventory and blueprint. This means that in the production phase, adding content to the site is not much different from painting by numbers.

If you’d like to learn more about blueprints, we suggest visiting the IAwiki site for some excellent discussion on the topic (http://iawiki.net/SiteMaps).

Just like blueprints, wireframes come in many shapes and sizes, and the level of fidelity can be varied to suit your purposes. At the low end, you may sketch quick-and-dirty wireframes on paper or a whiteboard. At the high end, wireframes may be created in HTML or with a publishing tool like Adobe Illustrator. Most wireframes fall somewhere in the middle. Let’s review a few samples.

Figure 12-13 is a relatively low-fidelity wireframe; there are no graphic elements and no real content. This enables the visual designer to focus attention on the global, local, and contextual navigation elements of the page.

Figure 12-13. A low-fidelity wireframe developed by MessageFirst’s Todd Warfel; note that all content is “greeked up” to ensure a focus on layout of content and visual elements

Figure 12-14, from a redesign project for Egreetings.com, is a medium-fidelity wireframe with a high degree of detail. This wireframe was intended to introduce several aspects of content, layout, and navigation into the discussion, and was one of many wireframes used to communicate the information architecture to managers, graphic designers, and programmers.

Figure 12-14. A medium-fidelity wireframe for Egreetings.com; more detail, more explanation, and more unique content

Finally, Figure 12-15 is a relatively high-fidelity wireframe that presents a close approximation of what the page will actually look like. This is about as far as most information architects can go without bringing a graphic designer into the picture.

Figure 12-15. A high-fidelity wireframe for Weather.com

Such a high-fidelity wireframe has the following advantages:

On the other hand, some disadvantages are:

Provided that you recognize the strengths and weaknesses of these varying levels of fidelity, wireframes can be an extremely powerful tools for communication and collaboration during the information architecture design process.

Chris Farnum, a former colleague at Argus Associates and a wireframe expert, suggests the following best practices to consider when creating wireframes:

For an excellent discussion of information architecture deliverables and wireframes and additional information, see the IAwiki (http://iawiki.net/WireFrames).

We encounter content models all the time on the Web and in more traditional media. A recipe is a great example. Its objects are a list of ingredients, directions, a title, and so on. If you “greek up” a recipe, it’ll still be recognizable. But change the logic—by putting the steps before the ingredients or leaving out an important object—and the model collapses. Content models rely on consistent sets of objects and logical connections between them to work.

Let’s say you work for a media organization that has invested lots of resources in assembling information on popular music. Certain content chunks—such as artist descriptions and album pages—number in the thousands, and they all look and work in the same way. You might sense that there is potential here for a content model that serves fans of popular music. Instead of having those fans rely on the site’s hierarchy to find content relevant to a particular artist or album, why not create a content model?

Based on content inventory and analysis, there are a few music-related content objects that may emerge as good candidates for a content model, shown in Figure 12-21.

Figure 12-21. Content objects that might be the basis of a content model for album information

How should these objects be linked? We can certainly decide that an album page ought to link to its corresponding review, artist bios and descriptions should link to each other, and so on. But it won’t always be so easy to come up with the most obvious links; even if it is fairly obvious, you may need to produce some user research to validate your work.

In such cases, consider a variation of the card sort exercise. Print out a sample of each content object and cut out the navigation options (to prevent biasing users with the current information architecture). Then ask subjects to look at each content object and consider where they’d want to go next. Then have them cluster the objects and draw lines between them that indicate navigation (they can do this with string, or they can tape the content object samples to a whiteboard and use dry-erase markers to draw their lines). Arrows indicate whether users wish to navigate in both directions or prefer a one-way link.

To perform a simple gap analysis, ask subjects which missing content objects would be nice to include in the mix. By doing so, you’ll get a sense of what should be added to your content model. If you’re fortunate, the missing objects might already exist somewhere else in your site. Otherwise, you’ll at least have some guidance in deciding which content to create or license.

At the end of the process—whether based on user research or your own hunch—you’ll have an idea of how your content model ought to work. The result might look like Figure 12-22.

Figure 12-22. An ideal content model, showing navigation and missing content objects

So you’ve identified new content objects, like a discography, that you might need to create. And you’ve linked to other content, like TV listings for televised concerts and events in a concert calendar, that is a logical extension of the content model (and possibly, a connection to candidates for future content models). You’ve also identified logical “tops” or common points of entry to this content. And ultimately, you have a sense of how users might want to navigate an area deep in the guts of your site.

Unfortunately, you’re not quite done. How do these links between content objects get made?

If you’re Amazon, you’ve got reams of usage data to draw from. Amazon employs customer-behavior data to make connections between related products in its content model; familiar examples are the products listed under “Customers who bought this item also bought” and “What do customers ultimately buy after viewing this item?” But not every organization has the traffic volume from which to cull this kind of useful data.

So the rest of us typically rely on metadata as the basis of the logic that connects our content chunks. Shared metadata does the work of linking a pair of content chunks. For example, if we want to link an album page and an album review, the logic might look like this:

IF ALBUM PAGE'S ALBUM NAME = ALBUM REVIEW'S ALBUM NAME
THEN LINK ALBUM PAGE AND ALBUM REVIEW

Now, this rule might suffice for albums with unique titles, like “Sergeant Pepper’s Lonely Hearts Club Band.” But what if the title is the ubiquitous “Greatest Hits”? If you’re lucky, the object has a unique identifier, like an ISBN, that can be used as connecting metadata (many classical albums do have unique IDs; unfortunately, pop albums don’t):

IF ALBUM PAGE'S UNIQUE ID = ALBUM REVIEW'S UNIQUE ID
THEN LINK ALBUM PAGE AND ALBUM REVIEW

But as that’s often not the case, your linking logic will need to get a little more complicated, and additional metadata attributes will be necessary:

IF ALBUM PAGE'S ALBUM NAME = ALBUM REVIEW'S ALBUM NAME
AND ALBUM PAGE'S ARTIST NAME = ALBUM REVIEW'S ARTIST NAME
THEN LINK ALBUM PAGE AND ALBUM REVIEW

As you can see, these rules rely on metadata. Do the required metadata attributes exist? The bad news is that you’ll probably need to invest in creating new metadata from scratch or acquiring it.

Of course, metadata availability is a consideration with just about any information architecture project of any size. And the good news is that the content modeling process will help you decide which metadata attributes to invest in by helping you select the most useful from the wide range of possibilities.

Consider our arrows in Figure 12-22. Which metadata will be necessary to drive the logic behind each link? Make a simple table listing each content object, which other objects it should link to, and the metadata attributes required to make those connections. It might look something like this:

Notice a pattern here? Certain metadata attributes show up more frequently than others. These are the attributes that are most necessary for the content model to succeed. If you’re operating with limited resources (and who isn’t?), now you’ll have an excellent way to prioritize your investment in metadata attributes.

As you can see, content models are as much an exercise as a deliverable. While the primary output is a useful IA deliverable that informs the design of contextual navigation deep within a site, the process also generates two invaluable, if secondary, benefits.

First, content modeling forces us to determine which content is most important content to model. As you can see, it’s work—not necessarily terribly difficult, but not trivial. Most likely you can’t create content models for all of your content. So you’ll have to ask yourself: which content fulfills the requirements of homogeneous, high volume, and, most of all, high value? You might find a set of priorities falls out of this exercise; for example, perhaps this year you’ll develop a product-area content model, next year a support-area content model, and later you’ll link those two models together for even greater benefit.

Second, content modeling also forces you to choose which of the many metadata attributes are the ones that will make your content model operational. The combination of focusing on and narrowing down to critical content and critical metadata means a huge simplification and clarification of a large and complex problem space. And that’s what the Pareto Principle, the information architect’s best friend (and commonly referred to as the 80–20 rule), would recommend.

In the research phase, the design team developed a sense of the desired graphic identity or look and feel. The technical team assessed the information technology infrastructure of the organization and the platform limitations of the intended audiences, and they understood what was possible with respect to features such as dynamic content management and interactivity. And, of course, the architect designed the high-level information structure for the site. Design sketches are a great way to pool the collective knowledge of these three teams in a first attempt at interface design for the top-level pages of the site. This is a wonderful opportunity for interdisciplinary user interface design.

Using the wireframes as a guide, the designer now begins sketching pages of the site on sheets of paper. As the designer sketches each page, questions arise that must be discussed. Here is a sample sketching-session dialog:

Developer: “I like what you’re doing with the layout of the main page, but I’d like to do something more interesting with the navigation system.”

Designer: “Can we implement the navigation system using pull-down menus? Does that make sense architecturally?”

Information Architect: “That might work, but it would be difficult to show context in the hierarchy. How about a tear-away table-of-contents feature? We’ve had pretty good reactions to that type of approach from users in the past.”

Developer: “We can certainly go with that approach from a purely technical perspective. How would a tear-away table of contents look? Can you sketch it for us? I’d like to do a quick-and-dirty prototype.”

As you can see, the design of these sketches requires the involvement of members from each team. It is much cheaper and easier for the group to work with the designer on these rough sketches than to begin with actual HTML pages and finished graphics. These sketches allow rapid iteration and intense collaboration. The final product of a sketching session might look something like Figure 12-23.

Figure 12-23. A basic design sketch

In this example, Employee Handbook, Library, and News are grouped together as the major areas of the web site. Search/Browse and Guidelines/Policies make up the page navigation bar. The News area defines space for a dynamic Java-based news panel. This sketch may not look much different from a wireframe. In fact, the team may have begun with an information architect’s wireframe, then iterated on the design until arriving at this sketch, which in turn may be the basis for a revised and final wireframe.

Starting with a sketch—whether a formal wireframe or something more “back-of-the-napkin”—is critical to the success of interdisciplinary meetings. The sketch provides a common focus for each participant, minimizing the attention paid to the individual personalities around the table. It also makes it more likely that participants will be using the same terminology to discuss the design; shared terms for design concepts often emerge directly from the sketch itself.

Finally, note that design sketches aren’t necessarily “owned” by the information architect. For example, sketches that describe functional requirements may be under the purview of the designer or developer. Be wary of getting caught up in ownership issues; contributing to the design, regardless of who is driving Visio, OmniGraffle, or Illustrator, is far more important to the project’s outcome.

For the information architect, a high point of the design process is the creation of web-based prototypes. More than sketches or scenarios, these digital renditions show how the site will look and function. They are concrete and often aesthetically compelling; you can actually see how your work will really come together, and maybe even kick the tires yourself.

While the balance of attention now shifts toward aesthetic considerations such as page layout and graphic identity, the prototypes frequently identify previously unseen problems or opportunities related to the information architecture. Once your architecture and navigation system are embodied in actual web pages, it becomes much easier for you and your colleagues to see whether they are working.

The designer may begin with two concepts based on a single information architecture. After getting feedback from the client, the designer and architect may work together to adapt and extend the preferred concept. At this point, conceptual design officially ends, and production actually begins. The most exciting challenges for the architect have been met, and you now begin the days of detail.

Ideally, the production process would proceed smoothly in a paint-by-numbers manner, and the architect could sit back and relax. In reality, you must be actively involved to make sure the architecture is implemented according to plan and to address any problems that arise. After all, no architect can anticipate everything.

Many decisions must be made during production. Are these content chunks small enough that we can group them together on one page, or should they remain on separate pages? Should we add local navigation to this section of the site? Can we shorten the label of this page? Be aware that at this stage, the answers to these questions may impact the burden on the production team as well as the usability of the web site. You need to balance the requests of your client against the sanity of the production team, the budget and timeline, and your vision for the information architecture of the web site.

You shouldn’t need to make major decisions about the architecture during production because hopefully these have already been made. Discovering a major flaw in the architecture at this point is an information architect’s nightmare. Fortunately, if you’ve followed the process of research, strategy, and design, this is unlikely. You have worked hard to define the mission, vision, audiences, and content for the web site. You have documented the decisions made along the way. You have resolved the top-down and bottom-up approaches through content mapping and detailed blueprints. Through careful planning, you’ve created a solid information architecture that should stand the test of time.

Still, it’s worth reminding yourself that an information architecture can never be perfect. Factors of content, users, and context are constantly changing, and the architecture will, too. It’s more important to invest your energy in educating your colleagues that information architecture design is an ongoing process, rather than fighting with them to get it “right.”

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.

Your 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 guidance—a user’s manual, really—to 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.