This 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 situation.

  • 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 map.

Sample (pdf)

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 or implementation.
  • Real Use Case - Narratives that incorporate the current technology and/or site design. This is basically the same thing as a Process Flow.

Sample 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)

6. Wireframes

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.

HTML Wireframes

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)
Sample Wireframes 2 (pdf)
Sample 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 1
Sample Story Board 2
Sample Story Board 3 (pdf)
Sample Story Board 4 (pdf)
Sample Story Board 5 (pdf)

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.