Approaching a Web Site Project

---

In theory, Web development process models make sense, but do they work in practice? The answer is a resounding Yes . However, site development rarely works in a consistent manner because of the newness of the field, the significant time constraints, and the ever-changing nature of Web projects. Developers should always proceed with caution. With this in mind, regardless of the project, the first step is always the same: set the overall goal for the project.

Goals and Problems

Many Web site projects ultimately fail because they lack clear goals. In the first few years of Web design, many sites were built purely to show that an organization had a site. Somehow, without a site an organization was not considered progressive or a market leader; competitors with sites were considered a threat. Many times, a site provided little benefit because it wasn't really designed to provide anything other than a presence for the organization. As familiarity with the Web has grown, the reasons for having Web sites have become clearer. Today, site goals have become important and are usually clearly articulated up front. However, don't assume that logic rules the Web ”a great number of site development projects continue to be driven by pure fancy and are often more reactive to perceived threats than intended to solve real problems.

Determining a goal for a Web site isn't difficult; the problem is refining it. Be wary of vague goals such as "provide better customer service" or "make more money by opening up an online market." These may serve as a good sound bite or mission statement for a project, but details are required. Good goal statements might include something like the following:

• Build a customer support site that will improve customer satisfaction by providing 7/24 access to common questions and result in a 25 percent decrease in telephone support.

• Create an online automobile parts store that will sell at least $10,000/month of product directly to the consumer.

• Develop a Japanese food restaurant site that will inform potential customers of critical information such as hours, menu, atmosphere, and prices as well as encourage them to order by phone or visit the location.

Notice that two of the three goal statements have measurable goals. This is very important, as it provides a way to easily determine success or failure as well as assign a realistic budget to the project. The third goal statement does not provide an obviously measurable goal. This can be dangerous because it is difficult to convince others that the site is successful or to even place a value on the site. In the case of the restaurant site, a goal for the number of viewers of the site or a way to measure customer visits using a coupon would help. Consider a revised goal statement such as the following:

Develop a Japanese food restaurant site that will inform at least 300 potential customers per month of critical information such as hours, menu, atmosphere, and prices as well as encourage them to order by phone or visit the location.

The simple addition of a particular number of visitors makes the goal statement work. By stating a number of desired visitors , the restaurant owner could compare the cost of placing advertisements in print or on the radio versus the cost of running the site to provide the same effective inquiry rate.

Brainstorming

In general, coming up with a goal statement is fairly straightforward. The challenge is to keep the statement concise and realistic. In many Web projects, team members often want to include everything in the site. Remember, the site can't be everything to everyone; you must have a specific audience and set of tasks in mind. To more fully explore site goals and features, team members often need a brainstorming session. The purpose of a brainstorming session is simply to bring out as many possible ideas about the site as possible. A white board and post-it notes are useful during a brainstorming session to quickly write down or modify any possible ideas for the site.

Oftentimes, brainstorming sessions get off track because participants jump ahead or bring too much philosophy about site design to the table. In such cases, it is best to focus the group by talking about site issues they should all agree on. Attempt to find a common design philosophy by having people discuss what they don't want to see in the site. Getting meeting participants to agree they don't want the site to be slow, difficult to use, and so on is usually easy. Once you obtain a common goal in the group, even if it is just that they all believe that the site shouldn't be slow, future exploration and statements of what the site should be will go smoother.

Note  

When conducting a project to overhaul a site, be careful not to run brainstorm meetings by ridiculing the existing site, unless no participant in the project has any ownership stake in the site. A surefire way to derail a site overhaul project is to get the original designers on the defensive because of criticism of their work. Remember, people build sites, so building a positive team is very important.

Narrowing the Goal

During the brainstorming session, all ideas should be allowed. The point of the session is to develop what might be called the wish list . A wish list is a document that describes all possible ideas for inclusion in a site regardless of price, feasibility, or applicability. It is important not to stifle any ideas during brainstorming, lest this eliminate the creative aspect of site development. However, eventually the wish list will have to be narrowed down to what is reasonable and appropriate for the site. This can be a significant challenge with a site that may have many possible goals. Consider a corporate site that contains product information, investor information, press releases, job postings, and technical support sections. Each person with ownership stakes in a particular section will think his or her section is most important and will want a big link to his or her section on the home page. Getting compromise with so many stakeholders can be challenging!

Audience

Throughout site development and particularly when goals are being discussed, you should always consider the site's audience. What a brainstorming group wants and what an end user wants don't always match. We need to make sure the site's goals are in line with its users' needs. However, to do this we need to accurately describe the site's audience and their reason for visiting the site. Don't look for a generic "Joe Enduser" with a modem who happened upon your site by chance. It is unlikely such a user could be identified for most sites, and most users will probably have a particular goal in mind. Instead, think about what kind of people your end users are. Consider asking some basic questions about the site's users, such as:

• Where are they located?

• How old are they?

• What is their gender?

• What language do they speak?

• How technically and Web proficient are they?

• Are the users disabled (sight, movement, and so on) in any manner?

• What kind of connection would they have to the Internet?

• What kind of computer would they use?

• What kind of browser would they probably use?

Next, consider what the users are doing at the site:

• How did they get to the site?

• What do the users want to accomplish at the site?

• When will they visit the site?

• How long will they stay during a particular visit?

• From what page(s) will they leave the site?

• When will they return to the site, if ever?

• How often do they return?

While you might be able to describe the user from these questions, you should quickly determine that your site would probably not have one single type of user with a single goal. For most sites, there are many types of users, each with different characteristics and goals.

Server Logs

If the site has been running for some time, you have a gold mine of information about your audience ”your Web site access logs. Far too often designers don't really look at logs for anything other than basic trends, such as number of page views. However, from looking at log files you should be able to determine useful information, such as the types of browsers commonly accessing the site, the general pattern of when and how visitors use the site such as entry and exit points, the current delivery and server requirements, and so on. Of course, stats logs won't tell you much about user satisfaction and specific details of site usage. For that, you will actually have to get to know users and even talk to them!

User Interviews and Profiling

The best way to understand users is to actually talk to them. If at all possible, you should interview users directly to resolve any questions you may have about their wants and characteristics. A survey may be appropriate, but live interviews provide the possibility to explore ideas beyond predetermined questions. Unfortunately, interviewing or even surveying users can be very time-consuming and will not account for every single type of user characteristic or desire . From user interviews and surveys or even from just thinking about generic users, you should attempt to create stereotypical but detailed profiles of common users.

Consider developing at least three user profiles. For most sites, the three stereotypical users should correspond roughly to an inexperienced user, a user who has Web experience but doesn't visit your site often, and a power user who understands the Web and may visit the site frequently. Most sites will have these classes of users, with the intermediate, infrequent visitor most often being the largest group. Make sure to assign percentages to each of the generic groups so that you give each the appropriate weight. Now name each person. You may want to name each after a particular real user you interviewed, or use generic names like Bob Beginner, Irene Intermediate, and Paul Poweruser. Now work up very specific profiles for each stereotypical user using the questions from the previous section. Try to make sure that the answers correspond roughly to the average answers for each group. So, if there were a few intermediate users interviewed who had fast connections, but most have slow connections, assume the more common case.

Once your profile for each site visitor is complete, you should begin to create visit scenarios. What exactly would Bob Beginner do when he visits your site? What are the tasks he wishes to perform? What is his goal? Scenario planning should help you focus on what each user will actually want to do. From this exercise, you may find that your goal statements are not in line with what the users are probably interested in doing. If so, return to the initial step of the process and modify the goal statement based on your new information.

Site Requirements

Based on the goals of the site and what the audience is like, the site's requirements should begin to present themselves . These requirements should be roughly broken up along visual, technical, content, and delivery requirements. To determine requirements, you might ask questions such as the following:

• What kind of content will be required to meet our goals?

• What kind of look should the site have?

• What types of programs will have to be built?

• How many servers will be required to service the site's visitors adequately?

• What kind of restrictions will users place on the site with respect to bandwidth, screen size , the browser, and so on?

As you determine your requirements, it is likely that site costs will become more apparent and potential implementation problems will surface. The requirements will suggest how many developers are required and show what content is lacking. If the requirements seem excessive in view of the potential gain, it is time to revisit the goal stage or question if the audience was accurately defined. The first three steps of the typical Web project process may be repeated numerous times until a site plan or specification is finally agreed upon.

---