All too often, though, clients do not understand the need for an IA, and may even be threatened by their very inclusion in the web design process because their role in the design team is frequently misunderstood. It's easy to understand what the graphic artists do; they create all of the graphics. It's easy to understand what the HTML coders do; they put the web pages together. It's even easy to understand what the programmers do; they create all of the back-end software to make the site work. But the IA's role starts by creating a design document for the site, detailing what the site is about. This document sets out what is and is not to be included in the site, the audience the site is directed toward and the goals for the site, as well as the structure and navigation. This is based on extensive research and testing before even a single pixel is placed on the screen, and may thus seem to the client to be time-consuming, costly and unnecessary.
However, like a building's architect, an IA creates the blueprints for the site through the definition document, planning the structure and support around which all of the fixtures of the site (graphic, HTML and programming) will eventually be placed. A large site built without the benefit of a definition document will fail as surely as a skyscraper built without the benefit of a blueprint.
A good plan will save you time and aggravation in the long run. The design document is built in two parts: the first identifies different aspects of the site and the second is a map of its structure.
Collecting the Information
The web is about information and before any other member of the design team can begin their work, the IA has to collect, identify and distil information about the site.
The site's content: This one may seem obvious, but you would be surprised how many sites begin their life before those designing it really know what is going into it. Generally, content will initially be identified by the client, but don't let them skimp on how much information they give you. Also, don't be afraid to suggest content to the client. They may be unfamiliar with the capabilities of the Web and the features that can be included within a webbed environment. You will also need to break the content down and begin to consider how visitors to the site will be navigating through all of the information you will be presenting. Ask yourself: how can similar chunks of information be bundled together into different sections? What should those sections be called and how they should they be represented? This will play an important role later, when you map out the site and determine its structure.
The site's audience: Not too long ago I devoted an entire column to understanding visitors to your site (http://www. independent.co.uk/net/ 980810ne/story5.html), so I will be brief here. Suffice it to say that identifying who will be using the site is crucial to every other aspect, including its goals, its features and even how you structure the navigation.
The site's goals: Now that you know what is going in the site and who will be visiting your little corner of the Internet, it's time to solidify exactly what your goals are with this site. In reality, you will need to consider your goals while evaluating the content and audience. Naturally, the client may want to have some input on what the goals are for their site, so it's important to question them closely and listen carefully to what they say. Make no assumptions. You will also want to talk to perspective visitors to help determine what their goals will be when using the site. This can be as formal as a focus group or as informal as asking your mates, who may, after all, be potential visitors, what they think.
The site's features: Will this site need real audio? DHTML? Interactive navigation? CGI forms? Most of these features will need to be handled by a programmer or HTML coder, but you need to know exactly what is going to be in the site at a very early stage in order to plan the structure and address the goals. Ask questions such as: How will we accomplish this? Is this the best solution? What other technologies are available?
The site's layout: You can begin your preliminary drafts of how the site may look. Try not to get too definitive at this stage, especially if you are not going to be doing the graphic design yourself. Determine whether you will be using frames; how you want to place the navigation, titles, subtitles and other content; and how you will fit your site features into this structure. Sketch these pages out, either on paper or in an illustration program that allows you easily to move elements around in the design. Play with different concepts and don't be afraid to experiment. It is easier to try new things now than when you have the design in HTML.
In the real world
Follow this process, and the World Wide Web is your oyster? No. In fact, this is not nearly as linear a process as I have presented. First, you have the people paying the bills breathing down your neck to get results, either your manager or the customer (no longer the patient "client"), or both. This may mean you have to compress and combine several of these steps to meet deadlines. More than that, though, these steps are highly interdependent. For example, who you determine your audiences to be may alter what content you decide to include, or the site layout might limit the features you implement. Don't be afraid to go back and reconsider previous decisions based on new information. That's what the planning stage is for.
Next week we will look at mapping the site out and supervising its construction.
Jason Cranford Teague is the author of `DHTML: Visual Quick Start Guide', available from Peachpit Press (http://www. peachpit.com/peachpit/titles/ catalog/K5798.html).
E-mail comments or queries to Jason at indy_webdesign@ mindspring.comReuse content