[ansonkelvin]

PROCESS

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.
Chapter contents

• Before you begin
  • Planning
  • Developing a site specification
• The site development process
  • Site definition and planning
  • Information architecture
  • Site design
  • Site construction
  • Site marketing
  • Tracking, evaluation, & maintenance

[ansonkelvin]

Before you begin

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.



Section contents

• Planning
• Developing a site specification

[ansonkelvin]

Planning

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.
What are your goals?

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.
Know your audience

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.
Design critiques

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.
Content inventory

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.

[ansonkelvin]

Developing a site specification

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.
Goals and strategies

• What is the mission of your organization?
• How will creating a Web site support your mission?
• What are your two or three most important goals for the site?
• Who is the primary audience for the Web site?
• What do you want the audience to think or do after having visited your site?
• What Web-related strategies will you use to achieve those goals?
• How will you measure the success of your site?
• How will you adequately maintain the finished site?

Production issues

• How many pages will the site contain? What is the maximum acceptable count under this budget?
• What special technical or functional requirements are needed?
• What is the budget for the site?
• What is the production schedule for the site, including intermediate milestones and dates?
• Who are the people or vendors on the development team and what are their responsibilities?

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.
Avoiding "scope creep"

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.

[ansonkelvin]

Every significant Web project poses unique challenges, but the overall process of developing a complex Web site generally follows six major stages:

1. Site definition and planning
2. Information architecture
3. Site design
4. Site construction
5. Site marketing
6. Tracking, evaluation, and maintenance

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.
Section contents

• Site definition and planning
• Information architecture
• Site design
• Site construction
• Site marketing
• Tracking, evaluation, & maintenance

[ansonkelvin]

Site definition and planning

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.
Site production checklist

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.
Production

• Will your site production team be composed of in-house people, outside contractors, or a mix of the two?
• Who will manage the process?
• Who are your primary content experts?
• Who will be the liaison to any outside contractors?
• Who will function long-term as the Webmaster or senior site editor?

Technology

• What browsers and operating systems should your site support?
  • Windows, Macintosh, UNIX, Linux
  • Netscape Navigator, Internet Explorer; minimum version supported
• Network bandwidth of average site visitors
  • Internal audience or largely external audience?
  • Ethernet or high-speed connections typical of corporate offices
  • ISDN, or DSL medium-speed connections typical of suburban homes
  • Modem connections for rural, international, or poorer audiences
• Dynamic HTML (HyperText Markup Language) and advanced features?
  • JavaScript or vbscript required
  • Java applets required
  • Style sheets required
  • Third-party browser plug-ins required
  • Special features of the UNIX or NT server environments required
  • Special security or confidentiality features required
• How will readers reach the support personnel?
  • Email messages from readers
  • Chat rooms, forums, help desks, or phone support
• Database support?
  • User log-ins required to enter any site areas?
  • Questionnaires required?
  • Search and retrieval from databases needed?
• Audiovisual content
  • Video or audio productions?

Web server support

• In-house Web server or outsourced to Internet Service Provider (ISP)?
  • Unique domain names available (multihoming)
  • Disk space or site traffic limitations or extra costs
  • Adequate capacity to meet site traffic demands?
  • Twenty-four-hour, seven-days-a-week support and maintenance?
  • Statistics on users and site traffic?
  • Server log analysis: in-house or outsourced?
  • Search engine suitable for your content?
  • CGI (Common Gateway Interface), programming, and database middleware support available?
  • Database support or coordination with in-house staff?

Budgeting

• Salaries and benefits for short-term development staff and long-term editorial and support staff
• Hardware and software for in-house development team members
• Staff training in Web use, database, Web marketing, and Web design
• Outsourcing fees
  • Site design and development
  • Technical consulting
  • Database development
  • Site marketing
• Ongoing personnel support for site
  • Site editor or Webmaster
• Ongoing server and technical support
• Database maintenance and support
• New content development and updating

Appoint a site editor

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.

[ansonkelvin]

Information architecture

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:

• Detailed site design specification
• Detailed description of site content
• Site maps, thumbnails, outlines, table of contents
• Detailed technical support specification
• Browser technology supported
• Connection speed supported
• Web server and server resources
• Proposals to create programming or technology to support specific features of the site
• A schedule for implementing the site design and construction
• One or more site prototypes of multiple pages
• Multiple graphic design and interface design sketches or roughs

[ansonkelvin]

Site design

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:
Content components, detailed organization and assembly

• Text, edited and proofread
• Graphic design specifications for all page types
  • Finished interface graphics for page templates
  • Header and footer graphics, logos, buttons, backgrounds
• Detailed page comps or finished examples of key pages
  • Site graphic standards manual for large, complex sites
• Interface design and master page grid templates completed
  • Finished HTML template pages
• Illustrations
• Photography

Functional and logic components

• JavaScript scripts, Java applets designed
• Database tables and programming, interaction prototypes completed
• Search engine designed and tested

Templates

Whether you develop your site on your 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.
Accessibility

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 (
To view links or images in this forum your post count must be 1 or greater. You currently have 0 posts.
). 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.

[ansonkelvin]

Site construction

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:

• Finished HTML for all Web pages, all page content in place
• Finished navigation link structure
• All programming in place and linked to pages, ready for beta testing
• All database components in place and linked to site pages
• All graphic design, illustration, and photography in place
• Final proofreading of all site content
• Detailed testing of database and programming functionality
• Testing and verification of database reporting features
• Testing of site reader support procedures, answering email, etc.
• Archives of all site content components, HTML code, programming code, and any other site development materials

Maintainable code

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%">
&nbsp;
</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%">&nbsp;</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.

[ansonkelvin]

Site marketing

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:

• Print advertisements
• Radio and television advertisements
• Lobby kiosks in high-traffic areas of your enterprise or in local libraries, schools, or other suitable venues
• Direct mail campaigns
• Business cards
• Stationery
• Bills and statements
• Product manuals and product packaging
• Response cards and warrantee cards
• Publications and promotional materials
• Press releases
• Posters and billboards