A Comprehensive Website Planning Guide

Why Plan?

Planning is essential for most businesses and organizations. In practice, many people fail to plan their websites. Sometimes the ever-busy, dynamic nature of running a business is to blame; there are so many operational demands that proper time is not allotted to projects. But this often happens because people fail to recognize that planning for the Web is just as important as planning for anything else in a business.

The (Lengthy) Deck Example

Consider the example of building a deck. If you want a deck for your house, you probably won’t call several carpenters and ask, “How much is a deck?” If you do, you’ll get the smart answer: “It depends.” In order to provide you with an estimate, a carpenter needs some details about the project:

• What kind of wood? Cedar? Treated? Synthetic?
• Where exactly will the deck go? Are there any obstacles to work around?
• What height will it be, and how many levels will it have?
• Do you want benches, railings, built-in planters?
• Do you have clearance to bring special equipment into your yard?

Then there is the host of other things for the carpenter to consider: scheduling, building permits, inspection, maintenance, etc. That’s why a smart carpenter will answer your simple question with “it depends.”

It makes sense to meet with more than one contractor to address the questions above and more. When you choose a carpenter, they should provide a detailed plan that you both sign. Throughout the building process, the carpenter should check in with you periodically and discuss potential challenges and snags.

Surely all of this makes sense, but consider another scenario wherein there is no clear plan:

“Hi, Jennifer Carpenter. It’s Juan Homeowner. I need a 20 × 30-foot cedar deck in my backyard. I want it built in two weeks.”

“Okay, Juan. I’ll pick up the materials and get started tomorrow. If you have any questions, just see me in your backyard while I’m working.”

Jennifer Carpenter gets started by drilling post holes for each corner of the deck. She assumes that Juan Homeowner has secured a building permit from city hall, because that’s how most of her previous jobs have worked out… But there’s no building permit.

As Ms. Carpenter starts framing the deck, she notices that Mr. Homeowner has put a large hose reel against his house and connected it to the faucet. Based on where the deck will sit, the hose reel will have to go. She’s not sure if he will want to move it somewhere else or have his outdoor faucet replumbed to reconnect it and put it on the deck, which is two feet off the ground. She stops building and waits to ask Mr. Homeowner when he gets home… But it turns out that he’s on a business trip for three days.

When he gets back, Ms. Carpenter reaches him by phone. He’s not happy that his faucet will have to be moved, because it adds unplanned expenses to the project. But that’s not Ms. Carpenter’s fault. She’s not the plumber. She’s just putting the deck where he asked.

Once the deck is framed, she starts building a railing for one side. This wasn’t discussed, but she sees that there are small children around the house and thinks this is a good safety measure. Mr. Homeowner comes home one day and is happy to see the great progress on his deck, but he notices the railing.

Mr. Homeowner: “What’s this?”

Ms. Carpenter: “I added a railing to the side because you have kids. It’s a good safety feature.”

Mr. Homeowner: “I don’t have small children.”

Ms. Carpenter: “But I saw them playing in your front yard.”

Mr. Homeowner: “Oh, those are the neighborhood kids. My kids are in high school.”

Ms. Carpenter: “Well, a railing is still a good feature.”

Mr. Homeowner: “Fine, but can you make it shorter and put a bench next to it?”

Ms. Carpenter: “I didn’t buy enough wood for a bench, and the railing is already drilled and attached. I’d have to remove and recut it. Also, we didn’t talk about a bench.”

Mr. Homeowner: “Well, I’d like a bench here.”

Ms. Carpenter: “That will take more time. I won’t be able to get this done by your two-week deadline if we add the bench. Plus, I’d have to charge you for the extra wood.”

What began as a simple project has become a series of headaches, all due to a failure to plan.

From a Web professional’s perspective, developing a 50-page website for six unique stakeholders is far more complex than building a rectangular deck. A deck is a physical structure built in stages. You can look out the window and see the progress. In contrast, a website has a number of technical and administrative steps that aren’t visible to all.

A Caveat, and the “Waterfall” Method of Development

When I worked at an insurance company, business analysts from the information technology (IT) department would write project charters: long, painfully boring documents that attempted to outline every possible aspect of a website. I hated these documents and preferred to work by the seat of my pants. My reasoning in part was that websites are flexible, unlike print material. That is, their content can be changed at will. The idea that every aspect of a website could be pre-planned on paper was ludicrous.

IT departments that handle large projects often use something called the “waterfall” method of development: specify absolutely everything, down to the point size of the type, the line length of page headers and exactly how a simple photo gallery will work.

This is my view of the waterfall method: if you’re building a banking application that transfers money in and out of customer accounts, you’d better be sure your code is perfect. When dealing with debits and credits, there is zero allowance for error. For projects this critical, it makes sense to specify everything you’re going to do in great detail before writing a single line of code.

However, as I said, websites are flexible. So how do we reconcile the need for clear and detailed specifications with the inherent flexibility of the medium?

We do this by splitting the difference. By following the process I’ve outlined below, we can create a set of content and design specifications that greatly reduce the likelihood of mid-project glitches, while creating a framework that allows the website to grow with time. In fact, we can plan for expansion by allowing, for example, a news section to handle 10 news items or 200. When these specifications are properly implemented in a content management system (CMS), the website will give its editors the flexibility to swap out key photos, change titles and headers, reorder content, etc.—all within the framework established by proper planning.

The Value of Planning and Needs Assessment

I am frequently approached by prospective clients who want estimates for building their websites. Sometimes they have a general idea of what they want and possibly a simple website map. Others, especially organizations, will submit a request for proposal (RFP). In most cases, none of this gives the designer or developer enough information to generate an accurate proposal. Even a multi-page RFP usually does not have enough detail from which to create a proposal and estimate. If a prospective client just wants a ballpark figure, I can usually do this, but much more information is needed in order to arrive at an accurate cost.

Ideally, prospective clients would hire either a designer, developer or project manager to do a thorough needs assessment before requesting a proposal. However, clients don’t necessarily understand the efficiencies gained by up-front assessment. Ten hours spent on a needs assessment can save 30 hours of development time. Discovering the needs of a client halfway through a project is a recipe for headaches, extended development time, cost overruns and missed deadlines. As you’ll read below, failing to recognize and pay for proper planning creates big problems.

Common Results of Failing to Plan

• The designer or developer is forced to make assumptions, which may or may not be correct, about how certain content will appear on the website.
• The amount of back-and-forth communication about trivial matters can be multiplied many times over.
• Backtracking causes delays and missed deadlines.
• Work that falls outside the original scope of the project creates cost overruns.
• Confusion and client dissatisfaction are byproducts of a shoot-from-the-hip process.

Needs Assessment

Important things to remember:

• Unless you’re building an intranet, the website is not for you and must meet the needs of your client.
• A website is not an event. It is a flexible, extensible communications tool that reflects, negatively or positively, on the business.

Now we could potentially start using business-speak, as in “Assemble your key internal stakeholders.” That’s another way of saying: “Get everyone together who has something valuable to contribute.”

Aligning the Website With the Marketing Campaign

The website must work in concert with the overall marketing plan. The needs assessment for the website might overlap with the other efforts and approaches of the marketing department, which is fine. This is outside the scope of this article, but note that the established branding and marketing of the business should inform the structure and design of the website.

Roles: Who’s Doing What?

Every project is different, but these are the typical roles in a sizable Web project:

• Internal stakeholders (aka “clients”), who represent all primary aspects of the business;
• Project manager;
• Copywriter or editor;
• Web designer (graphic design, illustration, Web design);
• HTML coder (HTML, CSS, JavaScript, Flash);
• Web or CMS developer.

Keep in mind that one person can play multiple roles. The number of participants does not necessarily bear on the quality of the result. In some cases, a series of one-on-one meetings between company principals and an experienced designer can yield a great website.

Determine Website Content

Who’s Responsible?

As you prepare to add content to the website, think about who will contribute. In a five-person business, it might be just two of you, and that’s fine. In a large business or organization, 5, 10 or 15 people might be contributing content. The time required to edit and proofread both copy and visual content grows exponentially in proportion to the number of people who contribute content.

Content Is Not Just Text

Unless you are creating the dullest, most technical website imaginable, your content should consist of more than just plain text. By using one or more of the following multimedia elements, you’ll greatly enhance the appeal and usefulness of the website:

• Images;
• Documents (usually PDFs);
• Audio;
• Video (i.e., embedded from YouTube or Vimeo, or self-hosted);
• Adobe Flash files;
• Content feeds (from other websites, for example);
• Photos (from Flickr perhaps);
• Twitter stream;
• Facebook “friends” list;
• RSS feeds.

The Value of Good Photography

Like other elements of a website, photos communicate the brand of the organization. If you’ve just moved into a beautiful new building or storefront, you may have snapped some pictures of it and your staff on your $150 digital camera. In most instances, unless you have bona fide photography skills, these will not be quality photos. Try to budget for professional photography. You don’t necessarily need a lot of photos, just good ones. Twelve professional images is better than fifty amateur snapshots.

If your budget doesn’t allow for a pro, then contact your local art school or community college and ask for a recommendation. A budding student photographer with a good eye will work for cheap in order to build a portfolio. If you have no budget at all, then take the photos yourself, but pay special attention to lighting, framing and focus… and hope for the best.

In some cases, when generic images will suffice, stock photography can be used. But there is no substitute for quality photos of your staff, storefront, products or services.

The Value of Good Writing

Good writing, like good photography, requires a skill that not everyone possesses. Writing for the Web is different than writing memos, policy papers and technical documents. You might write great technical manuals for precision machining tools, but that doesn’t mean you can write well for the Web. If your organization doesn’t have someone who can write clear and concise marketing copy, hire an expert. If you can write reasonably well but need some guidance, consider hiring an editor to polish your output.

Quick Writing Tips

Consider your audience and write accordingly. Try to see the business from the customer’s perspective. What do they care about?

Avoid business-speak, confusing acronyms and dry details. Your customers do not work at your shop, office or widget factory; they are the ones purchasing your products or services. Speak to them accordingly. When appropriate, write in generalities, and save the hardcore details for multi-page PDFs (as downloads). This approach is especially useful for product information, white papers and copy that approaches or exceeds 1000 words.

Here is a useful approach when writing for the Web:

1. Write your first draft,
2. Cut it in half,
3. Cut it in half again,
4. Add bulleted and numbered lists where possible,
5. Send it to the editor.

Reading on a screen is fatiguing. A screen, whether a massive 26-inch monitor or a diminutive smartphone, projects tiny points of light at your eyes. Consequently, reading long stretches of text on it can be very tiring. Users will scan for key points in the text, so short blocks of copy and bulleted or numbered lists are helpful because they’re easy to spot.

Don’t style the content. Most writers prefer to work in Microsoft Word or a similar program. This is fine, but Word is notorious for outputting messy code. Don’t worry about colors, fonts and alignment. Just write well. Style will be applied later at the level of each Web page.

Determine Your Website’s Structure

Here are the key elements in planning a website’s structure.

Site Map

Your site map could be structured like a flow chart and built with software such as Visio or a free tool like Gliffy. Alternatively, you could create an outline with bulleted lists and indentations that indicate pages, sub-pages and other structural breaks.

Content Definition

Some content will be easy to define. A contact page, for example, is generally expected to include a business name, a location, contact information, hours (if applicable) and, often, a simple form. Other types of content require more consideration. This is another point when failing to carefully define the content will create headaches for you later on.

Perhaps you want to put a photo gallery on your website. Good idea, but what exactly will the gallery consist of? Will it be 20 images in a grid of thumbnails with a nice pop-up overlay when you click on one? Or a multi-page gallery with 1000 photos, individually categorized and tracked with meta data? Should users be able to rate the images? Comment on them? Download high-resolution versions? Email them to friends?

This is but one example of why defining each type of content is so important. If you don’t, then the developer will make their best guess as to what each type of content should be. Content elements like an event calendar, staff directory or blog might provide a general frame of reference, but they require clear direction: what exactly do they need to accomplish, and how will they be used?

One way to help define content is to simply observe the functionality of other websites and see what might suit your purpose.

Content Checklist

Here is a list (though not exhaustive) of common types of content. Remember, these are just types, not definitions:

• Articles;
• Blog;
• Banner advertising;
• Discussion forum;
• Documents;
• E-commerce;
• Forms for contact, quotes or something else;
• Physical products (how many?);
• Digital content (what kind and how many?);
• Email newsletter;
• Event calendar;
• Event registration;
• Image gallery;
• Link management (dozens or hundreds of links, ordered by category);
• Incoming RSS feeds (pulled from other websites);
• Outgoing RSS feeds (your content syndicated to other websites);
• Search;
• Social media sharing links (Twitter, Facebook, etc.);
• Staff directory.

Content Relationships

Some of your content will relate to other content. For example, the same details might appear on different pages of your website. Map these relationships carefully, and remember that when content is changed in one area of the website, it might need to be changed in other areas for consistency and accuracy.

Separating Design From Content

Design and content are intimately related, but they are also separate. This might be confusing at first. But it means that website content is completely free of design elements. To avoid speaking in hypotheticals, let’s consider a simple example. Let’s say your website has a set of articles. For each article, there is a:

• Title,
• Meta title,
• Meta description,
• Author,
• Date of publication,
• Category,
• Summary,
• Main text.

These pieces of information constitute a whole article. At this point in the process, it doesn’t matter what design you apply to the copy: fonts, layout, colors, author photo thumbnails, etc. The content is valid even in the absence of design. It may not look pretty in plain text, but it reads correctly.

This separation neatly suits Web Standards, a project that advocates for a set of standards for Web design that makes content accessible to the broadest possible range of people and devices.

Then, when it’s time next to redesign your website, you can easily apply an entirely new design to your existing content, because you’ve maintained the separation between content and design.

The Value Of Good Content And Meta Data

What Is Meta Data?

Meta data is content about your content. In the case of an article, everything other than the title and article text is considered meta data. When some people hear “meta data,” they immediately think, “Oh, that’s for search engines,” which is correct: search engines do rely on meta data to index Web pages effectively. However, you might want some meta data just for your own records, without displaying it.

When deciding what meta data to collect for each type of content, there is a benefit to collecting more data than needed. Still, you could collect a lot less than what we’ve listed above and still have a valid article. The bare minimum you need for something to qualify as an article is:

• Title,
• Author,
• Article text.

You might think that that is enough, or that you won’t have many articles, or that they’ll be short, or that the articles won’t need summaries, or that your visitors won’t care about date or categories. This might be true today, but what about next year? If you write good content, then it will be useful well into the future.

Collect Meta Data, Plan for the Future

Over time, the value of good meta data increases. If you have only 10 articles, then tracking authors and categories might not seem useful. In two years, though, when you’ve built up a library of 150, you’ll be glad you took the time to collect it. You will be able to sort by author, date and category. And because you’ve collected summaries, you’ll be able to make a version of your website for mobile devices, for which summaries are all that fit on the screen at once.

Wireframes

Once you’ve determined the structure of the content, you can move to the first step in the design process. Building wireframes mostly has to do with the layout aspect of Web design. They are done in grayscale and are designed not to be pretty but rather to show page layout. There are many great tools for this: Photoshop, Illustrator and Visio work well, as do specialized tools like Balsamiq.

The tendency of designers especially is to make things look appealing from the beginning of the process. But this should be avoided completely at the wireframing stage, because that would distract from the purpose of the wireframe, which is to decide where things should go, not what font size to use or what color the navigation should be.

Generally speaking, one wireframe should be made for each unique page on a website. If you have a page that offers downloads or photo galleries, mock it up as well. The examples that follow are for a home page and two internal pages, respectively.

Once the wireframes have gone through your review process, it’s time to move to the design stage.

The Value of Good Design

Consider the iPod. Apple has been wildly successful at selling products with exquisite and refined design (in terms of both the physical object and the user interface). The iPod doesn’t have any particular capabilities that its competitors lack. In fact, by some measures, it has fewer features than others. For example, it doesn’t record audio out of the box; you have to attach a piece of hardware to the iPod before it can do this. Nonetheless, the product’s exceptional industrial design and highly intuitive interface, combined with great marketing, make the iPod a far more coveted item than any competing product.

When it comes to websites, however, good design and attention to detail are often discounted. The reasoning is that if something works, it doesn’t need to be refined. This is misguided thinking. A website—along with a logo, business cards, signage, letterhead, direct mail and other visual expressions of a brand—critically affects the way customers perceive a business. The experience users have on your website is part of this impression. When a website is harmonious, pleasing to the eye and easy to navigate, visitors will leave with a positive impression. Conversely, when a website is just passable, it could annoy customers, leave a bad impression and discourage return visits. And, importantly, you likely won’t hear about it from them. The Web isn’t very old, but here’s a key question that has been relevant since the first business website went online: if a customer goes to a website to search for the specifications of a product that they know you sell and finds nothing, what will they do next?

They’ll leave. Typically, when users get frustrated, they don’t search any further, and they don’t call or email; they just leave the website. To get a sense of this, review your website visitor statistics (see the section below on bounce rates).

Still, these stats can’t tell you what a visitor was thinking when they left. And unless you’re selling something wonderful and unique, customers will probably go elsewhere to find a similar product or a different service provider.

Initial Design

The initial design, commonly created in Adobe Photoshop or Fireworks (and sometimes Adobe Illustrator), consists of visually accurate images (“mock-ups”) of the home page and at least one internal page. Your business’ visual branding elements should be included here. If you already have well-defined graphics in addition to a logo, they should dictate the design of the website. If your brand lacks these, then the designer should do their best to create work that accurately reflects the business.

Here is a short list of key points for successful mock-ups. We’ll assume that the designer is working in Photoshop, although these guidelines apply to other programs as well.

• Start with a pre-made template, with pre-drawn pixel-accurate guides. Some designers create their own, and others adhere to systems like the 960 Grid System. Whichever you start with, the template should be clean. Make the canvas wider than the width you’re designing to so that you can add notes on one side.
• Add the color palette and basic branding elements (e.g. fonts) in the margins of the canvas so that you have them for reference when viewing on screen or in print.
• Draw everything to exact pixels, and draw clear guides and slices around design elements. This becomes critical when you execute the design in HTML later.
• Organize all design elements with a logical folder or sub-folder structure, and label each item clearly. If the designer will be handing files off to an HTML specialist, this is especially important. “Sidebar events header” is clear; “Layer14 Copy” is not.
• Make clear notes about fonts, alignment, repeating background elements, gradients and anything else that will be implemented with CSS. Photoshop’s sticky-note feature can help with this. If something is unclear, ask the person who will be converting the design.
• If you’re using a common style for headers, navigation or other design elements that appear throughout the website, consider making separate templates for them. These will also come in handy later in the design process, once mock-ups have been approved.
• Use realistic content. Designers often use Lorem ipsum to fill space, which is okay for body copy. But for headlines, titles, events and so on, use real copy. Consider the two following headlines. The layout considerations would be different for each:
  • Widgets, Inc. Wins Green Manufacturing Award
  • Widgets, Inc. Employees Win Landmark Court Case Affirming Employee Right to Petition for College Tuition Reimbursement When Training Is Relevant to Work Role

Design Approval and Revisions

After you have submitted the initial mock-ups for approval, there could be a revision process where the designer and key stakeholders go back and forth a few times, trying a variety of edits until the design is approved.

Designing-by-Committee: Don’t Do It

Having to consider multiple opinions can be a problem at this stage. Some stakeholders might be quite vocal in critiquing the design but are absent later, when the time comes to put in solid hours sifting through content for the website. Certainly, soliciting feedback about each design is important, and project stakeholders have valuable criticism to offer; they help to guide the design process so that the result accurately represents their business. In some instances, legal or technical staff will need to review. However, giving equal consideration to all feedback might not satisfy anyone.

Generally speaking, in small businesses or organizations, allowing more than five people to provide design feedback creates gridlock. It would help if these five (or fewer) people solicited feedback from their subordinates or department colleagues, but this feedback should be compiled by each stakeholder. In other words, don’t invite 15 people to a design review meeting.

Design Tension: Designer vs. Client

There is often tension between trained designers and less-informed clients. This is best illustrated by the “bad idea” conundrum: the client requests a design feature that is ugly, unworkable or for some reason a bad idea. Entire websites are dedicated to chronicling the poor choices of clueless clients. The responses of designers usually fall somewhere between “That’s horrible, and we won’t do it” and “Well, if that’s what you want….”

The response should be based on a number of ever-shifting factors, including:

• When the designer hopes to get paid;
• How emotionally invested the designer is in the project;
• How much time the designer has invested in the design phase, and how long a delay would result from implementing the bad idea;
• The client’s willingness to hear constructive criticism of their ideas.

Every project is different. Designers who continually get requests from clients for ill-advised features are likely to write the project off at some point. It’s just too exhausting having to constantly explain why centered bold red paragraphs, crazy Flash animations or poor-quality photography make for an ineffective website. Their attitude shifts from “Let’s make something that we’re proud of” to “Let’s just get it done.” Designers don’t say this to clients, but it happens frequently.

Realize, also, that the work of some designers is not up to par. Perhaps they have refused to listen to valid criticism. Avoid this situation by inspecting their previous work.

Consider Content

Think about future expansion. For example, you might have a news section with six news items. You’ll have a main news page with summaries, each of which links to the full view of the item. This is fine. But what happens when you have 10, 20 or 50 news items? Now you have other considerations. Do you want to archive old news? Paginate the items? Show only the last 10 items? Consider these questions in the design process.

For websites that accumulate content, such as news, press releases and reports, there’s a good rule to follow when creating mock-ups: you can never have enough mock-ups. In other words, if you think the layout or design of a page or section of the website will differ significantly from other pages, then mocking it up is worthwhile. This step normally comes after the initial mock-ups are approved.

Web Style Guide

A style guide is where proper planning shines. A style guide determines and defines all the design, layout, interactive (i.e. JavaScript and Flash) and type elements used throughout the website. These include but are not limited to:

• Navigation styles;
• <h1> through <h5> (heading tags);
• Paragraphs;
• Lists;
• Block quotes;
• Italics, bolding and underlining;
• Links, including active, hover and visited states;
• Icons;
• Use of images and image style;
• Use of background images (watermarks);
• Common elements such as sidebars.

The mock-ups and style guide are the foundation of the next steps in development.

Integrating With Content Management System

At long last, your brilliant design has been converted to code and is ready to be integrated into a CMS. The individual or team tasked with doing this will provide you with log-in details for the CMS that allows you to add content, including text, photos, video and documents. Most editors prefer to cut and paste from Microsoft Word.

Depending on the specifics of the CMS, you might be able to do this easily and retain simple formatting like bold, italics and lists. Sometimes, though, the CMS will strip out the formatting when you cut and paste, and you’ll have to put it back. This can be tedious, but it ensures that your content remains neat and orderly and thus can be easily printed, cited, indexed by search engines and converted to other formats.

Putting It All Together

After following these steps, you should be sitting on a pretty solid website. Regardless of the size of the project, now is a good time to do the following:

• Review the content once again, and check it against the points listed under “Writing for the Web” above.
• Ask a third party to proofread all of your content. This is not the task of the designer or original writer. Bring in someone with a fresh perspective. Don’t proofread your own work.

Beta Testing and Launch

When you feel that the website is almost ready for the public to see, it’s time for beta testing. Go through this checklist (which is the bare minimum):

• The website looks correct in all targeted Web browsers. Web browsers include the usual Internet Explorer, Firefox and Safari, as well as (depending on the specifications) less common browsers like Chrome and mobile devices (iOS, BlackBerry, etc.);
• Interactive features work smoothly;
• Contact and other forms work predictably and send the correct information to the user and recipient(s);
• Internal and external links work;
• Images are sized properly;
• All placeholder content has been replaced by the final copy;
• Links from third-party software, such as email campaigns, work.

Once you’ve thoroughly beta-tested the website, launch it.

Post-Launch

After you’ve launched, maintain the website. Here are a few helpful tools for that.

Web Statistics

Visitor statistics provide insight into how people use your website. You’ll need at least a month or two of data to make any determinations. Here are a few questions to consider:

• Where are visitors coming from? See search engines, direct traffic (i.e. visitors who type your website’s URL directly into the address bar), ads, links from other websites, etc.
• Where do visitors live? Are they mostly local, regional, national or international?
• What pages are the most popular?
• How long are visitors staying on the website?
• What is the bounce rate? That is, how many users visit only one page on the website before leaving?

Google Analytics is one of the most commonly used Web statistics apps, and you will find answers to these questions in the high-level data it presents. Other software should provide these answers as well.

Documentation

Much of your documentation will consist simply of the different elements discussed earlier in this document, including wireframes and Photoshop documents. You’ll also need detailed notes on how various parts of the website are implemented in the CMS. Think about what information would be needed if you brought in new people to maintain the website, people who were not at all familiar with it. What would they require in order to pick up the project? This is what proper documentation is.

Back Up

Schedule regular back-ups of the website’s files and database. Daily is ideal. Your hosting company might provide an automated way of doing this, so that if your files or database get hacked, erased, corrupted or otherwise damaged, you can restore them with copies from the previous day. Depending on the size of the website, update frequency and some technical matters that vary from website to website, you could schedule more frequent back-ups.

Maintenance Plan

Your maintenance plan should clarify roles and responsibilities for every aspect of the website. For example, if two articles per week are to be posted, who is responsible for them, and who is that person’s back-up? If your website requires that photos or graphics be created regularly, make sure this work is assigned and understood. Decide who will check links.

Write a simple maintenance plan, and share it with everyone involved in the website’s care and development. Remember, a good website isn’t a one-time event, but rather an extensible communication tool that requires regular updates to stay valuable, relevant and compelling for visitors.

Solicit Visitor Feedback

A great way to improve the impact of a website is to solicit visitor feedback. There are a variety of ways to do this, from conducting simple online surveys to on-site focus groups. Website visitors often have trouble articulating what they like and don’t like about their experience. With this in mind, craft very clear and specific questions when soliciting feedback. And remember: if you’re going to take a significant amount of visitors’ time, offer something in return (a product discount, a prize or simply a handwritten thank-you note).

Conclusion

Okay, one more time: a good website isn’t a one-time event, but rather an extensible communications tool. Once you’ve built a great website, keep the momentum going. Devote resources to regular maintenance, and check in with visitors regularly to identify areas for improvement.

Mike Kroll supplied wireframes and design mock-ups. Susan Morris provided editing and proofreading.

(al) (sp)