Lisa Goldberg

The information architect's job is to help users find the content that they need. To quote Peter Morville in Web Review, an information architect creates "consistent and functional systems for navigation, graphics, page layout and title languages so that the user knows where to go, what to do, and [is encouraged] to return." As part of this task, the information architect communicates with developers, designers and the client (or management), connecting their needs with those of the users.

In addition to the core task of creating consistent and functional systems, information architects sometimes design user interfaces, write content, document functional and graphical requirements, and conduct usability tests. These task assignments vary, depending on the skills of the architect and the structure of their organization.

This column explains the process of information architecture and how that methodology is integrated into the overall Web design process. The process can be summarized in six steps:

1. Document the Goals and Requirements
2. Map Task Workflows
3. Organize the Content
4. Define Content Entities
5. Test for Usability
6. Revise and Repeat

Step One: Document the Goals and Requirements

Before you design anything, you need to know what the site should accomplish. Should it sell products? Reduce calls to the customer service department? Encourage networking among members? Ideally these goals are quantifiable so that you can measure your project's success. To be thorough, gather feedback from all relevant parties in the organization.

Internal resources should also be considered. Who will maintain the site? Will new content be incorporated, and if so, who will write it? Answers to these questions will affect the structure of the site content. For example, if the site will only be updated twice a year, then a stand-alone news area is not a good idea.

You also need to determine who will be using the site. What are visitors' demographics, such as profession and age range? How Web-savvy are they and what browsers do they use? What tasks would you like people to accomplish when they visit?

In addition to setting goals, you should also gather data. If you are redesigning a site, review Web traffic statistics and archived user feedback. If time permits, you can post a temporary survey on your site to gather input.

Study similar sites to see what they do well and what you'd like to avoid. If your site services a limited audience, such as association members, you might be able to solicit feedback from them directly. Focus groups may be merited for large projects.

After you have gathered the relevant data, prioritize the user groups, user tasks, and site goals. This is a critical task. The priority list will guide your decisions later in the project.

Document these requirements. Many information architects gather all project requirements, including functional requirements. Some goals may be postponed until a later phase, but they should all be recorded in writing.

After the requirements have been formally approved, you can organize the site.

Step Two: Map Task Workflows

Note: This task is relevant if your site contains functionality, such as online donations or registrations. If not, you can move on to the next step.

By now you should understand who your users are and what you'd like them to accomplish on the site. Using your priority list as a guide, map the key tasks.

Create a workflow for each task in your priority list. You can draw a flowchart or write an outline. If you are redesigning the functionality for an existing site, you may find it helpful to map the current task workflows and then redesign them.

Here is a sample task workflow:

I. Buy a flashlight

a. Find the flashlight

i. Search for the flashlight

1. Type "flashlight" in the search box

2. Read the results

ii. Browse the store

b. View the flashlight

c. Purchase the flashlight

Provide the user with multiple paths to the same destination. For example, the user can either browse or search for the flashlight. Also consider potential dead ends. What happens if the user makes a mistake when entering their shipping information? Will you give them an opportunity to correct the error?

Although you are only designing the process at this phase, not the interface, you may wish to perform this task in conjunction with an interface designer or usability specialist, depending on how the project team is constructed.

You want the process to be as intuitive as possible, but technical constraints will interfere at times. Before you finalize your workflows, make sure the developers can build them.

Step Three: Organize the Content

Now you're ready to create the site map, or site outline. This document organizes the site content into categories and assigns labels, or names, to each content area. Any functionality that you mapped in Step Two will be integrated into this system.

The process is similar to outlining a written document. Unlike paper documents, however, you should provide multiple paths to the same information, since not all people think alike. For example, a little black dress could reside under "dresses > evening wear" and "evening wear > dresses."

You can use any tool to get started. Personally, I prefer Microsoft Word's outline tool for the initial drafts because it's so easy to modify. If you'd rather map the site graphically, Visio works well. You can also use Inspiration, Illustrator, or pencil and paper.

There are a few rules to keep in mind:

• Design for the end user
• Design to meet the site goals
• Design for scalability

I tend to disregard other purported rules, such as "use seven plus or minus two links" or "click no more than three times." Many of these rules have been disproved over time. In addition, each site design poses unique challenges. For example, retirees learning about arthritis will require a different navigation style than programmers participating in an online discussion group.

If you are designing a site for a large organization, I can almost guarantee that everyone will want their content on the home page—which means, in their minds, that they have a place in the top-level navigation. This is a bad idea for two reasons:

1. The navigation won't scale effectively. Eventually, you'll need to include every department or product in the top-level links.
2. An organization chart is not intuitive to most site visitors, who don't understand how the departments are structured. They are visiting the site to accomplish a task and the navigation should reflect that mindset.

Fortunately, you can offer alternatives for visible content placement. You can provide flexible content areas on the home page to highlight newsworthy items. You also can crosslink between pages deeper in the site.

Think of the top-level navigation as the blueprint for a house. You can build additions later, but those additions are expensive, and they may not be integrated as effectively into the design. Well-planned navigation should meet the site's needs a year or even three years from today.

If the schedule and budget permit, you can solicit help from users with a card-sorting exercise. In such an exercise, each topic is written on a separate card. Members of the targeted user groups arrange the cards into categories that make the most sense to them.

Step Four: Define Content Entities

After you have determined how the content should be organized, you need to define the content entities. For example, your home page might require navigation and a logo, search box, news area and mission statement.

By representing these items in a wireframe diagram, you can see how the content entities relate to one another. This example shows a very simple wireframe (normally they contain more detail).

Wireframes can be created using many tools: Visio, Illustrator, HTML, even Microsoft Word. They are not graphic designs; they simply represent the content relationships. Imagine the items as pieces of a puzzle that can be shifted around.

Dan Brown, a local information architect, has devised a page description diagram that defines content entities with text instead of graphics. This option is useful if you want to make sure that people don't interpret the diagrams as graphic designs.

Developers use wireframes to define and group database fields. Wireframes are also quite effective in usability testing.

Step Five: Test for Usability

I always advocate usability testing at this stage. It is much easier to make changes now, before the graphic design process has begun. The later you wait to test for usability, the more costly the changes will be.

There are many ways to test for usability. What I am outlining here is the quick and dirty technique. It's informal, it doesn't require knowledge of statistics and it may not even cost you anything.

Find some sample users. Ideally you should test people from each of your defined target audiences. If you can't, ask coworkers, friends, or neighbors to sit down with you and offer feedback. In general, any feedback is better than none. Just make sure that you're soliciting input from people who are not familiar with your project. Testing 5-8 people will give you enough information to identify some trends.

One caveat: if you are working on a site that targets a specialized audience—such as neurosurgeons or high school students—then you should work with that audience if you want useful feedback.

You can test the wireframes in paper or HTML format. Paper wireframes can be less intimidating and are easy to modify. They are useful for identifying problems with labeling and navigation structure. HTML wireframes are most useful when testing a process, since users can click through the screens. (Processes can also be tested in paper format, however.)

I generally give people a think-aloud usability test ("what do you think you'd find in here?") and ask them where they'd go to accomplish certain tasks. I also record the elements that people don't notice. For a great introduction to usability testing, read Steve Krug's Don't Make Me Think.

Step Six: Revise and Repeat

After you have run your usability test, you will probably want to make changes. Test again, if you can.

You may also wish to revise the information architecture once you see the site content, which may not have been available when you began the design process.

After the information architecture has been finalized, the graphic designer and programmers take over. Your core tasks are complete, although you should still remain involved to ensure that the site's vision is realized.

Learn More

This article provides a general overview of the process. To learn more specific problem-solving techniques, try the following resources:

Lisa Goldberg has managed user experience projects and served as resident information architect at Lucidea and WestLake Consulting Group since 1998. She has more than a decade of experience in project management, writing, usability and graphic design.