Floozy Speak!

i have to blog everyday other wise the site cant maintain a shape i like...

Information architecture and interaction design are two sides of the same coin. (See "The Elements of User Experience" for definitions of these terms as they are used here.) Diagrams of contemporary sites inevitably involve both sides. But for each, the objectives of the diagram are slightly different.

In both cases, the diagram focuses on what we call macrostructure, providing just enough detail to enable team members to get the "big picture". The task of the architect is to determine the appropriate level of detail to meet this objective. The specific page-level detail, or microstructure, is detailed in other documents that the architect may not be primarily responsible for developing.

When describing information architecture, the diagram should emphasize conceptual structure and organization of content. Note that conceptual structure is not the same as navigational structure. The objective of the information architecture diagram is not to provide a full-blown navigational specification; this level of detail is best kept in other documents, where it is less likely to confuse and distract.

When describing interaction design, the diagram should emphasize how the user flows through defined tasks, and what the discrete steps are within these tasks. As with navigation, details of interface should not appear in the diagram -- if you find yourself drawing buttons and fields, you're probably loading the diagram down with excess detail.

This vocabulary is based on a simple conceptual model encompassing both information architecture and interaction design:

The system presents the user with paths.
The user moves along these paths through actions.
These actions then cause the system to generate results.

If for some reason we want to prohibit this upstream movement (such as in cases where some irreversible action like deleting a record has taken place), we use a crossbar (just a short perpendicular line) on the opposite end of the arrow to indicate this.

In some cases, it may be necessary to place an additional arrowhead near the upstream page to clarify the directionality of the flow in a more complex architecture. (A practical note: Many diagramming applications do not allow the user to string arrows together in this fashion. To work around this, the shape libraries include a "gluedot" element, an invisible element consisting of a single connection point. Use this element to connect arrows together.)

Connectors and arrows can also be labeled, but the use of these should be limited to cases in which the action taken by the user needs to be clarified. If the labels become long and unwieldy and start to clutter the diagram, point the reader toward a footnote or appendix entry.

If you'd like to see how the whole system comes together, here's a sample diagram of the information architecture and interaction design of MetaFilter. (I wasn't involved in the development of this site; this diagram was simply reverse-engineered from it.)

Scott Larson created this handy cheatsheet for quick reference to the various conditional elements. And for those interested in creating their own shape libraries for use with an application other than the ones below, here's a PDF of all the shapes (thanks to Ross Olson for the suggestion).

This vocabulary necessarily represents only a first step. As information architecture and interaction design for the Web continue to evolve, situations will inevitably arise that this vocabulary does not address. Your feedback and recommendations for the next revision of this vocabulary are welcome.