Site Planning, the Red-Headed Stepchild of the Web

In: Articles

By Ben Henick

Published on June 20, 2001

The Audience Is the End… What About the Beginning?

This month’s issue of Digital Web drives home two points:

1. Keep it simple, stupid.
2. It’s the audience, stupid.

The point to this tutorial is not to reinforce these messages in the same style that you see in the rest of the issue. Had I wanted to do that, I could have written about UI design, white space, or “ommitting needless words.”

Those are easy.

What hasn’t been addressed is the greater challenge: the effective planning of a site.

To many, planning is not an alien task. Engineers plan; surveyors sight. Officers plan; soldiers fight. Editors plan; writers write.

Designers, however, are in a bind. The job of a designer is to be both creative and effective, but inspiration rarely crosses the sights of a mind mired in anklebiting details.

The dilemma is that if your process is simple and free of details, the audience will be confronted with a site that’s riddled with details and obstacles.

The sooner you prepare for the details, the sooner you can go back to the cocoon of your creativity. Done properly, a project plan will vastly simplify the task of getting the site launched.

This article is meant to serve as a resource for considering the likely details, and building a site from them that is simple for the user.

Many if not all of the questions asked below will look extremely familiar. However, you need to answer for yourself whether or not you sincerely ask these questions for every project—and apply the answers to your work. If you are not sincere about asking these questions and coming up with the answers, the visitors you’re hoping for won’t be sincere about using the site.

Where Are They Going? Where Should We Go?

Who is the audience, anyway?

What we are usually told is that every user is unique in regard to their goals for visiting a site, that classifying users is the first step on the journey to disaster.

We can, however, make a valuable generalization:

When someone visits a web site, they’re looking for one of three things: information, entertainment, or services. [From “The Balkanization of the Web” by David Siegel]

These classifications can be used as follows:

• A seeker of information is looking for something specific, and will look for it until they arrive at a state of success (or failure).
• Those looking to be entertained have an expectation rather than a goal, and will continue to browse a site as long as their expectation is met.
• A visitor in need of services (with which we can include goods) needs to be pointed directly to the object of their activity.

These user objectives will affect your planning, according to the audience and objectives of the site.

For example, I was asked earlier this year to put in a bid for a site redesign; the prospective client was a marine hardware design company. My first question was, “Is this site intended for builders, masters, or all potential purchasers of your products?” Builders would give information the highest priority; on the other hand masters would be seeking to buy products, thus the service provided by the site would take on the highest importance.

Once you’ve established these priorities, you’ll know your “boundaries” as they are applied to the design process. If you stay within them, the result will be a simpler project for you, and more importantly, a site that’s easier to use.

You Think You Know What They Want… How Will They Get It?

Once the goals of the audience can be classified according to the preceding list, it becomes necessary to obtain or hypothesize demographics that will point to aesthetics and a browser baseline. What follow are light examinations of a few specific cases.

Is it a government or non-profit site? You might want to consider a traditional two-column layout with a small number of colors, designed to be rendered by as many browsers as possible, and with great attention paid to bandwidth.

Is it an e-commerce site? The highest contrast should be placed on product photos, and DHTML might be a good idea if it adds function to the site’s user interface… depending on the goods being purchased (for example, electronics equipment). If you’re going to include a lot of high-bandwidth files, you’d better make it worth the visitor’s time by ensuring that they contain content that will assist the user in achieving their objective in visiting the site.

Is it an archive of music or animation? There’s an excellent chance that you’ll be able to design for version 5+ browsers, since multimedia hounds tend to be power users or college students. However, you’ll need to make sure that the linked files are easy to find. How you do that is up to you, whether it’s through a powerful search tool, breadcrumb trails, or a flat information architecture that provides lots of information at one “bite.”

Regardless of the audience and objective of a site, it will demand a particular approach to layout, graphic design, and information architecture.

Which approach is best for your circumstances? This question is best answered through some sort of testing, or perhaps the assembly of a focus group. If you apply common sense to some initial designs and show them to a possible member of your target audience, the information gained through that single inquiry will likely be priceless. This step will most likely be taken after you’ve won a contract, but it should be taken at the earliest practical stage in the project.

What Does Everybody Need?

Now that you’ve gotten some feedback on the things likely to attract and keep an audience, you need to think about the project from your side of the house.

Are you thinking of creating presentations or other content that will require special software? If you’re thinking of using content that requires a plug-in, you’ll need to devise an incentive for people to download it (if they don’t already have it). If the content requires something that’s ubiquitous, such as QuickTime or Flash, you’ll need to provide low-bandwidth substitutes for your content. If it’s a Flash presentation, you’ll need to pay special attention to usability.

Perhaps you need special software to execute the project, like a content-management system or a multimedia development package. Your decision to implement a specific tool should be made after you’ve done some research; it’ll save you a lot of embarassment before the project launches.

Do you need a budget for stock photography or illustration? This is a question that needs to be approached from a number of angles. In most cases, you won’t need a lot of pieces because too much art in the presentation will make for unnecessary clutter (unless it’s an art site, of course). The corollary to this question is that illustration and photography, if needed, should be obtained from professional sources whenever possible.

What about the server? You should be sure that the hosting provider has reliable connections to their backbone, and that they’ll give your site the bandwidth it needs without charging your client more than they can afford.

Early in the process, you’ll also want to make sure that the server has an operating system that you’re okay with. I personally have been the victim of a move to a host made before this was done, and I can tell you that it’s not a pleasant outcome.

In the event that you’ve promised features for which you cannot guarantee delivery, have you lined up vendors to do the work? Don’t give me that look. It’s no secret that the upbeat, can-do attitude will always win the contract—even if that attitude was a total lie. Of course, you’ll breathe a lot easier if you know who’s going to pinch hit for you before you make your pitch.

When you’re still in the process of trying to win a contract or an approval, don’t forget the two things that your client is going to need:

• Education is not a degree or certification, but rather a dialogue in which the client gains an understanding of what you’re doing to finish the project. This helps them know that they’re getting heir money’s worth. Not all clients insist upon this, and some of them don’t want to be bothered with this… but where a need for education appears to exist, it should be satisfied.
• Scope explains all of the deliverables in the project, and their ownership – which may belong to you, one of the vendors you’ve chosen, or the client.

Do you have any idea of how you’re going to educate your client and describe the scope of the project?

Once you’re confident that your client is comfortable with how the project is going to proceed, you’ll need to get the answers to some detailed questions.

What is the nature and extent of the content? You need to know this in advance because it will help to establish some rules as to when content becomes outdated. Knowing the answer to this question will also help you in preparing a design—for example, would you design an underwater photography site with predominantly warm colors? (I doubt it.)

Does the content lend itself easily to a database? There are few tasks more daunting than assembling lots of little bits of content into a finished site, especially if you have to keep those bits of content apart. On the other hand, if the site is a set-piece project that isn’t likely to change, it will probably be more trouble than it’s worth to connect it to a database.

What are the client’s maintenance requirements going to be, once the site is launched? If nothing else, knowing the answer to this question in advance will help to cushion any disappointment you may feel from their decision. On a more practical level, it’s sure to affect your entire approach to building the site. For example, knowing that a client intends to maintain a site in-house with the help of FrontPage will allow you to create a design that won’t get mangled on the first attempt at maintenance.

Of course, as we all point out, the web is a fantastic marketing tool because it’s always on. This rather begs the question:

How does the site you’re building fit into your client’s marketing plan? If it’s a “tight fit,” you’ll probably want information on the colors and artwork they’ve used in their printed material, so that you can ensure that the site is a seamless part of the plan.

You’ve Got the Power of Knowledge, But Do Know How To Use It?

Now you’re at a point where you have all the tools and information you need, and your client is satisfied that you’re doing a great job. Now, you’ve got to answer the questions that will make for a smooth design and production process.

Have you decided exactly which technologies you’re going to employ? Is it ASP, ColdFusion, PHP, or JSP? Which server software is actually going to run the site? Which plug-ins are you going to require? Because you took an inventory of your resources and vendors beforehand, it’ll take you two seconds to make this decision… right?

Do your chosen technologies play to the strengths of the people who are going to build the site? If not, you will need to be as conservative as you can when it comes to deadlines. The same rule applies if you are juggling a lot of projects… let’s face it, you’re only human.

If you’re using dynamic scripting such as PHP or ColdFusion, do you have an idea of how the scripts you write are going to work by themselves, and together? No, don’t figure it out as you go along, unless you’ve got the time to spend and the money to burn.

Have you sketched out designs that will lend themselves to easy changes? The reason I ask this, is because you need to allow in most cases for the possiblity that the client may want to see something added to the site at some point. It’s much easier to implement such changes if you don’t have to re-write your page templates from scratch.

If you’ve got an “enthusiastic” client, have you recommended a second phase to the development of the site? It’s either that, or feature creep. The latter of the two will more often make for useless “stuff” that serves little purpose. If you need the money that badly no one can stop you from letting the features creep all over the place… but if you do, you’re likely to regret your decision later.

There is also the matter of contingency planning.

Have you taken practical steps to ensure that the site will have superb uptime? This means that it’s connected to a network that’s well-monitored and sitting behind an effective firewall. Your server needs an uninterruptible power supply (or UPS). Your hosting provider or collocation facility should have generators to keep all of their servers running, with plenty of fuel on hand. This last measure is only as critical as the site’s role in your client’s business, but if you take the steps to make it available, you’ll usually have a grateful client.

Have you come up with a “Plan B” in the event that your registrar goofs up your domain name? Keep in mind that problems like that can drag on for months; perhaps you should register a second domain, with another registrar, that you can advertise on short notice.

Wait! Don’t Jump the Gun!

You’ve got a timeline, and the pieces are in place. Now it’s time to sketch out the various pieces of the project, so that you can do the actual sitebuilding in the knowledge that those pieces will fit together properly.

Mockups of the site’s presentation and architecture consitute one part. When you create these mockups, you have the opportunity to ensure that the colors look right, that there will be a home for all of the site content, and that the client will be happy… all before you’ve written a single line of markup and code.

Pseudocode of the scripts on both the server and client will create the opportunity to spot compatibility issues before they become bugs, and make it possible to walk through user-experience scenarios as you intend them… to see if they will actually happen in the way that you intend.

The database schema needs to be developed in tandem with pseudocode, so that you don’t wind up with orphaned code or database calls that are excessively resource-intensive. Creating schemae also makes it possible to assess the information that’s traveling between the user and the site, so that any shortfalls can be amended before you run the risk of having to push back deadlines.

Internal testing of the system that results from these designs will likely catch more problems before they turn into emergencies. The question you should never forget is:

What if the user does something unexpected?

Roll ‘Em, Cowboy!

Phew. You’ve planned everything.

Or have you?

Are time and facilities going to be available for usability testing of the site’s user interface? Shopping your mockups around is a good idea, but it can’t beat the insights gained from watching people actually use what you’ve built. One tester is 100% better than zero testers, and a small group of four to six testers will usually manage to uncover most of the site’s usability problems.[1] If done with working application (server-side) code, this testing will also alert you to the risk of excessive resource usage on both client and server.

Have you set “freeze dates” for development on various parts of the site? A “freeze date” is a point past which development needs to be approved, and cannot be changed. For complex projects, these are essential as a tool to prevent feature creep.

Will all of your scripts have adequate comments and documentation? The fact that you built the site, doesn’t mean that you will always be the one to maintain it. If you are certain that maintenance will be passed off to other parties, it’s also a good idea to write a short manual of sorts explaining how all of your code and markup works, as a system.

Is a style guide going to be written? If not, the maintenance and “natural growth” of the site will rapidly grow out of control.

Aaaaaahhhhhh….

Have all of these questions been answered?

They have? Good. Now you can start building your live markup and images. You can see to the writing of your server-side scripting, and you can do it all with a feeling of security… at least, more security than you would have felt, had you just jumped right in and started writing markup and code from the very beginning.

The point to this parade of questions is not to make the development process inherently simple. Instead, it removes the obstacles that are likely to be placed in your path, especially if you’re working on a complex project.

In so doing you’ll be able—with practice—to simplify your job by making things simpler for your users.

Isn’t life simpler when you’re not besieged by crises, anyway?

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Planning, Information Design