Planning the Website
Now that you have signed a contract with a client, you are ready to plan the website. In this section, you learn what you need to do before production can begin. First, you need to get content and media assets from the client and gather more specific information from the client and other members of the staff. Second, you need to determine how the website will be structured by creating the site's information architecture and flow chart. Lastly, you come up with a content update plan, create a requirements document, and develop a time line to keep on schedule.
Content and Media Assets
After you agree on contractual items with the client, make a list of the resources the client needs to provide to assist you in your work.
The following are examples of material you might need:
- Company info
- Tag line(s)
- Marketing collateral (such as brochures)
- Stock photography
- Location, addresses, phone numbers, e-mail addresses
- Glossary
- Design elements
- Copy text
- Other resources (such as videos, books, articles, CDs)
- Competitor URLs, related companies' URLs
During the pre-production phase, collect as much material as you can. An abundant amount of material ensures that you will have plenty to choose from. The more information you can get from the client at this point, the more resources you will have at your disposal when designing the site.
Content
If available, gather copy, logos, photographs, illustrations, audio files, and so on, from the client or from sources such as photo or audio CDs, libraries, or the web. Examine the information that you have collected. Decide what content is critical and where it should be placed on the website. Organize the content into cohesive units by subject. Envision how the content will be presented. Determine what portion of the content will be exclusively text and how many images are needed. Will there be additional graphics, tables, frames, or interactive components?
Generally, the client will not be able to provide the formalized content for the website until the final site map is decided upon. You might use these items to help the client organize and complete a site map, but hold off on formatting any content you might find in brochures and other materials until you know for sure that it will be included on the site.
Size
Assess the quantity of information and determine how it will best be distributed throughout the site. The amount of information is crucial to deciding the number of pages, the look and feel, and the navigational options. Streamline the information so that it can be presented efficiently.
Multimedia
If audio or animated multimedia elements are to be included in the site, the designer needs to decide where they will be placed and who will do the multimedia work. Some elements are available on CD, such as audio or video clips. Others will need to be created in software applications. These elements can be used for instruction or entertainment depending on the site's intention. Multimedia elements greatly enhance the website's ability to deliver information and entertainment, but it might add expense for the client and increase download times for the user.
Background Information
While meeting with the client, ask for additional information that might not relate directly to the project, such as marketing collaterals (e.g., brochures, fliers, and television or radio ads). Ask for a tour of the company so that you can be made aware of all of its departments. Ask to meet additional personnel associated with different departments.
Try to investigate further the accessibility requirements of the audience to make sure that they are not overlooked. (The issue of web accessibility is thoroughly discussed in Chapter 7, "Accessibility and Internationalization.") It is also important to determine how traffic analysis is accomplished. This is mostly a service connected to the way the site is hosted. In Chapter 11, you learn more about this. Any information that you collect will aid you in developing a comprehensive understanding of the enterprise.
Static Versus Dynamic Content
Determine if the content will be delivered statically or dynamically. When a web page is requested, the server where the page is stored returns the HTML document to the user's computer and the browser displays it. On a static web page, this is all that happens. The user can interact with the document through clicking available links or a small program (an applet) can be activated, but the document has no capacity to return information that is not preformatted.
On a dynamic web page, the user can make requests (often through a form) for data contained in a database on the server that will be assembled on the fly according to what is requested. For example, the user might want to find out information about the availability of baseball tickets for a particular date. The request is relayed to the server using an intermediary such as an Active Server Page (ASP) script embedded in the page's HTML. The intermediary tells the server what information to return.
If the client wants a dynamic web page, consider hiring someone with expertise in this area. This book does not focus on dynamic websites because it requires extensive knowledge of databases and scripting. However, the basics of dynamic websites are discussed in Chapter 9.
Stakeholder Interviews
Beyond the initial meeting with your client, you might find it necessary to gather more detailed information about the organization or business. Thoroughly investigate the nature of the enterprise that you are representing. If there are multiple departments or areas of specialization, make it a point to interview the individuals who can provide the most detailed perspective. Gather as much information as you can about each component of the business. Conduct as many interviews as necessary to help you understand how they can be best represented on the site.
A stakeholder is someone who has an interest in the website; that is, they will benefit or be represented by it. Stakeholder interviews are conducted to further develop a deeper understanding of the company. Your questions will focus on the more detailed particulars of the business, which the main client contact might not know, such as highly technical aspectsthat only a specialist might be able to articulate.
You might want to ask stakeholders the following list of questions:
What aspect of the business does your department handle?
How is it related to the company as a whole?
What are the technical issues in the scheme of production?
How many individuals make up the department?
What do you want your website to say about your department?
How frequently will your department's information change?
What kind of feedback do you need from the site's audience?
To what other websites will your department's information be linked?
What other websites do you like?
What assets are currently available (e.g., photographs, copy, logos, and so on)?
What are examples of information that you typically share with coworkers or the public?
Information Architecture
Now that you have considered what you want to put on the website, you need to create the information architecture. It organizes content on a website and determines how a user finds and accesses that information. Information architecture is intended to organize and simplify a website, as shown in Figure 4-3.
Figure 4-3 Information Architecture
Even if the site you design boasts award-winning visuals, users will go elsewhere if they cannot find what they are looking for quickly and intuitively. Begin the information design process by categorizing and prioritizing the information that you will include in the site. What are the main categories? Weigh the importance of the information to be presented. Without addressing any visual styles, draw outlines and diagrams that show how information is grouped together. For example, product and company information could be grouped together, but perhaps should be kept separate from functions such as search and feedback. Furthermore, think about which groups of information should be given the most prominence on the screen and draw those items larger in your diagrams.
Ideally, a website is structured hierarchically. The main categories are displayed first. From there, subtopics lead the user to an ever-narrowing subject range and eventually to the information they are seeking. This process creates a logical map so that users can easily navigate around the site. It also simplifies the organizational process for the web designers.
The following questions can help you set up a hierarchy for your site on paper:
What are the main categories of information that will be included on the website?
Are these main categories related in a way so that their order is important?
What should users be able to access from any page (home page, shopping cart, search box, contact us, help)?
How do you want the user to find each web page? Will they be able to have a menu of the main categories and perhaps a menu of the related subcategory that they are already in available to them on all pages?
How should you group similar information?
Categorizing and Prioritizing Content
Before you begin the process of categorizing and prioritizing content, be sure that you have a complete list of all the site content. There is no greater development challenge than to accommodate late-coming information. After you have a list of all the content, create a simple text outline. Look for ways to group all information into about five to seven categories. This is called chunking. Designing an interface to accommodate more than seven major categories is difficult, and you can potentially overload your users with information. After generating a simple text outline, begin to prioritize. Decide which information should be given most prominence on the screen and which information should always be accessible to the user.
Common Information Architecture Mistakes
The process of compiling information for a website involves digging as deeply as you can through client interviews, web research, competition surveys, and data gathering, so that you have choices as to what material is the most current and relevant for the site. This is somewhat of a paradox because an effective website needs to present information quickly and efficiently.
In essence, the process of constructing a website involves reducing a large amount of data into a succinct, cohesive, and streamlined body that best represents the client's needs. This is a serious decision-making process that affects every aspect of the look, feel, and functionality of the site.
For example, in the process of gathering information about the business, the client enthusiastically gives you an animation that their child created in a class at school. Yet the site's intention is to provide an online catalog so that customers can quickly place orders. Unless that animation is relevant to the intention of the site, you should not use it. Politely explain to the client that it is inappropriate content and would interfere with the message that they are trying to convey to customers. Suggest that the child sets up a personal website to showcase the artwork.
Avoid clutter. Websites with irrelevant or redundant information take longer to download, are difficult to understand, and are inefficient to navigate. Use only relevant information.
A common mistake found on many websites is to present all the information with equal emphasis. The viewer is forced to sift through all the information to establish its relevance. Avoid this mistake by emphasizing navigation buttons and labels that clearly lead the visitor to the information they seek.
Another common mistake is to present too much information at one time so that the viewer is barraged with a visual and intellectual tangle. Consider segregating information by page or by area, and lead the visitor through the information in smaller doses.
The following tips can help you avoid common architecture mistakes:
Be sure to consult the client on how to get straight to the point.
Always keep the web as a medium in mind, paying particular attention to the fact that any page can be the first one that users see.
Spend time organizing the site and then stick to your plans.
Site Flow Chart
Just as you would not build a house without a blueprint, you should not build a website without a flow chart. Flow charts are not meant to imply visual directions; they are simply a means of communicating the flow of content through the site. The creation of a flow chart is an excellent process to share with clients so that they too can begin to see and understand the website. An example of a site flow chart is shown in Figure 4-4.
Figure 4-4 Site Flow Chart
The information hierarchy is illustrated by a flow chart. The information is divided into levels. The first level is for general categories that act as signposts to the next level. The second level is where the topics are more clearly defined and elaborated upon. There are links to the third level where details, specifics, and other related material could be accessed. Additional levels could follow, although it is advisable to avoid unnecessary nesting of pages.
You can generate your flow chart in almost any graphics application, particularly if the program is vector-based. Some HTML editors, such as Adobe GoLive, allow for this. After you create your own language of symbols, the program automatically draws boxes of all shapes, generates text in the boxes, and understands levels of hierarchy and relationships.
Content Update Plan
It is a good idea to consider a content update plan from the beginning. The World Wide Web, being one of the most dynamic publishing mediums, readily lends itself to changes. A content update plan should be developed if the project includes not only setting up a website, but also regular site updates. It should cover which pages or page areas need to be updated, when this should be done, and where the updated content comes from. The plan should outline a delivery schedule for updated content to the web designer to ensure a smooth updating process.
A website for a movie theater, for example, would post its scheduled information weekly. The information should be delivered to the web designer well in advance of the posting deadline to ensure that it can be revised in sufficient time.
Requirements Document
After you develop the information architecture, set up a site flow chart, and assemble a content update plan, the next step is consolidating this information in a requirements document that you can provide to the client for sign-off.
The requirements document is created after the proposal is accepted. This document serves as a laundry list for you to make sure that you have received all the necessary assets and background information and that you have understood the client's needs and goals for developing this website. This list must be provided to the customer for sign-off. This guarantees that both sides are clear about website details that were not covered in the proposal or identifies any subsequent misunderstandings.
A requirements document is a typical project milestone that requires the client's sign-off before actual production can begin.
The requirements document needs to address the following key questions:
- What does the client need to provide to the designer?
- What does the designer need to do the job?
- What will the designer do exactly?
- What are all the parts and features of the website?
Time Line Development
After having written the requirements document, you need to develop the time line to share with the client.
Determine when the client expects to have the website online. In many cases, the client will tell you that time is of the essence and that they needed the site yesterday. Be prepared to ask for a realistic amount of time to accomplish the task. From this information, develop a time line and a schedule. The completion date is either approximated, by using the project scope as a basis, or determined by a specific deadline date the customer sets. Of course, you need to determine if you will be able to deliver the product by the deadline date.
Almost all clients are in a rush. There are times when they will call up to ask for a project to be executed in a week's time. It is a good plan to have a minimum amount of time in mind for a given deliverable. If you explain, for example, that the minimum amount of time to produce a home page mock-up is a week and a half, be prepared to let them know that it is just not possible to do it sooner, or that you would need to charge a rush fee. Explain that you are going to have to shuffle some current projects around to accommodate them under such a restraining time line. You could also explain that you will have to work overtime, and that a common rush job rate is a markup of 50 percent on your usual hourly charge.
It is important for you to adhere as closely as possible to the scheduled deadlines. Presenting the material on time builds the client's confidence in you as a designer. Be sure to allocate enough time so that you do not become crazed in trying to meet the deadlines. Remember that it is better to ask for more time at the beginning of the job then fail to deliver the work because of impossible circumstances. Your work might suffer in quality if you are trying to cram it into an unreasonable amount of time. Be sure to take into account the fact that you might be serving more than one client at a time.
Develop a time line based on specific milestones in the process. These include the pre-production, the production, and the post-production phases. Also, the time line should outline the due dates for contributions by both you and your client. Including your client in the time line emphasizes that your client is also part of the website development process. It is crucial to point out that a delay on the client's part affects the entire time line. This is a touchy subject. Be realistic. Remember that this is a team effort. If the client is not available for necessary sign-offs or content delivery, it affects your time line and delivery dates. Be sure to inform your client from the beginning that you are dependent on his participation throughout the process.
Table 4-1 is an example of how you can set up a time line for a project.
Table 4-1 Time Line for an Example Project
Task |
Completion Date |
Start project |
November 1 |
Receive content and media assets |
November 3 |
Create site flow chart |
November 6 |
Create content update plan |
November 9 |
Requirements document completed |
November 10 |
Convert media assets |
November 18 |
Create prototypes |
November 26 |
Meeting with client to discuss prototypes |
November 28 |
Create navigation elements |
December 5 |
Media completed |
December 15 |
Content writing completed |
December 23 |
Assemble website |
December 27 |
Test website |
December 30 |
Modify website |
January 3 |
Test website |
January 6 |
Task |
Completion Date |
Modify website |
January 12 |
Test for accessibility/validate HTML |
January 15 |
Present website to client for sign-off |
January 18 |
Make final changes |
January 21 |
Upload site |
January 25 |
Test live site |
January 25 |