A Comprehensive Website Planning Guide

Advertisement

As a veteran designer, developer and project manager for more websites than I can count, I’ve identified a common problem with many Web projects: failure to plan. The same issues come up repeatedly in my work, so I’ve written this guide in order to help clients, other designers, businesses and organizations plan and realize successful websites.

This guide is written in relatively non-technical language and provides a broad overview of the process of developing a website, from the initial needs assessment through the launch, maintenance and follow-up. It is appropriate for:

  • Small and medium-sized businesses;
  • Organizations;
  • Institutions;
  • Web designers, developers, and design and development firms.

If you’re building a four-page website for your family reunion or a 5000-page website for a Fortune 500 company, then this guide might not be for you; it will either be too detailed or way too short, respectively.

image of QandA letters
Important questions and answers. Image by opensourceway

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

The way to success.
Be sure to plan your way to success. Image by opensourceway

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.

Seeing and doing.
See what is relevant and react. Image by opensourceway

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.

To compete and collaborate.
Clear the fronts and distribute clear responsibilities. Image by opensourceway

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.

Structure your content.
Structure your content. Image by opensourceway

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.

You can wireframe anything.
You can wireframe anything. Image by opensourceway

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.

Where does good design start?
Where does good design start? Image by opensourceway

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.

Make sure everything fits in.
Make sure everything fits in. Image by opensourceway

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.

Download a Free PDF Copy

You can download an even more detailed PDF version of Ben’s project planning guide after a quick registration on his agency’s site.

(al) (sp)

↑ Back to top

Ben Seigel is the Principal of Versa Studio, a Web design and development firm in Madison, Wisconsin.

  1. 1

    excellent focus… As usual! Congratulations for the comprehensive guide.

    6
  2. 2

    Well done… But I will love the detailed website designing from scratch to final. All this guidelines should be applied :)

    0
  3. 4

    Especially enjoyed the comment in the source code:

    INSERT IMAGE HERE: website-planning-from-versa-studio_img_0.jpg

    That aside, good overview of the process, but as hinted at in the article, every client needs a tailored plan depending on their needs.
    Good to dee the heaviest focus going onto content management.

    -1
  4. 6

    Carlos Almeida

    June 9, 2011 5:09 am

    5* , Totally true… A good Plan is always half way to succeed in all the ways.. nice work ;)

    1
  5. 7

    And the wireframing stuff ? No ? Before the design stuff maybe..

    4
  6. 9

    Excellent article, but didn’t see any mention of usability testing.

    0
  7. 10

    Brilliant! Well done! I’ll be adding this to my library!

    -2
  8. 11

    As an Agile designer/developer this article made me cringe. Not once is there any mention of user acceptance testing before going to Beta.

    Working for a large enterprise on ecommerce applications, I know only too well how business analysts and project managers want the requirements nailed down to the tiniest detail from the start. The most difficult part of any large-scale project is – I believe – educating BAs and PMs in the ways of Agile development.

    The one thing that never fails to surprise and, ultimately embarass them, is the fact that UAT doesn’t come at the END of a project. It’s an ongoing task, part of the agile development lifecycle and will always, ALWAYS result in changes in requirements, design, and content.

    While there is no denying the importance of any of the tasks you’ve mentioned above, I feel you’ve left out one of the most critical aspects of rolling out large-scale solutions to a potentially global audience: test, test and test again!

    10
    • 12

      It sounds like the type of project you’re referencing, and they types of projects that Ben is referencing are completely different circumstances which require different methodologies. Waterfall works well for small to mid-sized projects with limited budget and proper planning. Agile works well for massive projects that would otherwise be difficult to scope, and have the budget to implement rounds and rounds of changes.

      In either case you need a good team and that’s what produces quality work regardless of what methodology they use.

      7
    • 13

      Though I enjoyed the article I’ve got to agree with you Missy, all the planning in the world isn’t going to validate if what you believe is the same as your users and if not, how to move in the right direction.

      Rarely do users see a web application in the same light as the organisation/development team and ultimately it’s their opinion that make something successful, or not.

      -1
    • 14

      Well said Missy.

      -1
  9. 15

    It’s a bit unclear to me but I came to believe that you’re embracing a waterfall method of site development. Even in smaller teams working on smaller business sites the waterfall method inherently causes issues.

    As Missy hinted at, an iterative process in agile development often makes more sense. But, you do need a team to accomplish that; so for freelancers, or very small businesses perhaps it does not.

    I recognize that this article is aimed at small to medium sized businesses. And, it serves as a good stepping point for those who do not know about building a website or application to educate themselves on what to expect. I just wanted to reiterate that there are many, many other ways to tackle the build process and educating yourself on those will help you avoid many of the “headaches” mentioned in the article.

    3
    • 16

      Andrea at ProtoShare

      June 10, 2011 8:26 am

      I agree with @Missy and @Michael Neil. An iterative process can define better requirements at the front of the development process, thereby saving expensive rework after the development stage. Just as described in the deck example.

      Pure Agile development may not be ideal for small companies or small projects, but incorporating some rounds of iteration through prototyping can make a huge difference. Oftentimes wireframes are not enough. Clients can see where you plan to place elements on a page, but it doesn’t mean they understand all of the interactions.

      Even on a small budget, you can add some interactivity to elements that are likely to cause confusion, make the pages link together, and invite the client (or even end-users) in to experience the prototype, and provide feedback. This way, you know they understand what you intend to build, can make necessary adjustments, and save the relationship before it’s too late. Trying to throw change orders and sign off pages to clients after development is near completion is not the ideal experience.

      I realize you can’t predict everything that will happen in a development process, especially on small budgets, but you can find medium ground to achieve both sides’ goals, and at a reasonable cost.

      0
      • 17

        Many of the steps within the guide (and some that were not included, like usability testing and security) will be modified depending on the size of the project. The guide represents, for my development approach, something close to an ideal. In some cases, there may simply not be enough time and resources to cover everything.

        My objection to the waterfall method stems from reading RFPs (Request for Proposal), project charters and SOWs (Statement of Work) which attempt to specify everything in advance, in great detail. This doesn’t work well for web sites, as they are dynamic by nature. One has to find a compromise between specifications and flexibility.

        0
  10. 18

    One of the most interesting articles SM has published recently.

    Thank you.

    0
  11. 19

    What a wonderful article, thanks!

    But I do have a slight problem with “less common browsers like Chrome and mobile devices.”

    I guess that’s just a line left in from some quite old version of the article? :-)

    I know it’s just a very minimal detail, but if people will start using this as their template for new projects, they might believe that line too!

    -1
    • 20

      Compared to Internet Explorer’s market share, Chrome and iOS have much lower adoption rates. You don’t have to believe me either. http://gs.statcounter.com/

      -1
      • 21

        Of course, but as stats clearly show, Chrome is the third most used browser and that sentence simply looks odd, considering that Safari seems more “important” there. And that was surely true a couple of years ago, that’s why I wonder if that’s just a leftover of something older.

        0
  12. 22

    Hi, I am new in the webdesign area and I would like to know what do you mean by CMS… do you mean to put the website inside WordPress or Joomla so the client can manage the content?
    Tks

    -1
  13. 24

    Thanks for posting this. There is always something new to learn. And, I couldn’t agree more regarding “… keeping the momentum going” with websites.

    -1
  14. 25

    This is great in theory but there has to be some middle ground when discussing web design. I’m sure we are the only people in the world who’s clients don’t pay attention when the planning happens.

    I have been working on projects way past planning and wireframes , well in to development when I have been given something that the clients wants to mimic in functionality. It ruined the project and when we came in over budget and still didn’t have a good polished result, we got blamed and axed.

    I can pull out my scope agreement and shake my fist at them.. but who wins when I do that? Not me. It good to have defined terms but its just as good to be flexible. Its a hard thing to balance sometimes.

    0
    • 26

      And that’s why you need a change process defined. If a client has signed off on a feature set and design there needs to be some way that they can ask for changes and that way needs to accomodate the impact in schedule and cost terms. Clients need to realize that they can’t drop in a feature midway through with zero impact. We need to realize that clients might have a legitimate reason to alter something or to add something. Define how that gets done upfront and make sure people know about it.

      -1
      • 27

        No matter how many times I told them it was a very very bad ideal and that we would lose 2 months of progress to implement their new features… they didn’t care. Hater’s gonna hate… Clients gonna make changes… and worse… Some clients are never going to be happy. Its something every young designer must learn.

        0
  15. 28

    Great article !

    0
  16. 29

    Great article Ben ! Not just my opinion either – I got 6 RTs on this today – the most I’ve ever gotten on a single article :)

    -2
  17. 30

    As part of the plan, ought not addressing security risks are also important for any public-facing website, especially those with Content Management System? Would it be prudent to conduct a website security and vulnerabilities scan (using automated tool like IBM Appscan) as well?

    1
  18. 31

    A good plan is critical to the success of any project. Especially one with so many variables as a web site.
    However your planning methodology sounds like it adds thousands of dollars to every project. You are clearly spending far too much time on this.
    You also forgot several aspects of a web site, like SEO and security. And avoid the waterfall like the plauge man, get agile or get left behind.

    Your article was long winded , rambling and left out things that it mentioned that it would include. Is this how your web projects go too?

    -3
    • 32

      @all: Thanks for the great comments.

      @texxs: You are partially correct. Proper planning will add cost and time to a project. However, as I pointed out in the guide, failure to plan can add cost and time too, but also headaches, aggravation and missed deadlines.

      The guide is not intended to be all-encompassing, indeed, SEO and security are important aspects too.

      1
  19. 33

    I read the section “The Value of Good Photography” and had to share this about a project. A “professional” photographer came and took pictures of the building and staff to put on the website.

    The photography arrived 2 days before the project was meant to go live. The pictures were poorly framed and badly lit, the focus was even pretty poor on a number of the staff photos (an not in a soft focus kind of way, simply bad!). I certainly cannot claim any level of photography skills and my tool on the day was a camera phone. Suffice to say I am pretty sure those shots I took on my phone are still on the website.

    Sometimes a professional photographer can be worse than your average joe…

    1
    • 34

      in that case you’ll have to introduce an ‘UN’ before describing that photographer that is unprofessional photographer.

      0
  20. 35

    What – no usability testing at all? Really??

    0
  21. 36

    A very good guide, many thanks. But usability testing is essential before and after launch – even if it’s three people you’ll get a sound idea about where the site is going wrong. Then improve and iterate, improve, iterate…

    1
  22. 38

    nice attempt but hardly “comprehensive”. No mention of SEO, usability testing, social media integration, the preparation of a proper project specification, milestones for client approval & commitments, timeline………

    -1
  23. 39

    This is a wonderful summary. Thank you for putting it together!

    -1
  24. 40

    Having read through the comments, I want to know specific (and well-known url please) examples of where Agile development was used as opposed to a variation on the waterfall method. It seems to me, as a designer, that the Waterfall approach parallels a designer’s way of working; agile more like a programmer’s.

    -2
    • 41

      In large projects, and we’re talking several months to a couple years, do you think a designer can be given specs of an entire site and have it laid out in the course of a week or even a month? If given 6 months to design a network of sites, each consisting of hundreds of pages, wouldn’t a designer or team of designers benefit from daily or at least weekly meetings? And, wouldn’t it be even more beneficial, when designing interaction, that the designers meet with developers to go over aspects of the processes; and maybe even see it in action?

      Since design handles the end users control they are responsible for laying out many of the aspects of a project developers like myself must develop. The agile method allows that, while sometimes brief, needed interaction between designers and developers to make sure projects work smoothly. These changes then get relayed to a client much faster than if the designer were to lay it all out over the course of a month or two and then have the developer try to build the application.

      If the developer must change something drastic it will likely coincide with some key design aspect be it form input, navigation, or some other aspect of the project and the designer will almost always have to rebuild their comps. Also, in large projects development and design are worked on in parallel. You can’t wait for one to end for the other to start. Aspects of the data model and package construction can easily be managed by developers without the need for a design or designer while the view or output will always require some level of design in the visual sense.

      Once again this article is for small and medium projects; as the author stated. And so in this case I may be over doing it here. But, even in medium sized applications developed over the course of a month or two agile development processes work well.

      In short, agile development processes absolutely work with designers. And from experience many applications role out using this technique within all departments of a project. See particularly the SCRUM method.

      0
  25. 42

    I’ve only skimmed through the article and can already tell that it focuses on key points I try to get across at work all the time. Content is so important to planning out a web design, but sometimes I find myself having to design a site without any kind of content, which then leads to the headaches and frustration I saw mentioned. Content and planning is KEY.

    0
  26. 43

    Speaking of efficiency, this article could have been written in about a quarter of its length.

    0
  27. 44

    very good. we’re doing same way you explained in this article.

    -1
  28. 45

    goog job!

    -1
  29. 46

    Great post, but I agree with some earlier quotes. Usability testing and an SEO strategy should be included.

    0
  30. 47

    Thank you! Very helpful article.

    0
  31. 48

    A real good job!
    Thanks

    0
  32. 49

    but the PDF download from your website doesn’t work :-(

    -1
  33. 50

    Simply Brilliant! I’m going to adapt this for my freelancing.

    0
  34. 51

    This was such a helpful article! Websites have a tendency of turning into elaborate projects.

    0
  35. 52

    A very good article Ben, I agree with all you points regarding planning. I think planning outlines expectation of all parties involved. One thing I always do at the start of a project (usually in Gant chart format) is outline each stage of the process where the client is involved. This gives the client a clear indication of when they need to be involved, this also provides a safety net if they fail to deliver. This also helps when reviewing budget, usually projects slip behind because of external reasons – by making your client aware of the cost implications in running over they will be more willing to deliver on time.

    0
  36. 53

    Thank you for this useful article. I will use it as a reference, and to make the process of building a website visible to my clients.

    0
  37. 54

    Fantastic guide to creating a successful web project. Sometimes I feel like the amount of detail we put to pre production can seem a little over-kill, and although you can’t account for absolutely everything this article shows how much time should go in to the planning and how most never account for the information correctly. Great job!

    1
  38. 55

    This really is an awesome guide. I have been managing Web Projects for over 10 years now and this surely sums up everything very nicely and precisely.

    0
  39. 56

    Very Usefull and informative article, this will help me planing my websites…

    0
  40. 57

    Well, I didn’t like this article at all, total waste of time.
    Made long on purpose to look good probably, but then again, articles on Smashing Mag are generally too long for their own good. For the example the carpender example… really, now…

    Then it is full of non-information or mistakes.
    HTML Coder does not include Flash.
    You want to make the content more appealing with PDF files? Interesting.
    Images AND photos put 4-5 list items apart? Cool.
    I’d say more, but that’s where I stopped reading.

    Sorry.

    -4
  41. 58

    Oh, my eyes – that was a long read. I need to sleep to digest what I learned, now.

    -4
  42. 59

    Thought the article was great….really well done. Anyone that designs, builds and sells sites should follow this process. What would be of GREAT benefit is if clients could read this so that they are educated buyers.

    I don’t need to know how to build a car but if I’m going drop $30,000 I would surely do my homework and gain a better understanding of what would be good things to consider including in my purchase.

    1
  43. 60

    Great job! I have been designing and building websites for years now. But, this article has definitely inspired me to get more organized and to fine tune my own workflow. Thank you so much!

    1
  44. 61

    Energy medicine is a vast unlimited study of healing the human body through the knowledge of disease and healing through the application of very specific energies in very specific ways.Disease is almost always caused by blockages in the body. The body is meant to be an open and flowing energy system. It is these blockages that cause all physical, mental and spiritual disease. from the subtle to the dense ranges.

    -9
  45. 62

    hey I filled the form and I don´t get an email with the instructions for downloading, any other download source? thx

    -1
  46. 63

    Awesome guide! Thanks for taking the time to write this!

    0
  47. 64

    Thought this was great. I think you should cite Steve Krug (write your content. Cut it in half. Cut it in half again) and others with whom you’ve developed some of your ideas.

    2
  48. 65

    Hesham Abdel Rahman

    March 15, 2013 3:21 pm

    Excellent work,
    one of the best I read lately. Well done!

    1
  49. 66

    Very comprehensive look at project planning for a web site. One good way to ensure that you’re going to be successful with your web project is to use a good project plan. I’ve created a free microsoft excel project planning tool and a free sample web project plan that is available freely for download from my blog at http://www.mlynn.org/2013/04/web-site-design-project-plan-free-project-template/

    0
  50. 67

    I know this is a bit of an oldie, but it’s still a goodie. Would you mind fixing the broken images please? Thanks Smashing Mag

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top