Link to CD&G Marketing Services Link to CD&G Copy Writing Services Link to CD&G Creative Services Link to CD&G Digitizing Services Link to CD&G Promotion Services Link to CD&G Hosting Services Link to CD&G Training Services Link to CD&G Homepage

Command Design & Graphics

E-Commerce | Audio & Video | Partners | Pricing | Credentials | Sites Served | Art Gallery | Advice | Contact


Command Design & Graphics Microsoft SiteBuilder #234477

Here is one of the best pieces of information we've found anywhere that covers all the bases for the would-be web site planner or someone who wants to build a web site for their business. We find that we agree with almost everything the author preaches. We hope you enjoy the article.

So You Want to Build A Web Site?
Everything You Need to Consider From Initial Planning Through Launch

July 25, 1996

Domenick J. Dellino

For the Microsoft Site Builder Network


This article is aimed at first-time Web site producers—the project managers charged with pulling it all together. It is intended to be a "how-to, what-to-avoid, here's-what-you-need-to-remember" article that considers each step in implementing a Web site. The range of considerations necessary when planning and implementing a Web site is immense and differs from case to case. This article alerts you to many of the common pitfalls and flash points, plus technical, design, procedural, and even organizational considerations.


What Is a Site Producer?
Defining Objectives and Goals
Going Live
Getting the Word Out
Basic Definitions
HTML Resources
Further Reading


Planning a Web site for the first time can be daunting. This article is designed to answer the questions of those not familiar with the various ins and outs of Web publishing. This article covers:

1. Considerations that need to be made along the way, from conceptualization to implementation

2. An inventory of tasks to build a team around

3. Budget considerations for hardware, software, and human resources

4. Suggestions for conceptualizing, prototyping, producing, and testing your site

5. What to do after your site is launched, with recommendations for getting your site publicized

6. Launch logistics as well as some of the interdepartmental, managerial, and potential organizational issues involved in the development process

What Is a Site Producer?

A site producer oversees the development and implementation of a Web site and thus functions as a kind of general contractor, coordinating the efforts of everybody involved: third-party vendors, Internet Service Providers (ISPs), plus designers, editors, testers, developers, and other technical staff. The title site producer—just like movie producer—can mean different things to different people in different settings; typically, a site producer is in charge of pulling together and supervising the Web team. In most cases, the team should be selected to represent a broad range of skills: programming, editorial, marketing, and testing.

In addition to performing the supervisory and coordinating functions, a site producer should be able to champion the site—communicating the vision to the rest of the organization and securing the resources necessary to carry out that vision.

Defining Objectives and Goals

Whether you'll be doing all the tasks yourself or coordinating the work of people across multiple departments, clearly defined objectives and goals save time, money, rework, and most importantly, agony. It's not that you can't change your mind. Things happen. But if you plan well from the outset, you'll know how any change or compromise will affect the budget, functionality, launch date, or design when things do happen. The questions to answer first are:

• Why do we want to go online with a Web site of our own?

• Who is our target audience?

• Will other parts of the company want to participate?

• Is there a need to "go live" by a specific date?

• Do we have the hardware to host the Web site in-house?

• Do we have the technical expertise to build and maintain a Web site?

• How much time should we expect to devote to maintaining a site?

In broad strokes, the strategy here is to break the process down into two main steps: 1) figure out what you would like the site to do or contain—IGNORING any constraints, and 2) find out the financial, time and technical constraints you will have to work within.

Formula for success

Don't torpedo yourself by setting unrealistic expectations. Typical self-sabotage moves include trying to do too much of the work yourself, attempting to launch sooner than reasonable, thinking an ambitious site can be launched on a shoestring, and assuming that others in the organization will be interested in joining your online presence.

Think of the entire project as a balanced equation: resources on one side, and site scale and scope on the other. If the resources are reduced, then so must be the scale and/or scope. The more time, money, or bodies to devote to the effort, the grander the site can be. According to a recent survey conducted by the International Data Corporation, it is not uncommon for site development to take twice as long as expected and for costs to be four times greater than originally budgeted. (See "The Marketeer's Internet: Motivations, Costs, and Customization" by Mark Winther [International Data Corporation, March 1996].)

Although some people start by determining resource constraints and plan their site accordingly, I prefer to imagine all the things the site could be and then to scale back to fit resource constraints. Once again, the approach will depend on your situation. If you are the sole person working to get a site up in a week—as I once was—then you're not going to be spending a whole lot of time coming up with a grandiose—but completely unrealistic—plan. Still, you want to be clear about your objectives and your message. This will really help when making design and content decisions.

Why bother with a Web site?

The first question to ask is: "Why do we want to go online with a Web site of our own?"

You probably wouldn't be reading this if you hadn't already decided affirmatively. OK, but have you answered "Why?" Start by determining your online goals. Are they to:

• Establish name recognition or company identity?

• Provide product or service information?

• Sell product online?

Even if you simply want to create a presence on the Web, you will need to assess how high-tech you want to get and how artsy you want to look. One way to start by is by checking out other sites. Bookmark sites that are relevant to your industry and share them with your team. Ask yourself, "What is the first thing that comes to mind when I open some of those home pages? Are they well-organized or chaotic? Is the page too 'busy' with graphics and text? Does it take too long to download? Is the navigation clear? What kind of impression does the site make?"

Consider your audience as well. Will they want to see state-of-the-art graphics and Web page tricks, or are they going to want quick, no-frills access to data they can download and read offline? That doesn't mean a site needs to be graphic-laden to be inviting. Obviously it should be attractive, well-organized, and have interesting content to keep people coming back. If your primary objective is name recognition and company identity, consider separate pages for: mission statement; company background, history, and officers; products, services, and marketing information; employment opportunities; white papers; and links to other sites.

If you want to take it beyond the basic "we need to be online" presence, then you should also plan to devote space to describing products and services. You may want to have a way for your customers to reach you easily via e-mail or include a survey form to capture customer information profiles and any customer comments, suggestions, or requests.

If you want to sell product online, then your site will need sophisticated scripts, databases, and server-side capabilities; you'll also need to ensure secure commerce for transactions. Conduct brainstorming sessions with your team on how to meet the site objectives, place the list aside, and review it when you have finished the first prototype to determine if you've met the objectives.

Who is our target audience?

Thinking about your potential audience is an important step. Who are you trying to reach? Existing customers? New customers? A mixture?

Will other parts of the company want to participate?

If you are in a large company, consider that other departments or teams may want to join in. The sooner you bring them into the process and get their feedback or help the better. The help you receive can aid in gathering and defining objectives, as well in adding to your potential audience and the overall appeal of the site.

Another key to success is to communicate clearly with other departments and staff to get them involved early in the process, gather their ideas, and keep them informed of your progress. Don't make the mistake of protecting them from the work involved in producing a Web site. If the organization has made the decision to do a site:

• Get sponsorship for participation from the highest levels down.

• Convey the sense of worth the site offers for your organization and the value it brings to your audience.

• Set clear deadlines for those wanting to contribute.

• Establish a process for drawing the line on design consideration (that is, make it clear to everyone where the final authority and decision-making responsibility lies).

It will also be important to let marketing know your URL (Web site address) as soon as you have it so that it can be added to all marketing and collateral materials.

One of the challenges in launching a site is getting others in the organization share your vision and helping them to understand the migration from print to electronic media. As Gordon Todd of The Nature Conservancy of Washington suggests, "It's best to get buy-in early in the game, but you need to be clear with people about how the process will be managed. The projects that work best are those that reflect a shared creative vision. At some point, folks just have to trust that you'll be able to pull it together for them." The alternative is a collection of great ideas that may not harmonize.

Is there a need to "go live" by a specific date?

If your site launch is timed to coincide with another major event, say a product launch or annual meeting, the conventional wisdom is that you'll actually need about twice the amount of lead time that you estimate you'll need. Of course, by the time the launch date is determined, it may already be too late to allow enough time for everything you had hoped to build in; so, unless the launch is a long way off, expect something else to give. You may have to scale back some of the cutting-edge technology or rein in the ambitious content you had hoped to provide.

One way to solve the problem of not enough time to provide desired features is to use a phased-in launch. That way you can meet your launch deadline without including every single new feature or every single piece of content on the launch day. This approach also gives you the flexibility to adjust features and content based on what works and what doesn't, as well as gather feedback from your audience (if you have a mechanism for this.)

Let's consider an example. You have a wish list of ideas from people in your organization. If, based on your resources, you think you can deliver about two-thirds of the wish list, break that first two-thirds in half and promise the first half. This will be Phase I. While you are getting Phase I ready for launch, you'll also be planning Phase II. As you move toward the launch of Phase II, you'll also be working on Phase III.

Hopefully, good planning and organization will obviate the need for reworking, but be prepared to change some of your plans in the later phases as you learn from experience.

Remember, everything is changing: your company, your customer's needs, and the technology. And that represents only three vectors from which you must predict an outcome! Just wait until you add organizational pressure to the equation. The point is simply to plan conservatively if you have hard deadlines to meet. A phased implementation will help you adjust more easily to these changes as they affect your planning and implementation.

This is a good place to mention budget. Is the budget you're working within fixed or negotiable based on desired functionality? Again, you probably don't have $1 million to turn the whole thing over to a design firm. Most often, the situation dictates compromises. Even well-planned sites—including those produced by experienced firms—often run over-budget by a factor of two or three. Part of the reason for this is that the technology is moving so rapidly that it is nearly impossible to anticipate the potential costs even a few months out. So, if you must stay within a fixed budget, don't be tempted by late-breaking technology that can require more time and money.

Do we have the hardware in-house to host our own Web site?

This gets to more of the nuts and bolts of planning the site. Again, scale is an important factor, but a reasonable minimum configuration would be a Pentium® Pro machine running Windows NT® with at least 32 megabytes of RAM. You'll want to consider getting an ISDN line if not a T1, and you'll need a bank of fast modems. (See additional specifics on hardware, below.)

Do we have the technical expertise to build and maintain a Web site?

Technical expertise is another consideration. Do you have the in-house expertise to build a prototype? To install and maintain Internet server software? To develop the site and ready it for launch? These factors are discussed in detail in the "Tasks Inventory" below, but the survey by International Data Corporation (referenced above) reveals that by far the greatest part of Web development costs for commerce-ready sites were devoted to customization. Between $500,000 and $800,000 is spent on a typical site to secure talent and develop custom software and design unique sites. Of course, your site may not require the customization of the "commerce-ready" sites in the survey, but you may need expertise that is more efficient to hire than to develop in-house.

Even if you don't have the HTML programmers and net-savvy personnel you need, you will probably be able to develop a prototype on your own. While many recommend developing the prototype using HTML tools like FrontPage™ or PageMill™, nearly any software that allows you to use buttons to create "animation" will do. Presentation programs such as Microsoft® PowerPoint®, Microsoft Persuasion, and Adobe® Acrobat™ are possibilities. Macintosh® users could also prototype in HyperCard®. While these programs simulate the navigation between screens, the disadvantage is that they don't provide the long scrolling pages that make the Web a unique medium. Useful tools for prototyping as well as publishing are described in the Guide to Microsoft Internet Publishing Tools.

When I developed my first Web site for Aradia Women's Health Center in Seattle, I used PageMill because I was not an HTML programmer and I was developing on a Macintosh. PageMill was easy to use, and my efforts could be built on by the programmer who added a "hits" counter, a guest book, and an automated e-mail return. Moreover, building the prototype in an HTML environment provided an excellent way to gather and organize the content. Because the Aradia site was for a private, non-profit corporation and was limited to six pages, I could easily arrange all the content and add the internal links for navigation I wanted within the site.

How much time should we expect to devote to maintaining a site?

The range of required site-maintenance time depends on how often you want to add or change content and revamp graphics. Some site managers recommend changing content weekly, others daily, to keep the site interesting and your audience coming back. Other considerations are whether or not you'll be responding to customer requests or orders, the nature of the content you've put up (is it date sensitive—that is, does it describe upcoming events?), and how complex the site ends up being.

When I volunteered to help plan the Aradia site, the resources available to maintain the site became a major design consideration. Because Aradia did not have the staff to answer e-mail or respond to feedback daily, we dropped the automated e-mail return and guest book features. Also, because the ISP (Internet Service Provider) hosting the site charged US$60 per hour for any changes—even if I made the changes and sent them the HTML—the site producer decided to limit revisions to quarterly changes that would coincide with the publication of their newsletter. For our Phase I of Aradia's foray onto the World Wide Web, we decided to count the "hits" the site received and assess how many client phone calls the site generated before expanding the site to include tasks that would require additional staff resources.

For a site as ambitious as The Nature Conservancy of Washington's, however, even quarterly changes can require significant ongoing attention. Leslie Kellogg—whose responsibilities at The Nature Conservancy of Washington quickly evolved from spending 75 percent of her time on fundraising and 25 percent on communications to being a full-time site producer—warns, "We expect to have to devote at least a full-time staff person after the site goes live. That person will need to manage content, design how to present such things as upcoming volunteer events, create and maintain new links, coordinate with our capital campaigns, and continue to involve the staff in the metamorphosis of the site. It is a very organic process, one that many people don't understand intuitively. A large part of my job has been devoted to getting people to understand the process of developing content for the Internet. Since the medium is not directly translatable from the printed word, we've had to develop a process for writing, editing, and review that takes a lot of hand-holding. This means setting people's expectations about the timing and degree of feedback they'll be involved in."

As Kellogg points out, "If you're not ready to devote the effort to keep it fresh, then you may not be ready to launch the site in the first place. You might as well wait six months and reconsider it then."


Pulling together your team

Perhaps it goes without saying, but unless you know it all—from HTML programming and server setup to graphic design and content organization—you will need to rely on in-house experts, hire contractors, or pay for an ISP. Not all of the tasks and responsibilities considered below require an individual staff person. How large your team should be will obviously depend on the size and scope of your site. Most importantly, remember that the individuals assigned to the roles listed below should realize that the entire Web game is a fast-moving target.

Team tasks

Here are some of the tasks involved in pulling a site together.

Acquisitions. Acquiring content involves helping gather and organize content, following up on deadlines with content providers, helping plan the prototypes, and providing an occasional sanity check.

Coordination. Once the site is launched, processes need to be defined for updates. This task involves coordinating phased updates after launch, managing revision control, and downloading and distributing information collected in databases and e-mail.

Liaison to other departments. Although this role will likely be taken on by the site producer, it is worth mentioning separately here.

Creative services/graphic design. There are really two major components to this: graphic design and production. Graphic design is akin to art direction on a magazine. In a smaller shop an art director will also do a lot of graphic production work using tools such as Adobe PhotoShop™ or similar graphics programs to provide icons, buttons, backgrounds, logos, and optimized graphics for the Internet. In larger groups, there will probably be staff devoted exclusively to graphic production. (See Decreasing Download Time Through Effective Color Management.)

Graphical user interface/usability testing. Not everyone will have the resources to conduct focus group testing of the site before it is launched, but a user interface expert's assessment of the usability of your site design can improve the site and your users' experience of it.

Writing/editing. If you want to publish information that is not already available, you will need writers to create fresh content. Site writers and editors should think about which topics might interest your audience in the future so that the content of the site will always be fresh; it should be dynamic and must grow to keep readers coming back.

HTML production. This is a blend of HTML authoring and testing skills. Typically this task involves converting content to HTML, assisting in testing content and fixing bugs, and coordinating the launch and updates with the site administration team or ISP.

Site administration or hiring an Internet Service Provider (ISP). Site administration responsibilities will vary a great deal depending on whether you are hosting the site in-house. If not, you'll need to check with your ISP to know what services they provide. If their services are minimal, the site administrator might be responsible for maintaining a functioning copy of the site in-house and uploading it to the ISP after changes have been made.

Testing. Testing is an extremely important part of the process and ample time needs to be built into the production schedule to find bugs, make revisions, and retest before launching. The need for testing resources and time are often grossly underestimated, but given the host of new technologies, their growing complexity, and the problem of multiple browsers with diverse capabilities, you can be sure that you'll require more, not less, testing in the future. For specifics on what test scripts should include, see the Testing section below.

HTML programming. This task can involve either programming the entire site or augmenting the work done in the prototype created in an HTML tool. Custom effects that HTML tools cannot automatically generate also require HTML programming.

Software development. New Web technologies such as Visual Basic® Scripting and ActiveX™ controls, while giving Web authors and designers more flexibility, can also present an added technical burden. A good software developer can really be a plus if you are planning to take advantage of some of these new technologies, want to evaluate new technologies and tools, or create your own tools and utilities to automate processes.

In small organizations, a single person might perform more than one of the above functions. In really grand endeavors, there may be several people performing each role (that is, several writers, several testers, and so forth.) A site producer may wear a number of these hats, but be aware that the time involved in doing anything for the first time is usually greater than you think. The more that tasks can be broken down into distinct units, the more likely you'll be able to delegate them—and the greater your chance of success in meeting deadlines and achieving broader organizational acceptance.

First team meeting

Once you have your team selected and the broad objectives established, it's time to bring the team together for your first meeting. Here's what that first agenda might contain:

• Discuss the overall objectives and the top-level vision for the site.

• Present the concept. Encourage everyone to offer input.

• Determine who may be representing others not present but who want to provide input.

• Create timeline for completion of the "objectives-gathering" stage.

• Brainstorm on which media (text, graphics, photos, video or audio clips, and so forth) are most appropriate for the various types of information you have to present.

• Discuss all the tasks so that others can be aware of who is responsible for what. (Remind everyone to anticipate change.)

• Divvy up the tasks and discuss possible overlap. Make sure everyone understands the specifics of their component and generally understands what others will cover.

• Set clear expectations for what everyone should have completed by the next meeting.

• Establish a time for regular meetings, and propose a loose agenda for those meetings so that people will come prepared and know what they are expected to contribute.

Budget considerations

The budget for your site will depend on its complexity, depth of content, and degree of sophistication. In some ways, it isn't meaningful to attempt to define what makes a site small, medium, or large. I prefer to consider the size of the project rather than the site, because a site could be fairly easy to construct but still contain a great deal of information.

If you can build your entire site using minimal HTML programming or an HTML tool like FrontPage or PageMill, I would consider the project a small one. The weakness with this definition of "small" is that the site can contain hundreds of pages, which can take a very long time to pull together. For the Aradia Women's Health Center site, we were limited to 5 megabytes (MB), and six "pages." Because we elected not to add any special HTML features that PageMill couldn't generate (except a counter), this could easily be considered a small project: it took about three days to learn PageMill and pull the site together. The PageMill HTML files were then sent to the ISP, who added a counter and posted the site. Hosting the site for a year and making changes during the first 30 days cost $300. Because our site was text-rich and the few graphics used were small and already available, the entire site occupied less than 2 MB.

A large site could be one that requires sophisticated HTML programming that incorporates database searches, audio and video clips, animation, and security for conducting commercial transactions. The cost of such sites averages in the neighborhood of $1 million and the sites have required up to a year to implement.

On the high end, to implement and maintain an active commerce-based Web site, one survey showed hardware costs that range from $150,000 to $200,000 for the first year. Other costs include: software (off-the-shelf; $10,000 to 50,000); support and maintenance for 12 months ($180,000-200,000); and staffing, custom development, and design ($500,000 to 800,000), bringing the average cost to $1,298,000. (See "The Marketeer's Internet: Motivations, Costs, and Customization" by Mark Winther [International Data Corporation, March 1996].) Note that these costs do not include marketing, advertising, publicity, or internal training costs. So it is likely that the total costs for really large sites could easily exceed $1.5 million.


Until recently, most Internet sites were hosted on UNIX platforms, but the rising speed and power of Intel's Pentium Pro platform, and the accessibility of multi-processor Windows NT machines is enabling rapid migration to this low-cost platform that you may already have on-site. If you are considering hosting your own site, a good place to start is Microsoft Internet Information Server Performance Analysis, which analyzes the performance of the Microsoft® Internet Information Server (IIS) in comparison with other Windows NT™, UNIX®, and NetWare®-based Web Servers.

Don't think that you can avoid making decisions if you have your site hosted by an ISP. For larger sites, costs vary based on the type of connection desired (T1 or T3), the amount of bandwidth desired, the amount of data stored on the site, and the number of files downloaded ("hits") from the site. For an example of the various options with prices, see WCO Lata 1 Commercial Internet Prices.

Another alternative, for those not intimidated by hosting your own Web site but who would like help getting it installed, is the growing number of vendors providing "turnkey" solutions such as the ones offered by Global ISP, Inc.. Its Internet Service Provider Site Turnkey Solution (January 1996) includes the computers and communications equipment, installed hardware and software, operation manuals, installation, UPS stand-by power, tape backup, four 28.8 modems, and equipment to connect to your local and long-distance telephone companies for Internet access.

Of course, not everyone is jumping in and conducting commercial transactions online. If you are just getting started and are not sure you want to undertake the purchase and maintenance of the hardware infrastructure, having an ISP host your site can be a cost-effective way to test the waters. At Compass Communications, Inc., for example, the cost for setup and domain registration of a virtual site is $200, plus $100/month. This includes unlimited PPP/SLIP/CSLIP/Shell access, 50 MB of disk storage, 1 gigabyte of Web transfer "hits," anonymous FTP ( and Domain Mail aliasing ( for 1 gigabyte—more than adequate for a small to medium site. If you later decide to bring your site in-house, you shouldn't lose much time.

Note: The ISPs mentioned in this section are provided for comparison purposes only and their mention should not be considered an endorsement of their services by either Microsoft Corporation or the author. As always, please note that these links point to servers that are not under Microsoft's control. Please read Microsoft's official statement ( regarding other servers.


As mentioned earlier, the costs for off-the-shelf software can range up to $50,000 for the first year if you're building an enterprise-level, secure transaction site for online commerce. Fortunately, most of us aren't. The software we'll have to choose from will consist primarily of Web server software—and some of the best ones are free, including Microsoft's Internet Information Server. For a thorough, non-biased review of the top Web server applications and platforms, see "Web Servers Need Power, Speed, and Multimedia Savvy" by Sam Murphy and Bob Doyle (New Media, June 3, 1996).

For more information on how to download Internet Information Server, please go to the Internet Information Server Home Page.

Human resources

To launch a complex site, a Web team of 40 people may work for months. For that reason, staffing can easily become the greatest expense. You can expect to pay very good money for HTML programmers. Designers, network and server administrators, and multimedia specialists can also add dramatically to the costs. If you don't have the talent in your organization already, it might be time to hire or contract for on-site training, especially because development time can take months.

Creating a schedule and time line

Once you have a clear view of the overall objectives, at least a rough idea of the timeframe and budget that you're working within, and knowledge of the tasks involved, create a schedule. While it's impossible to say how long everything might take—because it depends on the size, complexity, graphics, and functionality of the site—start with a best guess. Be sure to allow ample time in your plan for conceptualization, prototyping, production, testing, and the planning logistics for the launch party.


Once the tough decisions about objectives and goals have been reached, the team has been pulled together, and the content and structure of the site is agreed upon, you can start prototyping. But before you begin planning your own Web site, I highly recommend that you check out a number of other sites to see what and who is up on the Web. If you haven't done this already, visit a variety of sites to see what others are doing—particularly those in your industry. The following is a cross-section of a variety of sites I have found when surfing.

• The Louvre

• Senator Kennedy

• Amnesty International

• The Rolling Stones

• Daniel Pelavin Designer

• NBA (I'm not a sports fan, really!)

• A&E Television

• Toyota

• Aradia Women's Health Center


Begin by defining a specification for the site. This can be as simple as an outline identifying all the pages, text, and graphics the site will include or as thorough as a completely annotated prototype. Starting with a well-defined spec will help you manage "feature creep" and provide clarity for the developers. It is also an excellent tool for communicating to others in your organization what the site will be and for securing their buy-off on what will be included and what will be left to future releases. A well prepared spec should include documentation on:  

• What is to be included.

• How everything is supposed to work.

• Where all the links are and what they should link to.

• Complete copies of all the text—both text in graphics and text files.

• Screen shots of each page.

Keeping the spec up-to-date as it evolves through the development cycle also provides an excellent starting point for testing and will save time during the testing cycle when you'll likely need it most.

It is a good idea to begin the prototype by sketching the site in flow-chart form. This will help you organize your thoughts and help you visualize how the site fits together. This is also a time-saving step, because—once you have all the pages identified—links can be planned and dropped on each page as they're created. Adding a page to the site after you've begun prototyping might require that the links already created will have to be updated...a tedious process at best.

The prototyping stage includes coming up with the ideas and developing a working model of the site. Make people aware that this is only a mock-up, and that not everything will necessarily be working (such as forms, e-mail reply, counters, and so on) as they will in the production version. Tasks at this stage include:

• Developing an outline or flow chart diagram of how the site will be structured and what content it will include.

• Creating a mock-up or working prototype of the site.

• Adding content and graphic placeholders.

• Beginning design and production of graphics.

• Creating links.

• Assessing navigation and flow for fluidity.

A good example of a site flow chart is Progressive Network's RealAudio site map. A flow chart is not a prototype per se, but it can help in the initial planning stages to speed development of the prototype and can also later serve as a "map," giving your audience a bird's-eye view of the site. It can be created in Persuasion™, PowerPoint, or any program that creates flow charts. Don't spend a lot of time doing this if it means learning new software—a drawing on paper or a big white board will get you started just as well. You really want to save the bulk of your time in the prototyping stage for HTML authoring.

Start by getting estimates from your team of the time required to complete each task in this stage (especially if there are responsibilities that are beyond your control—such as preliminary resource planning by IS). Determine who needs to buy off on the conceptual plan.

Choosing a prototyping tool

Even if you're not an HTML programmer, I recommend that you prototype your site in an HTML environment. This not only gives you control over the content and a reasonably good way to organize it but also allows you to get a feel for the dynamics of links within your site. If you're like me, just seeing how things work inspires creativity you may never have thought yourself capable of.

For specifics on two of the most popular site-creation tools, see the Microsoft FrontPage and Adobe PageMill sites. Don't worry too much about waiting for graphics at this point. (Of course, if your art is ready you can drop it in.) Focus on the text content and flow of the pages. If you have the luxury of a creative services department at your disposal, show them what you're doing and communicate your wish list of illustrations, icons, and other graphics for the site. Consider whether or not it's best to wait until your list is complete, since you'll probably have a better idea of what you'll want once you've finished with the first version of the prototype.


In the production stage, besides doing the actual HTML programming, plan for regular reviews and tests of the pages, speed performance of graphic redraw and downloads, and frequent testing of the functionality on different browsers. Here's a checklist of some key considerations in the production stage:

• Start by examining the prototype and ensure that you have all the content—text files, graphics, clips, and so on.

• Define the pages the site will contain. This will allow navigational links to remain fixed while still allowing some flexibility in the contents of each page.

• Define, in advance, how you will manage "feature creep" (those temptations to allow previously unspecified features to creep into your site). Determine which is most sacred: Launch date? Budget? CFO's wish list?

• Does the development software you are using manage links for you? If not, plan extra time to edit links at the end.

• What can you develop completely in PageMill? FrontPage? What features will require an HTML Programmer?

• Are graphics optimized for fast downloading and redraw? (See Decreasing Download Time Through Effective Color Management.)

• Consider how each page will display on a standard 15-inch monitor.

• Determine which documents or articles you will make available as a downloadable file. The longer the article, the more likely someone will want to download it. Consider providing estimates of download time based on file size and modem speed.

• Does each document work: Visually? Technically?

• Have several sets of eyes check what works well and what doesn't--graphically, organizationally, and in terms of download time? What works for one person may be annoying to another.

• How will your site accommodate different browsers?

• Allow time after testing for programmers to fix bugs and fine-tune the site.

• Consider setting up a way to know how many "hits" your site is receiving. Decide whether you'd like to know from which sites your hits are coming. This may mean you will have to develop multiple home pages with counters on each.

• Consider a section to whet your readers' appetite for what's to come, especially if you're not going to do everything in the Phase I release.


This step is critical to a successful launch—and the more thorough it is, the better. Visitors who encounter one busted link may be frustrated; if they find two, they may leave the site. Allow enough time for testing. If you can incorporate the writing of test scripts into the production process, that would be great. Here are some important components of a good testing effort:

• Determine, in advance, who will be responsible for bug fixing.

• Test the site with all kinds of browsers (Internet Explorer, Navigator®, and so forth) on the original development platform.

• Test at least the last two versions of the browsers and any beta versions.

• Test the site with all browsers on a machine other than the development platform.

• Test using different browsers on Macintosh computers and PCs. Do the graphics appear the same size with different browsers?

• Test for design considerations and various monitor resolutions and sizes.

• Test the site from the "final resting place" (that is, the "go-live" server).

• Systematically check all links within the site.

• If your site contains forms or e-mail reply routines, test to see that they return information readable in the desired format and are stored in the appropriate directories on the server.

• Test links to other sites. If you will include disclaimers, are they consistent?

• Test downloading graphics with an empty cache, both at 14.4 baud per second (bps) and at 28.8 bps.

• Retest everything from a minimal browser configuration at a remote location.

• Test again after any changes are made.

I cannot stress enough the need for thorough testing. Time spent testing will be worth its weight in pizza. Once the testers have had their shot at it, a round of corrections have been made, and the site has been re-examined, try to enlist fresh eyes that have not viewed the site. This will approximate the experience of your audience. Listen carefully to their questions (such as, "Why can't I get there from the home page?") and their comments ("This screen is confusing."). Chances are these will be the same ones your audience would have.

Going Live

Be sure to test again after the site is launched. If the Internet server is on-site, test from off-site. Be especially sure that links and downloads are tested. Are your estimates for download times accurate? If the server is off-site, test from both the office and from home.

Make sure that your audience knows what to look for in the future—something to keep their interest piqued.

If you have asked your audience for feedback and have provided a means for them to contact you electronically, be sure to assess their comments as soon as they start coming in. You should already have a plan for Phase II, so the comments received can help you direct and prioritize those changes.

Don't feel the need to react to every "wish" on the list, but be sure you have the resources to craft the modifications you want. To keep your site from getting stale, it would be great to have a team of writers, but at the very least, have a process in place for tracking and reviewing internally generated documents. The use of "New" flags will also help in directing attention to the elements you add after launch; these are small graphics that highlight new items for a specific number of days after they're added.

Getting the Word Out

As mentioned earlier, you should have notified your marketing and public relations departments long ago about your URL. In really large companies, many departments may be involved in sending direct mail to their customers, so don't be shy about finding out who they are and asking them to let people know where to find you online.

If you've looked at enough of the sites in your industry, arena, or field, you should have a good idea of which sites host links to other sites (perhaps, by category). Notify them that your site is launched and that you'd like them to add a link from their site to yours. Include a brief description of your site as you'd like it to appear. Be creative. What sounds more interesting: "Graphic Design Firm" or "Cutting-edge creativity you have to see to believe!"? You get the idea.

Major search-engine sites are also a great place to get listed for no charge. Here's a few to notify about your site:

  • Google
  • Yahoo!
  • Lycos
  • Magellan

These sites will have links to many other sites that you can also send your URL. This is just a starting place from which you should be able to find dozens (if not hundreds) of sites that will either list everyone or that are specific to your industry, organization, or interest. Look for any sites that invite you to add your site to their lists. In addition, identify sites that you would like to link to and suggest a reciprocal link relationship. It's probably a good idea to begin bookmarking these sites from early in your perusal and planning stages.

If you decide you really want to make a splash on the Web and you have an advertising budget, consider a banner headline somewhere. A few square inches of space on the Google or Yahoo! home page, for example, is seen by a million people each day! 


For a comprehensive collection of acronyms and related definitions, see The World Wide Web Acronym and Abbreviation Server. See also the glossary at the end of the article Creating Platforms for Innovative Internet Software.

The author, Domenick J. Dellino, is a Seattle native, a recent Ph.D. in Applied Anthropology, and remembers running his first SPSS™ job from a deck of punch cards. He has taught and written about computers since the Apple had 48K.

For the Microsoft Site Builder Network



E-Commerce | Audio & Video | Partners | Pricing | Credentials | Sites Served | Art Gallery | Advice | Contact CD&G
© 1997-2017 Command Design & Graphics ~ High Point, North Carolina 27265 USA ~ All Rights Reserved

This page, URL, was last updated 04/26/17 05:37:47 AM -0600