Articles on content inventory

Originally published February 2006

In part one of Web Information Architecture Deliverables and Diagrams I discussed the various deliverables and diagrams that are commonly used throughout the industry. In part two we take a look at the factors that influence the use of these deliverables and various implementation examples.

Understanding how to create information architecture deliverables is the easy part. Sure, creating documentation for large scale sites with complex functionality can be very challenging and tedious. But it takes additional expertise and a lot of trial and error to develop an understanding of how to best apply these deliverables. There is no magic formula to decide which deliverable or combination of deliverables to use. It takes a lot of experience to know when and how to best utilize the various deliverables available. This document takes a look at some key variables that should influence our decisions.

Access to programmers

Ideally designers, information architects, and programmers would work together closely as a Web site is built and refined. However, this isn’t always possible. I have been involved in projects where I was responsible for the requirements analysis, information architecture (IA), and design. But the actual coding was turned over to a set of programmers in another division or organization. Or perhaps conflicting requirements on other projects prevent you from maintaining regular contact with the programmers. In cases such as these it is important to create detailed documentation to guide the development. There may or may not be an open line of communication between the people that created the deliverables and the developers who are now responsible for developing from it. In the world of Government contracting this transition isn’t uncommon among separate contractors. Basically you can’t assume that the programmers will interpret your deliverables the way you envisioned, and you can’t assume they will be able to get clarification form you in the future. You need to explicitly describe how the system is designed to be implemented.

Programmers with design skills

Obviously the individual skill sets of programmers vary greatly. Some are former engineers or scientists with little or no design skills or artistic eye. Others may have once been designers, graphic artists, or just have been blessed with natural artistic ability. Some programmers may have a good understanding of Web usability, others may not. Senior developers may have enough experience to adhere to general design and usability guidelines that junior developers may not recognize. It’s important for you to recognize these characteristics. You need to understand the skills of the programmers you work with and customize deliverables accordingly.

It seems most Web programmers fall into one of two categories. The first group is part developer and part designer. The other sees things in black and white and will program exactly what is given to them. Once you are familiar with the design skills of the developer(s) you can cater your deliverables to match their needs. In some cases basic wireframes or flow diagrams may be enough for a programmer. It doesn’t take much time working with a programmer to ascertain whether they are capable of taking a rough design or wireframe and creating an effective interface from it. Some developers will program to precisely meet the requirements, but are incapable of injecting their own design elements. The key is to communicate the relationship and roles. If a developer has general design skills, then it may make sense to give them some freedom.

HTML skills

In some cases it may be the designer, and not the programmer, who is best suited to create the initial HTML for a site. It’s important to recognize that a designer’s or IA’s involvement doesn’t necessarily have to end with a site map or Photoshop mockup. Often it makes sense for the designer to be responsible for creating the HTML templates. Again, it comes down to recognizing and capitalizing on the skill sets of your team. In an ideal situation, and when I have enough time, I prefer to turn functional HTML over to a developer and let them do the “real” programming.

Targeted audience

It’s always important to understand who the audience, both the primary and secondary, for the deliverable you are creating is. You may be putting together a story board with detailed wireframes for the programmers, but the document may inevitably end up in the hands of management. Thinking about the documents possible future uses can help. Adding additional documentation about the purpose and/or intended audience for the document can help add context. On a project with frequently changing requirements a good approach would be detailed wireframes with enough documentation for programmers, clients, project mangers or anyone else involved.

Turnaround time

How quickly are these deliverables needed? In some cases there may only be time to sketch out rough designs on paper (paper prototypes) and put together general work flow diagrams. In other cases there may be time to put together detailed wireframes, and in other instances time to create HTML designs for the programmers to use.

Staff workloads

There is usually a tradeoff between the workload of the designer/IA and the programmer. High fidelity designs and documentation require less overall effort for programmers than if they were given basic requirements and design specifications. If the programmer is given HTML they won’t need to spend time on layout and design. So whose time is more valuable? Who currently has the most on their plate? On a tight budget, who has the higher hourly rate? These types of questions should ultimately determine where the handoff lies.


Perhaps your group or company has been tasked with creating the design and/or information architecture for a Website. The actual development, testing, and implementation will be handled by another group. The fixed budget for your portion of the work has been set. Depending on the budget you will either have to deliver low-fidelity (wireframes, process-flow, etc.) or high fidelity (detailed story-boards, HTML) deliverables. Obviously the latter requires a greater level of effort and expense.

Project/System Use

What type if system is being developed or who is it being designed for? If it’s a non-critical internal system designed to be used by staff, then it may be ok for the programmer to work with basic requirements. Obviously you never want to implement a system that sacrifices usability or accessibility, but it may be ok to deploy these types of systems with a less polished design. Websites that are higher profile (e.g. Corporate Websites, Large-scale systems) should be given additional attention. It’s important to keep tight control of the design and information architecture. Programmers should be working from detailed requirements so they don’t have to make design decisions on their own.

Familiarity with developers

If you regularly work with the same group of programmers over time you will learn their tendencies and individual skill sets. You may have developed a level of comfort with programmer A that allows you to hand them some basic flow diagrams and design specs and have confidence that they will be able to work successfully from them, making appropriate modifications where needed. However, programmer B may need precisely detailed deliverables or HTML design templates, or else the final product will suffer.

Now let’s take a look at some real world scenarios and the information architecture deliverables I would likely use in each.

Example 1

My company has been asked to provide consulting services for a client that needs to design and launch a large new corporate Website. The organization has an IT group that will develop the site, but is looking for some outside expertise in the requirements analysis, design, and information architecture. They will be paying us on a cost (time and material) basis and have a relatively large budget set aside for our services. They want to spend the money up-front to get it done right and avoid costly redesigns in the near future. Fortunately the schedule isn’t overly tight and there will be enough time to do the work the right way. The work that I deliver on this project is a reflection of our company’s capabilities and will potentially lead to future work with the client. Therefore, I am going to spend additional time refining and “prettying up” the deliverables. Since the deliverables will be handed off to another company, they will contain extensive documentation and comments. After working closely with the client to determine requirements and establish target audiences, I decide that we will create the following deliverables.

  1. User Profiles
  2. Content Inventory
  3. Sample Use-Case Scenarios
  4. Web Site Map
  5. Paper prototypes (documentation of testing our IA assumptions)
  6. Detailed website wireframes / story boards
  7. Mockups
  8. Web style guide
  9. HTML designs and .CSS

Example 2

I have been asked to assist another division in my company with the redesign of a website for a client they are currently working with. Let’s assume the budget they can commit to the design and architecture is enough to cover detailed wireframes and site mockups, but not enough to cover HTML designs. Fortunately they have a junior developer with good design skills who can effectively (and affordably) turn the wireframes into a fully functional Web site. I won’t be in close contact with the developer once I have handed off the wireframes, so I will make sure to add a lot of notes and documentation on the wireframes.

Example 3

My group was awarded a new contract to develop a Website for an existing client. The timeline is very aggressive so we need to get moving quickly. The site is pretty basic and doesn’t require a lot of requirements analysis. The developers I will be working with are in my group so we will be working closely together as the project moves forward. I am already familiar with the skill sets of the programmers and their existing commitments on other projects. Therefore I determine that the quickest and most effective use of my time will be to sketch out some rough designs and put together some basic wireframes. I will use these to make sure the programmers don’t have any problems with the proposed functionality, and to get a quick buy-in from the client. Then I am going to build out the HTML for each major page or section. There isn’t a need to build out every page, just the ones that are unique. Once the HTML designs are finished the developers can quickly add their code and database connections, or break the pages up into includes or database elements. This approach gives the programmers a good head start and reduces their required level of effort.

Originally published December 2002

Examples of Wireframes, Site Maps, Story boards, Use Cases, Paper Prototypes

In my work as a web designer and 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 groups I have heard multiple terms for the same deliverables. Web 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 is Information Architecture?

Information architecture is the foundation open which websites are built. You can think of it as the blue prints for a website. It defines a website’s structure, hierarchy, and navigation.

What are deliverables? 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.

Part 2 – How to use Information Architecture Deliverables

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 also displayed. Some Web information architecture examples and samples are linked to.

Web Information Architecture Examples

1. Content Inventory (aka Content Survey, Audit)

A content inventory is intended to provide a consolidated snapshot of all the major sections, pages, and content 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.

Here a a couple examples of Web content invent roy variations.

  • 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 content inventory (pdf)

Read more about content inventories for the Web

2. User Profile (aka Personas)

A user profile or persona is a realistic (but likely 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.

Read more about user profiles for the Web

3. Use Case (aka User Scenario, Task Analysis, User Flow)

Use cases are narratives that describe how a user might use a system or site. A use case illustrates a sequence of events that an actor (external agent) might go through in order to accomplish their goal. A use case is similar to a process flow.

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

Read more about use cases for the Web

4. Sitemap (aka Site Map, Site Hierarchy Map, Site Diagram, Blueprint, Web Map)

Site maps are one of the most critical and widely used web information architecture tools (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 web 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)

Read more about Web sitemaps

6. Wireframes (aka Wire Frame, Page Architecture, Low Fidelity Mock-Up, Page Schematic)

Information Architecture Wireframes (combined with Site Maps) are the bread and butter tools of information architects. They are useful for conveying the general page structure and content requirements for individual pages.

Wireframes need to achieve a happy medium between being too 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 will sometimes end up evolving into the default requirements document for a Web site.

Sample Wireframes (pdf)
Sample Wireframes 2 (pdf)
Sample Wireframes 3 (pdf)
Read more about Web wireframes

7. Paper Prototype (aka 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. Using a paper prototype 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 paper prototypes can be created, the greater the benefit. Paper prototypes shouldn’t incorporate specific design elements such as color, style, fonts, detailed graphics, etc.

You may be hesitant to present something that might resemble a 6th 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 (aka Storyboard)

It’s debatable whether a storyboards are anything different than a set of wireframes, but they can tend to illustrate more of a process than a wireframe does. However in many cases IAs add usage and process notes to wireframes. I have also see storyboards (or something resembling them) referred to as Blueprint, Schematic, Grey Model, Interaction, Interaction Wireframe, IA Requirements Document, Design Document

Story boards 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. Story boards 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). HTML Wire frames are a good solution to solve multiple needs; deliverables for clients or management, and functional templates to start programming from.

Sample Style Guide (pdf)

Read more about Web style guides

Using Web Information Architecture Diagrams

In part 2 we take a look at the factors that influence using information architecture deliverables. Which provides more information on using Wireframes, Site Maps, Story boards, Use Cases, Paper Prototypes, User Profiles, and Site Maps and other web information architecture examples.

Originally published December 2004

Information Architecture (IA)

Information architecture is the foundation open which websites are built. You can think of it as the blue prints for a website. It defines a website’s structure, hierarchy, and navigation. Individuals who specialize in this science are referred to as information architects. Many of the original Web information architects had backgrounds in library sciences. More »