louisrosenfeld.com logotype

Home > Bloug Archive

Sep 15, 2004: Information Architecture Guidelines

A colleague writes:

I'm helping write an IA guide where we are documenting the organization, navigation and labeling methods used by the site, the rationale behind them, and helpful hints for how to add content to the site going forward within this framework... We are really struggling with how to write and format this guide to make it usable by the site's content contributors. Lou, do you know of any examples of similar guides that we might reference?

Really good question, and no, I don't have an immediate answer. Oddly I've never really come across what I'd call a true, comprehensive IA guide; just fragments thereof scattered here and there. And, in a way, this sounds like a question for the technical communicators out there, with its focus on writing and format.

As with any help content, much of the challenge revolves not so much around which guidelines to create, but where and when to make them available. Seeing IA guidelines as a singular blob to be stowed away in a stand-alone publication or site misses the point of documentation (and maybe this explains the dearth of comprehensive IA guides?).

How might we slice and dice IA documentation? Well, for one, there's procedural stuff that's especially critical to ongoing maintenance. Among it are processes that happen regularly, even daily, like titling documents and tagging them with metadata. Guidance to these regular procedures probably should be embedded into the processes themselves if they're to be taken seriously. That's expensive, of course; your organization may not have the explanatory expertise, much less the technical ability, to embed contextual help into its CMS, for example. On the positive side, these processes may have many users but just a few roles (e.g., content authors, indexers). So the investment into contextual help will at least go reasonably far.

There also is procedural stuff that may take place less frequently or even in an ad hoc manner, like indexing content for search or updating a controlled vocabulary. It seems safer to stow these guidelines in an intranet or a single document. The challenge here is that these disparate procedures may involve many different roles spread out among a few individual information architects, content managers, IT staff, marketing staff, and so on. Perhaps it makes sense to treat the presentation of these guidelines as a true IA challenge, requiring standard IA methodology to develop a useful and usable architecture. For example, applying IA methods here might reveal that the content publication lifecycle would be a suitable organization model.

Finally, there are guidelines that serve as design rationales, taking on an almost philosophical flavor. These might include a justification for moving from an information architecture that is org-chart-centered to one that's subject-oriented. Site maintainers need to refer to such rationales for their own reference from time to time. But these guidelines often play a political role, helping information architects and others cover their asses during internal battles over main page real estate and so forth. Such guidelines may be captured in policy documents, but are much more important to provide in Powerpoint (sorry, Ed Tufte) or some other presentation format. Summaries of these guidelines, presented to obstructionist colleagues of all brands, are ultimately far more important that the detailed guideline documents themselves, which few will bother to read.

Heh. I didn't think I had an answer to this question, and despite the ample verbiage above, I guess I don't. Not sure anyone does, as the answers will always vary depending on your context. Instead, I'm suggesting a way to look at the question that might help you produce the best answer for your specific context.

And now, the original counter-question that I'd originally thought I'd submit here: does anyone know of any examples of complete IA guidelines? If so, post them here and maybe we can eventually get them added to the wonderful Tools section of the AIfIA site.

email this entry

Comment: Livia Labate (Sep 15, 2004)

Jeff Veen and Doug Bowman showed two great examples during the Adaptive Path User Experience Week.

One was from Atomz (Doug tells me it's not publicly available) and the other was from PBS: http://www.pbs.org/remotecontrol/bestpractices/

The PBS Best Practices for Member Station Web Sites has a particularly great structure because it doesn't focus on 'information architecture' as a separate entity, but conveys various aspects of the overall experience in a balanced way.

It clearly communicates to the partner Web sites how to achieve their main objectives through good implementation.

To me, good guidelines, style guides or whatever sort of documentation that informs future design should clearly and explicitly address:

* user needs and behavior (i.e.: do THIS, so the user can do THAT)

* business goals (i.e.: do THIS, to support THAT strategy)

In the end you have the whole experience flow outlined in a way that both informs design and functions as project memory. (i.e.: do THIS, so the user can do THAT, to support THAT strategy). Sounds great, doesn't it? It's hard to do.

It is rare to have all these elements documented in the same place but those two items are (or should be) the reasoning behind the implementations, so no other place seems more natural for them to live. This reasoning (do THIS, so the user can do THAT, to support THAT strategy) should be written anyway, but since they are generally not written anywhere else (because people don't document, trust their memories too much, think they'll be around forever, don't care about the future, etc), it is best to record them in the guidelines/style guide/whatever so they can exist outside people's minds.

Comment: Livia Labate (Sep 15, 2004)

And since you got me started...

I am currently working on a portal, defining how partner content is to be used. Portals are like very messy vines that grow (organically, of course) under very little control or ability to track growth.

Integrating content provided by a partner can take many forms: simply linking to a partner site, using a content feed from a partner within the portal structure, co-branding of pages hosted locally, co-branding of pages hosted with partner, etc...).

How to write guidelines for every possible partner content scenario? Superficial/broad guidelines would suffice? What MUST be on the guidelines - necessary, recommended and/or suggested solutions? I don't have final answers for these questions and I believe they are very contextual. But one topic I am concerned about lately is fitting *branding* guidelines into this sort of documentation.

It is not sufficient (in my scenario) to document just the 'original' organization, navigation and labeling used by the site when the partner contents will grow, their structures will become more complex and our portal structure will expand as well.

What's an IA to do?

* My recommendation (previous post) are from a portal perspective, but different models for guidelines may work better for different types of content delivery mechanisms.

* IA (restricting that meaning to organization, navigation and labeling), is highly impacted by the business branding strategy, so having that aspect addressed in the guidelines can ensure that partners are aware and can comply with what the business expects as a whole, not just technical/structural needs.

* Lastly, when you create guidelines for *real* you are sure to find the glitches and problems between the original strategy and the final implementation. Which makes the *process of writing* the guidelines, great for QA, success metrics and iteration.

Comment: Lou (Sep 16, 2004)

Great ideas Livia. You've got me wondering: is there a design guidelines analog from organizational design? What do those responsible for reorgs do in terms of capturing structural guidelines?

Comment: James Robertson (Sep 16, 2004)

Hi Lou, this is something that was developed by participants at one of our post workshops regarding an "intranet guide":


Certainly not a comprehensive answer, but perhaps useful...

Cheers, James

Add a Comment:



URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.