Go with the flowchart: Web Design

Information architects need to know how a site's pieces fit together
Click to follow
The Independent Culture
IN THE creation of a Web site, the information architect's role is not to make the graphics, though they should know the difference between a GIF and a JPEG. It is not up to IAs to code the HTML, JavaScript or CGI, although they should know how all of these technologies work. It's not even their responsibility to plan the exact layout of the site, though some may take on that position as well.

No, IAs are the Renaissance people of Web design. They need to know how all of the different pieces work in order to bring them together and balance them in the site. This is becoming an increasingly important role as Web sites become more complex. A well-designed Web site will require someone who understands the disparate elements and how to put them together, and who can explain them in a design document. The design document serves as the blueprint of the site and is used as a guide by graphic artists, HTMLers and programmers.

The first step is to collect information about the site's content, audience, goals and features from the client, as well as beginning a preliminary layout. The IA must listen closely to the client's needs, desires and dislikes. After compiling this information, the IA is ready to map out the site and this can be done in several different ways.

Mapping the site

Site maps form an initial conceptual view of how the site will work, but the format the site map takes will depend on the individual project and the IA's strengths in communicating the structure of the site. Some IA's may be more comfortable with a traditional outline structure, while other, more visually trained IAs, may use storyboarding to sketch out the site. That said, for very large sites a combination of different techniques might be the best solution. The goal is to allow others (clients, artists, programmers, project managers etc) to be able to conceptualise the site structure and to provide them with a common blueprint to work against and refer to.

There are three ways to map out a site:

Outline: the outline will be the most familiar form to work in. Basically, an outline treats the Web site as a linear object, with each section being a top level in the outline and each Web page fitting under these or in sub-categories. An outline will probably end up mirroring the file structure of the site when it is created. One warning, though: outlines, because of their linear nature, can be highly misleading when applied to a hypertextual site. It is difficult to show links and relationships between Web pages, especially if a page in one section has a hypertextual relationship with pages in another section.

Flow chart: Flow charts add a visual representation of how different pages and functions within the site fit and work together in the linear outline. Generally, pages will be represented by rectangles and links by lines, but you can add other symbols into the flow chart to indicate decision paths, external links or CGI code. The advantage this gives over a simple outline is that you can show relationships between pages that more accurately reflect hypertextual content.

Storyboard: The storyboard works like a simple flow chart but adds a visual representation of how the page will appear on the screen and what content it will have. Flow charts represent a page by a single symbol - such as a rectangle - without any indication of what will be going on to it. Storyboards, on the other hand, indicate the layout of each page and are indispensable for portraying what the site will look like to people who might have a hard time imagining it without some form of visual representation. However, storyboards generally take up a lot of space and need to be laid out on poster board to accommodate all of the information they contain. This makes them impractical as a document to be distributed to the various members of a project team.

Regardless of which option you adopt while creating your site map, you should label each individual Web page within your site with its own unique ID and include this in the map.

That way, the people working off the map can refer to specific pages when communicating with each other (for example, page A_3_4), rather than to some vague reference (for example, the page with the order form).

You can also use these IDs as a file-naming convention for the site when you start writing code. One other thing I like to include in my site maps are the exact URLs of any links that will be going outside the site to another domain. When the time comes to create the site, it can save hours of confusion if everyone has a list of where links will be going.

Directing the site's construction

The final result of this work is the design document in which you will include all of the information you collected about the site, along with the site map.

Now that the design document is ready, the IA's job may or may not be done. Some IAs will pass it on to a project manager, who then supervises the construction of the site. However, project managers should really - to borrow a film metaphor - be the producer of the site, where the IA is the director. Producers make sure that all of the resources are available and that the project is running smoothly. The director, on the other hand, works closely with actors, camera operators, boom operators, editors and the rest of the crew to make sure that the film happens.

At this point, the IA should be working with artists, HTMLers and programmers to bring their vision (the vision that they have produced based on interaction and feedback with the client) into being.

E-mail comments or queries to Jason at indy_webdesign@ mindspring.com

Comments