file has moved to my updated site THIS PAGE WILL REDIRECT
Information Architecture Deliverables and Diagrams 12/2002
In my work as a web designer/IA I have come across many inconsistencies
in the way Information Architects and other Web professionals refer to
Web information architecture deliverables and diagrams. In speaking with
various Web design companies I have come across multiple terms for the
same deliverables. Information architecture is a relatively new field
which has yet to develop a consistent and universal set of deliverables,
and terminology to refer to those deliverables. I also haven't come across
a central repository of IA deliverable and diagram documentation. This
document is an attempt to fill that void.
What are the most effective deliverables? The answer depends on the
situation, audience, budget, time constraints, skill set of your team,
and various other factors. Learning how to create these deliverables
is the easy part. Gaining an understanding of when to use them, and in
what format, is the tricky part.
The following are the most widely used IA deliverables. However, there
are additional deliverables which some consider to be the responsibility
of the IA, while others would assign them to perhaps a PM or designer.
The most widely used name for the deliverable is listed with additional
synonyms listed below.
1. Content Inventory
A content inventory is intended to provide a consolidated snapshot
of all the major pages on a Web site. This would include text, graphics,
and multimedia. Some even go as far as to break content down into individual
pieces or paragraphs of content. Sometimes a content inventory is performed
on content that is not yet part of a Web site. This would be helpful
for an organization that is collecting content to be placed on a new
Web site. Card sorting would be helpful for organizing content in this
- Survey -
A high level review of a site's main sections and pages. It enables
you to develop an understanding of the general site scope and major
chunks of content.
- Detailed Audit -
this is a comprehensive inventory of every page on a site. This inventory
will list every page's filename, title, URL, and possibly its file
type and a description. It's also helpful to assign a unique page
ID that will correspond to the pages location on the Site Map.
- Content Map -
This simply entails laying out the site content in a graphical format.
I haven't seen this used widely, and I'm not sure how much use it
would serve. If you're performing a content inventory on a current
site, then an effective site map might nullify the need for a content
2. User Profile
A user profile is a realistic (but fictional) example of a target
audience member. The profile commonly takes the form of a one page
piece that lists the user's name, occupation, education, demographic
characteristics, computer/web experience, and site goals or likely
tasks. A stock photography picture is usually used to give a face to
the profile. These profiles can be extremely useful in keeping the
web team focused on the user's needs. These may not be necessary for
usability experts, designers, or information architects, all of whom
should have a firm grasp of user-centric design, but they can be beneficial
for project managers, programmers, and clients. When making decisions
it's helpful to be able to say "John B. really would have trouble
with this," or "Adding this link here would really make life
easier for Sharon." User profiles also help to reinforce the importance
of an Information Architect. It is a deliverable that documents the
establishment of target audiences, a process that might have taken
a considerable amount of effort and research.
3. Use Case
Also known as: User Scenario, Task Analysis
Use cases are narratives that describe how a user might use a system
or site. They illustrate a sequence of events that an actor (external
agent) might go through in order to accomplish their goal.
- Essential Use Case -
Narratives that remain relatively independent of a specific technology
- Real Use Case -
Narratives that incorporate the current technology and/or site design.
This is basically the same thing as a Process Flow.
use case (pdf)
4. Process Flow
Also known as: User Flow, Interaction Flow, User Interaction Flow
A process flow illustrates how a user might perform a specific process,
or use a system. A process flow is essentially the same thing as a
Real Use Case. Sometimes these deliverables will look a lot like a
flow chart or storyboard.
5. Site Hierarchy Map
Also known as: Blueprint, Hierarchy Diagram, Flow Diagram, Site Architecture
Map, Site Flow Chart, Site Wireframe, Web Map
Site maps are one of the most widely used information architecture
deliverable (along with wireframes). They show the overall structure
and hierarchy of a Web site. They can be used as the first step in
laying out the information architecture of a site, and will provide
the framework upon which to base site navigation. When I set out to
understand the IA of a current site, or design an IA for a new site,
I start by sketching out a ruff site map. Site maps can be constructed
in a wide variety of formats, but the general structure and principles
remain relatively consistent.
Sample Site Map (pdf)
Also known as: Page Architecture, Low Fidelity Mock-Up, Page Schematic
Wireframes (combined with Site Maps) are the bread and butter of information
architects. They are useful for conveying the general page structure
and content requirements for individual pages. They need to achieve
a happy medium between being to precise and too loose. What I mean
by this is that a wireframe that is too precise or detailed may leave
little creative room for the designer. A wireframe that is too loosely
defined can easily be misinterpreted by designers and developers. The
format used should be dependent upon the audience. Using detailed wireframes
will frequently flush out new requirements and questions that nobody
has thought about yet. They also help to keep a paper trail of functional
and design decisions that are made. I sometimes use wireframes to get
people thinking and generate requirements.
Wireframes can end up evolving into the default requirements document
for a system. It can be very productive and thought provoking to be
able to look at the Website's structure and functionality on paper.
Countless hours and money can be saved by producing wireframes before
starting system development.
Information Architects and designers sometimes end up creating the
initial HTML layouts that are then turned over to a developer for "real"
programming. This often makes sense, because in some cases it's the
IA or designer with the best command of HTML layout and design. HTML
may be used to create basic wireframe templates that can be used for
usability testing or to get client feedback. In other cases the HTML
is created in order to keep tight control on the design, rather than
leaving it up to the programmer.
Sample Wireframes (pdf)
Wireframes 2 (pdf)
Wireframes 3 (pdf)
7. Paper Prototype
Also known as: Low Fidelity Prototype
Paper prototyping involves using screen shots and/or hand sketched
page diagrams to quickly elicit user feedback and identify interface
IA problems. Essentially it involves conducting a usability test using
a low fidelity prototype. These prototypes can be created electronically
using programs such as MS Word, Excel, Visio, or various WYSIWYG editors.
However, in many cases paper prototypes are nothing more than loosely
hand-sketched designs. The quicker these prototypes can be created
the greater the benefit. They shouldn't incorporate specific design
elements such as color, style, fonts, detailed graphics, etc.
You may be hesitent to present something that resembles a 3rd graders
art project to a client. However, with a bit of education the client
will be appreciative of the time and money you are saving them.
8. Story Board
Also known as: Blueprint, Schematic, Grey Model, Interaction, Interaction
Wireframe, IA Requirements Document, Design Document
Storyboards typically combine information from process flows, site
maps, and other IA deliverables. They can be used to illustrate a single
screen or a whole system or site. They usually offer screen shots or
some type of graphical representation of the screens, combined with
a narrative description. Storyboards help to document the functionality
of the site and describe how users will potential use the interface.
These deliverables can be used by programmers, project managers, upper
management, and clients to ensure that everyone is on the same page.
Storyboards often turn into the initial requirements documents that
programmers begin coding from. These deliverables provide an excellent
chance to get client buy in and sign-off on the proposed function laity
and IA of a site. Storyboards can be similar to a detailed wireframe,
and there is a lot of crossover between the two.
Sample Story Board 3 (pdf)
Sample Story Board
Sample Story Board
9. Style Guide
Style guides are used to document baseline design requirements for
a site. They usually define font classes and a wide range of various
design conventions to be followed. This deliverable would generally
be considered the responsibility of a designer, but in some instances
the Information Architect may be covering multiple roles (as is the
case with me).
Sample Style Guide (pdf)
In part 2 we take a look at the factors
that influence the use of these IA deliverables.