By: Christina Wodtke

February 10th, 2001

Reader Rating: 8.5

One of the hottest topics these days in Information Architecture circles is documentation. This is probably partly because the IA's role is so ill defined. Our jobs sit perched between engineering and graphic design: go too far in one direction, we're doing the coding, go to far in the other and we are doing the design. Neither role maximizes the architect's key skills; defining the organizational structure and behavior of the web site or application. An IA is most effective when they leave implementation and final graphic design out of the mix. The documents they create to express this have to be crafted with equal skill and diplomacy.

There are seven typical deliverables an IA will produce. Occasionally they will not produce all seven, sometimes the deliverables will include others such as a thesaurus or taxonomy. I've presented them in rough chronological order, though these are a toolset, not a rigid methodology, and the choice of which to use and when to use them will depend on the needs of the project.

1. Conceptual Model

User experience guru Don Norman [1] defined three types of models that occur when creating a product

• Implementation models
• Conceptual models
• Mental models.

A conceptual model is most often a graphic, though it can be a chart, a written paragraph or a flowchart. The key is that it expresses an explanation of the system's behavior to the user that is easy and intuitive-it does not have to be how the system actually works.

Diagram courtesy of Noel Franus, carboniq.com [3]

2. Content Inventory and Organization

Most typically used for content rather than application sites. The content inventory may be provided by the IA or the client. It is exactly what you might guess: a complete list of all the content that the site holds and will hold. For sites particularly rich in content, it may be a list of types of content. Once the content is aggregated, the most simple way to deal with organizing it is to perform a card sort. Typically the names of each of the items is written on an index card. These are then sorted by likeness. Card sorts are most effective when performed with the end user of the system, rather than only by the IA. I've done card sorts with cut up excel spread sheets, and also with post-it notes on a white board (my personal favorite); the only important thing is to have the card sort done on discreet bits of paper- the sorter needs to be able to play, rearrange, and not get caught up in perfection.

Once the content has been grouped, the cart sorter should be requested to label each collection. The IA can then take the card sort (or card sorts, doing this exercise with at least three users is a good idea) and refine the collection and labeling.

3. User Flows/Scenarios

[4]
User flows are simple diagrams that follow a user down a path of activity. Occasionally they look like storyboards, other times like flow charts. The important thing is to not outline every single possible behavior, but rather show most likely user experience. It's a good way to understand what the product does without being confused by every tiny detail. It is particularly useful if one needs to explain the core interactions to someone new or not deeply involved with the project.

Scenarios are a written equivalent of the User Flows, and are often a good jumping off point for them. To create them, the development team gathers together to tell the story of a user working with the system. The most effective way to do this is using a technique called personas. With personas, you start by creating archetypal users: first giving them names, then filling in relevant demographic and psychographic details about them. And finally you can describe their ideal interaction with the system you are designing.

Imagine you are designing a new version of excel. Telling the story of Jane who is 24 and working in accounting would create a different story than one describing Sarah, 45, working at home to do her budget. Both stories are potentially more useful than a story that tells user x accessed chart creation wizard: visualizing an actual person trying to use a system typically inspires much more compassionate designs. To learn more about personas, I recommend Alan Cooper's [5] book "The Inmates are Running the Asylum."

4. Task Analysis

From the scenario, you can move toward a task analysis. This is a discrete step-by-step analysis of how users accomplish their desired tasks. This allows the IA to carefully analyze each step a user needs to complete any give task.

My favorite example has always been one Peter Merholz [6] put together: Imagine Wily Coyote trying to buy an anvil for one of his nefarious schemes from the web:

(A.)Buy An Anvil
(1.)Find The Anvil
(a.)Search For Anvil
(i.)Type in "anvil" in Search box
(ii.)Read results
(b.)Browse the Store
(2.)View anvil
(B.)Purchase The Anvil

Of course a real task analysis would be quite more detailed and complex, but the essential idea is here.

5. Site Map

This is the IA's workhorse, the one thing we all do when building a website. Jesse James Garrett has undertaken the Herculean task of creating a standardized language for site maps; unfortunately most IA's still use the systems they developed early on when IA's weren't talking to each other. A site map can be small and simple, or can take up a hundred pages or be printed out on a plotter 6 foot wide. It all depends on the site and the needs of the project. The map documents the various pages or page types throughout the site and the user paths to and from them. It is typically started early in the project, and refined throughout.

from Jesse James Garrett's Visual Vocabulary [7]

6. Page Architecture

Also called wireframes or schematics, these are probably the most controversial of the IA's deliverables. Too precise wireframes, and visual designers feel dictated to, too loose and the architecture can be misinterpreted.

[8]
- Wireframe

One agency has solved this by having the visual designers create the wireframes, other companies make their page architectures look more like flow charts, eliminating design from them entirely. No matter how you decide to represent them they must show:

• Items on page
• Importance of each item on page
• Behavior of each item on page

7. Decision tables

The tables allow precise documentation of the design of every interaction possible. It is especially useful when designing error handling. Often errors are ignored by design, and when engineering codes the product, they have to make up error messages. This can result in messages like "error in dll 5034. click okay to continue" Not a happy user experience.

Again, this is not a complete list of every possible tool an IA may use but these are among the most common. Every project is unique, and the role each IA plays within the company is also unique. However, the IA's job is to define the structure and behavior of the systems as it is perceived by the user, and these seven deliverables are an excellent way to make sure the IA's thinking is clear and clearly communicated.

[1] http://www.jnd.org/
[2] http://www.webmasterbase.com/static/iatoolbox/concept.html
[3] http://www.carboniq.com
[4] http://www.webmasterbase.com/static/iatoolbox/userflow.html
[5] http://www.cooper.com/
[6] http://www.peterme.com/
[7] http://www.jjg.net/ia/visvocab/
[8] http://www.webmasterbase.com/static/iatoolbox/wireframe.html
[9] http://www.webmasterbase.com/static/iatoolbox/pagearch.html