In the long run men hit only what they aim at.
— Henry David Thoreau
THE FIRST STEP in designing any Web site is to define your goals. Without a clearly stated mission and objectives the project will drift, bog down, or continue past an appropriate endpoint. Careful planning and a clear purpose are the keys to success in building Web sites, particularly when you are working as part of a development team.
Planning a Web site is a two-part process: first you gather your development partners, analyze your needs and goals, and work through the development process outlined here to refine your plans. The second part is creating a site specification document that details what you intend to do and why, what technology and content you'll need, how long the process will take, what you will spend to do it, and how you will assess the results of your efforts. The site specification document is crucial to creating a successful site, as it is both the blueprint for your process and the touchstone you'll use to keep the project focused on your agreed goals and deliverables.
Web sites are developed by groups of people to meet the needs of other groups of people. Unfortunately, Web projects are often approached as a "technology problem," and projects are colored from the beginning by enthusiasms for particular Web techniques or browser plug-ins (Flash, digital media, XML, databases, etc.), not by real human or business needs. People are the key to successful Web projects. To create a substantial site you'll need content experts, writers, information architects, graphic designers, technical experts, and a producer or committee chair responsible for seeing the project to completion. If your site is successful it will have to be genuinely useful to your target audience, meeting their needs and expectations without being too hard to use.
Although the people who will actually use your site will determine whether the project is a success, ironically, those very users are the people least likely to be present and involved when your site is designed and built. Remember that the site development team should always function as an active, committed advocate for the users and their needs. Experienced committee warriors may be skeptical here: these are fine sentiments, but can you really do this in the face of management pressures, budget limitations, and divergent stakeholder interests? Yes, you can — because you have no choice if you really want your Web project to succeed. If you listen only to management directives, keep the process sealed tightly within your development team, and dictate to imagined users what the team imagines is best for them, be prepared for failure. Involve real users, listen and respond to what they say, test your designs with them, and keep the site easy to use, and the project will be a success.
A short statement identifying two or three goals should be the foundation of your Web site design. The statement should include specific strategies around which the Web site will be designed, how long the site design, construction, and evaluation periods will be, and specific quantitative and qualitative measures of how the success of the site will be evaluated. Building a Web site is an ongoing process, not a one-time project with static content. Long-term editorial management and technical maintenance must be covered in your budget and production plans for the site. Without this perspective your electronic publication will suffer the same fate as many corporate communications initiatives — an enthusiastic start without lasting accomplishments.
The next step is to identify the potential readers of your Web site so that you can structure the site design to meet their needs and expectations. The knowledge, background, interests, and needs of users will vary from tentative novices who need a carefully structured introduction to expert "power users" who may chafe at anything that seems to patronize them or delay their access to information. A well-designed system should be able to accommodate a range of users' skills and interests. For example, if the goal of your Web site is to deliver internal corporate information, human resources documents, or other information formerly published in paper manuals, your audience will range from those who will visit the site many times every day to those who refer only occasionally to the site.
Each member of a site development team will bring different goals, preferences, and skills to the project. Once the team has reached agreement on the mission and goals of the project, consensus on the overall design approach for the Web site needs to be established. The goal at this stage is to identify potential successful models in other Web sites and to begin to see the design problem from the site user's point of view.
Unfortunately, production teams rarely include members of the target audience for the Web site. And it is often difficult for team members who are not already experienced site designers to articulate their specific preferences, except in reference to existing sites. Group critiques are a great way to explore what makes a Web site successful, because everyone on the team sees each site from a user's point of view. Have each team member bring a list of a few favorite sites to the critique, and ask them to introduce their sites and comment on the successful elements of each design. In this way you will learn one another's design sensibilities and begin to build consensus on the experience that your audience will have when they visit the finished site.
Once you have an idea of your Web site's mission and general structure, you can begin to assess the content you will need to realize your plans. Building an inventory or database of existing and needed content will force you to take a hard look at your existing content resources and to make a detailed outline of your needs. Once you know where you are short on content you can concentrate on those deficits and avoid wasting time on areas with existing resources that are ready to use. A clear grasp of your needs will also help you develop a realistic schedule and budget for the project. Content development is the hardest, most time-consuming part of any Web site development project. Starting early with a firm plan in hand will help ensure that you won't be caught later with a well-structured but empty Web site.
The site specification is the planning team's concise statement of core goals, values, and intent, to provide the ultimate policy direction for everything that comes next. Designing a substantial Web site is a costly and time-consuming process. When you're up to your neck in the daily challenges of building the site, it can be surprisingly easy to forget why you are doing what you are, to lose sight of your original priorities, and to not know on any given day whether the detailed decisions you are making actually support those overall goals and objectives. A well-written site specification is a powerful daily tool for judging the effectiveness of a development effort. It provides the team with a compass to keep the development process focused on the ultimate purposes of the site. As such, it quickly becomes a daily reference point to settle disputes, to judge the potential utility of new ideas as they arise, to measure progress, and to keep the development team focused on the ultimate goals.
At minimum, a good site specification should define the content scope, budget, schedule, and technical aspects of the Web site. The best site specifications are very short and to the point, and are often just outlines or bullet lists of the major design or technical features planned. The finished site specification should contain the goals statement from the planning phase, as well as the structural details of the site.
These are big questions, and the broad conceptual issues are too often dismissed as committees push toward starting the "real work" of designing and building a Web site. However, if you cannot confidently answer all of these questions, then no amount of design or production effort can guarantee a useful result.
The site specification defines the scope of your project — that is, what and how much you need to do, the budget, and the development schedule. "Scope creep" is the most prevalent cause of Web project failures. In badly planned projects, scope creep is the gradual but inexorable process by which previously unplanned "features" are added, content and features are padded to mollify each stakeholder group, major changes in content or site structure during site construction are made, and more content or interactive functionality than you originally agreed to create is stuffed in. No single overcommitment is fatal, but the slow, steady accumulation of additions and changes is often enough to blow budgets, ruin schedules, and bury what might have been an elegant original plan under megabytes of muddle and confusion.
Don't leap into building a Web site before you understand what you want to accomplish and before you have developed a solid and realistic site specification for creating your Web site. The more carefully you plan, the better off you will be when you begin to build your site.
One excellent way to keep a tight rein on the overall scope of the site content is to specify a maximum page count in the site specification. Although a page count is hardly infallible as a guide (after all, Web pages can be arbitrarily long), it serves as a constant reminder to everyone involved of the project's intended scope. If the page count goes up, make it a rule to revisit the budget implications automatically — the cold realities of budgets and schedules will often cool the enthusiasm to stuff in "just one more page." A good way to keep a lid on scope creep is to treat the page count as a "zero sum game." If someone wants to add pages, it's up to them to nominate other pages to remove or to obtain a corresponding increase in the budget and schedule to account for the increased work involved.
Changes and refinements can be a good thing, as long as everyone is realistic about the impact of potential changes on the budget and schedule of a project. Any substantial change to the planned content, design, or technical aspects of a site must be tightly coupled with a revision of the budget and schedule of the project. People are often reluctant to discuss budgets or deadlines frankly and will often agree to substantial changes or additions to a development plan rather than face an awkward conversation with a client or fellow team member. But this acquiescence merely postpones the inevitable damage of not dealing with scope changes rationally.
The firm integration of schedule, budget, and scope is the only way to keep a Web project from becoming unhinged from the real constraints of time, money, and the ultimate quality of the result. A little bravery and honesty up front can save you much grief later. Make the plan carefully, and then stick to it.
Every significant Web project poses unique challenges, but the overall process of developing a complex Web site generally follows six major stages:
Developing a large Web site is a process that may have far-reaching budgetary, personnel, and public relations consequences for an organization, both during the development of the site and long after its successful deployment. Too many Web sites begin life as ad hoc efforts, created by small interest groups working in isolation from their peers elsewhere in the organization and without fully considering the site's goals within the context of the organization's overall mission. The result of poorly planned, hasty development efforts often is an "orphan site," starved of resources and attention.
As you consider the development process outlined below, note that the construction of the pages that make up the Web site is one of the last things that takes place in a well-designed project. Consider each step in the process, and its impact on your developing site specification plan. Think before you act, and make sure you have the organizational backing, budget, and personnel resources you'll need to make the project a success.
This initial stage is where you define your goals and objectives for the Web site and begin to collect and analyze the information you'll need to justify the budget and resources required. This is also the time to define the scope of the site content, the interactive functionality and technology support required, and the depth and breadth of information resources that you will need to fill out the site and meet your reader's expectations. If you are contracting out the production of the Web site, you will also need to interview and select a site design firm. Ideally, your site designers should be involved as soon as possible in the planning discussions.
Not every site will require consideration of every item below. Developers within corporations or other large enterprises can often count on substantial in-house technology support when creating new Web sites. If you are on your own as an individual or small business, you may need to contract with various technology and design vendors to assemble everything you'll need to create a substantial content site or small e-commerce site.
A site that is "everyone's responsibility" can quickly become an orphan. A maintenance plan should specify who is responsible for the content of each page in the site. To maintain consistent editorial, graphic design, and management policies you'll also need one person to act as the editor of the overall Web site. The site editor's duties will vary according to how you choose to maintain your site. Some editors do all the work of maintaining site content, relieving their coworkers of the need to deal directly with Web page editing. Other editors coordinate and edit the work of many contributors who work directly on the site pages. If multiple people contribute to site maintenance, the site editor may choose to edit pages after they are created and posted to avoid becoming a bottleneck in the communications process. However, high-profile public pages or pages that contain very important content should be vetted by the editor before public posting.
In addition to ensuring editorial quality, a site editor must also ensure that the content of the site reflects the policies of the enterprise, is consistent with local appropriate use policies, and does not contain material that violates copyright laws. Many people who post pictures, cartoons, music files, or written material copied from other sites on their own sites do not understand copyrights and the legal risks in using copyrighted materials inappropriately. A site editor is often an institution's first line of defense against an expensive lawsuit over the misuse of protected material.
At this stage you need to detail the content and organization of the Web site. The team should inventory all existing content, describe what new content is required, and define the organizational structure of the site. Once a content architecture has been sketched out, you should build small prototypes of parts of the site to test what it feels like to move around within the design. Site prototypes are useful for two reasons. First, they are the best way to test site navigation and develop the user interface. The prototypes should incorporate enough pages to assess accurately what it's like to move from menus to content pages. Second, creating a prototype allows the graphic designers to develop relations between how the site looks and how the navigation interface supports the information design. The key to good prototyping is flexibility early on: the site prototypes should not be so complex or elaborate that the team becomes too invested in one design at the expense of exploring better alternatives.
Typical results or contract deliverables at the end of this stage could include:
At this stage the project acquires its look and feel, as the page grid, page design, and overall graphic design standards are created and approved. Now the illustrations, photography, and other graphic or audiovisual content for the site need to be commissioned and created. Research, writing, organizing, assembling, and editing the site's text content is also performed at this stage. Any programming, database design and data entry, and search engine design should be well under way by now. The goal is to produce all the content components and functional programming and have them ready for the final production stage: the construction of the actual Web site pages.
Typical products or contract deliverables at the end of this stage could include:
Whether you develop your site on you own or hire a professional Web developer, you should develop page templates for your new Web site. It's much easier to add new pages if you can start from a page that already has the basic navigation and site graphics in place. If you share page development with other people, you will also want to be able to give your team members templates to use, along with instructions on how to handle page text and content graphics according to your standards. Popular Web site development software packages such as Macromedia's Dreamweaver offer powerful templates and standard reusable libraries of site graphics and HTML that make it easy to create new pages and maintain your site.
For many organizations, providing equal access to Web pages is institutional policy, if not a federal mandate. It is critical, therefore, that you validate your designs and page templates and the content of your site throughout the development process to ensure that your pages are accessible to all users. To check the accessibility of your pages you can use a tool like Bobby (www.cast.org/bobby). Bobby is a free service provided by the Center for Applied Special Technology. After you supply the URL (Uniform Resource Locator) of your page, Bobby checks the page against the Web Accessibility Initiative guidelines and flags potential barriers for users with disabilities. Bobby also recommends changes that will improve the accessibility of your pages. Check your designs at every development milestone to avoid time-consuming and potentially costly revamping efforts.
Only at this mature stage of the project are the bulk of the site's Web pages constructed and filled out with content. By waiting until you have a detailed site architecture, mature content components, and a polished page design specification you will minimize the content churning, redundant development efforts, and wasted energy that inevitably result from rushing to create pages too soon. Of course, you will always learn new things about your overall design as the prototype matures into the full-blown Web site. Be prepared to refine your designs as you navigate through the growing Web site and discover both weak spots and opportunities to improve navigation or content.
Once the site has been constructed, with all pages completed and all database and programming components linked, it is ready for beta testing. Testing should be done primarily by readers outside your site development team who are willing to supply informed criticism and report programming bugs, typographic errors, and critique the overall design and effectiveness of the site. Fresh users will inevitably notice things that you and your development team have overlooked. Only after the site has been thoroughly tested should you begin to publicize the URL address of the site to a larger audience.
Typical products or contract deliverables at the end of this stage should include:
Most business or departments in larger enterprises will contract with a Web development group to create the initial site design and to build all the pages in the first version of the Web site. They then assume responsibility for the site, doing some or all of the day-to-day maintenance and updating content as needed to keep the site current.
Often not until the practicalities of site maintenance come up do customers realize the importance of understanding the details of how the Web developer generated the HTML and other code that makes up the Web site. Although all HTML is much the same to Web browsing software, how the HTML is formatted and what Web authoring tool the developer used can make a huge difference in how the code looks to a human reader. Consider the two code examples below:
Example 1
<! — START OF SCHEDULE TABLE ======= — >
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%" cellspacing="0" cellpadding="1">
<tr valign="top">
<! — =============================== — >
<td width="50%">
<p class="tabletext">
Deadline for Submissions</p>
</td>
<td width="2%">
</td>
<td width="48%">
<p class="tabletext">
Meeting Dates 2001</p>
</td></tr>
<! — =============================== — >
Example 2
<table summary="Human Investigations Committee II schedule, FY 2001." border="0" width="100%" cellspacing="0" cellpadding="1"><tr valign="top"><td width="50%"><p class="tabletext">Deadline for Submissions</p></td><td width="2%"> </td><td width="48%"><p class="tabletext">Meeting Dates 2001</p></td></tr>
Which example do you find easier to understand? These code examples are exactly equivalent to Web browser software, but most people would find Example 1 significantly easier to read and understand. If you contract with a developer to build your site, it is crucial to understand how the developer writes code, what state the code will be in when the site is delivered, and whether the software used by the developer is compatible with what you will be using to maintain the site after delivery. Some Web development software produces HTML code that is nearly impossible for a human to read without significant (and expensive) reformatting. Other programs (such as Macromedia Dreamweaver) produce HTML code that is easy for Web programmers to read, which can make a huge difference if you decide to change Web developers or if you decide to edit HTML directly in maintaining your site. If you hire someone to create your Web site, be sure to ask what tools he or she will use to write the HTML and any other code. Ask to see examples of HTML code written for other clients. Check the code to be sure the developer inserts explanatory comments and dividers for legibility in the code. Be sure you understand whether there will be any problems or conflicts in using your favorite Web tools to edit the HTML code your Web developer produces.
Your Web site should be an integral part of all marketing campaigns and corporate communications programs, and the URL for your site should appear on every piece of correspondence and marketing collateral your organization generates.
If your Web site is aimed primarily at local audiences you must look beyond getting listed in standard Web indexes, such as Yahoo and Infoseek, URL and publicize your URL where local residents or businesses will encounter it. Local libraries (and schools, where the content is relevant) are often the key to publicizing a new Web site within a localized geographic area.
You may also find opportunities to cross-promote your site with affiliated businesses, professional organizations, broadcast or print media, visitor or local information agencies, real estate and relocation services, Internet access providers, and local city or town directory sites. Your organization could also feature local nonprofit charitable or school events on your Web site. The cost in server space is usually trivial, and highly publicized local events featuring a Web page hosted within your site will boost local awareness of your Web presence. Site sponsorship might also interest local broadcast media as an interesting story angle.
Your home page URL should appear in all:
An abundance of information about visitors to your site can be recorded with your Web server software. Even the simplest site logs track how many people (unique visitors) saw your site over a given time, how many pages were requested for viewing, and many other variables. By analyzing the server logs for your Web site you can develop quantitative data on the success of your site. The logs will tell you what pages were the most popular and what brands and versions of Web browser people used to view your site. Server logs can also give you information on the geographic location of your site readers. The usefulness of your site logs will depend on what you ask of the server and the people who maintain the server. Detailed logs are the key to quantifying the success of a Web site. Your Webmaster should archive all site logs for long-term analysis and should be prepared to add or change the information categories being logged as your needs and interests change.
A number of popular software packages are designed to produce easily readable site traffic reports, complete with data graphics and charts to aid in data analysis. As a service to customers, site hosting companies often offer reports from popular site analysis programs like WebTrends, often free of charge. Before contracting with an Internet Service Provider (ISP) for site hosting services, always ask about site analysis services. If your ISP or corporate Web site does not offer a good site traffic analysis package, ask whether the Webmaster can give you access to a monthly server log of your account. Basic versions of traffic analysis programs like WebTrends cost about three hundred dollars, and you can run them on a personal computer if you can gain access to the raw Web server log from your ISP or corporate Webmaster.
Don't abandon your site once the production "goes live" and the parties are over. The aesthetic and functional aspects of a large Web site need constant attention and grooming, particularly if a group of individuals shares responsibility for updating content. Someone will need to be responsible for coordinating and vetting the new content stream, maintaining the graphic and editorial standards, and assuring that the programming and linkages of all pages remain intact and functional. Links on the Web are perishable, and you'll need to check periodically that links to pages outside your immediate site are still working. Don't let your site go stale by starving it of resources just as you begin to develop an audience — if you disappoint them by not following through it will be doubly difficult to attract them back.
The site editor should be sure that the Web site is regularly backed up onto a secure and reliable storage medium to ensure that a catastrophic hardware failure in your Web server does not wipe out your Web site. Most Web servers maintained by information technology professionals or commercial Web service providers are backed up at least once a day. If you don't know what your particular backup schedule is, ask your Webmaster or Web services vendor. Human error is the most common reason you may want quick access to a backup copy of your Web site. Unfortunately, it's easy to accidentally overwrite an old file (or a whole directory of files) over a newer version on the Web server, to delete something important in error, or to inadvertently wipe out someone else's work when updating a Web site. A recent backup (ideally no more than twenty-four hours old) can often be a lifesaver in correcting a mistake.
If your site is successful, it will quickly become an important record of your enterprise's work, your accomplishments, and a valuable record of the "state of things" as the site evolves over time. Unfortunately, too little attention is paid to this aspect of Web sites, and we are collectively losing huge pieces of our history because no one thinks about preserving permanent records of a Web site. Unless your Web site is prohibitively large, your Web site editor could arrange to collect and store the files of the site periodically or contract with your Web service provider to set aside a backup version at regular intervals so that it can be stored for long-term use. We take for granted the "paper trail" of history left by conventional business and work practices. Without a plan for preserving our digital works, our collective history may vanish without a trace.
Burdman, Jessica R. 1999. Collaborative Web development: Strategies and best practices for Web teams. Reading, Mass.: Addison-Wesley.
Dobson, Michael Singer. 1996. Practical project management: Secrets of managing any project on time and on budget. Mission, Kans.: SkillPath.
Frenza, J. P., and Michelle Szabo. Web and new media pricing guide: A business and pricing guide for Web sites and related digital media. Indianapolis, Ind.: Hayden Books.
Friedlein, Ashley. 2001. Web project management: Delivering successful commercial Web sites. San Francisco: Morgan Kaufmann.
Graphic Artists Guild et al. 1997. Graphic Artists Guild handbook: Pricing and ethical guidelines, 9th ed. Cincinnati, Ohio: North Light Books.
Reiss, Eric L. 2000. Practical information architecture: A hands-on approach to structuring successful Web sites. Reading, Mass.: Addison-Wesley.
Siegel, David. 1997. Secrets of successful Web sites: Project management on the World Wide Web. Indianapolis, Ind.: Hayden Books.
Veen, Jeffrey. 2001. The art and science of Web design. Indianapolis, Ind.: New Riders.
Meyer, Eric. A. 2000. Cascading Style Sheets: The definitive guide. Sebastopol, Calif.: O'Reilly.
Musciano, Chuck, and Bill Kennedy. 2000. HTML and XHTML: The definitive guide. Sebastopol, Calif.: O'Reilly.
Niederst, Jennifer. 1999. Web design in a nutshell: A desktop quick reference. Sebastopol, Calif.: O'Reilly.
Powell, Thomas A. 2000. Web design: The complete reference. Berkeley, Calif.: Osborne/McGraw-Hill.
Spainhour, Steven, and Robert Eckstein. 1999. Webmaster in a nutshell: A desktop quick reference, 2d ed. Sebastopol, Calif.: O'Reilly.