When The Fat Lady Sings

It really ain’t over (aka “live”) until the “fat lady sings.”

All of the testing, research and design work in the world won’t help if a site never goes live. And as I “re-learned” the past month, there are many steps along the way that can make the “going live” process full of potholes.

In no particular order, here’s Kathy’s checklist to help ensure that the fat lady does sing!

1. Learn to say No. Sometimes.
There are many differences between “the Web” and “print,” and one of the most obvious is the lack of permanence associated with code. Changing an annual report or sales brochure after blueline isc ostly — both in dollars and time. Communications professionals who regularly work with print media understand this system constraint.

However, to impose such a restraint on the Web development process requires a special kind of discipline. In addition to the (obvious?) need for a well-defined scope document comes someone willing to drawa line in the sand and just say “No more changes!”

This boundary definition is not an easy one to make. It may be that after weeks of working with a design, one of the designers or programmers has an “ah-ha” moment that everyone knows will improve site usability or functionality. Do you implement it now, or wait until a new site version? Who makes the decision? How long do you take to make the decision? (Protracted decision processes could mean the coding change would have taken less time than needed to reach a decision.)

Here’s an example of a “last-minute” value-added change. The site is a major forest products company, and part of the site is devoted to land sales. Neither I nor the programmer with whom I was collaboratinghad spent a lot of time critiquing the artist concept of this section. Until we started coding it, that is.

The first thing we realized was that important information about the properties was “below the fold” for folks with 800×600 resolution. This didn’t seem to be a good idea, so we experimented with the layout to get that information “to the top.”

Together, we decided that this design change was important enough to improve site functionality that we developed a prototype and got client buy-off the next day.

Artist Concept	More Usable Design

However, we still weren’t happy. The plot had no context — where the heck was this plot of land (other than being somewhere in the US Rockies)? There was an image that showed all properties in a random numerical order; we had listed properties in alpha order in the body of the site. How to provide context in this situation?

We elected to provide a text link under each plot (opening in a new browser window, but not with a javascript command!) that featured the large property map. We then noted each property’s “map number” so that it would be easy to spot this plot in the bigger picture.

We felt this was important enough to add. And since it was our call, and did not negatively impact our ability to meet deadlines, we did it and did not charge the client for this extra bit of usability.

2. Remember Backups
I’d like the proverbial quarter for every time I’ve heard of a client deciding to get a new designer … and discovering that the prior designer did not ever deliver a permanent, digital, non-web server copy of the web site.

It seems so simple. In contract negotiations with any design firm, the client should specify that at the close of any phase of the project one of the deliverables is a copy of the full site. Preferably on CD-ROM (so it cannot be accidentally erased or changed).

This has the added benefit of acknowledging that web developmentand execution is a phased process!

As a developer, I make a backup of the existing site before starting to work on a redesign. At least I initiate the FTP process. I learned, much to my dismay, that on a recent project either their web server or my FTP client had a bit of “unhappiness.” But neither alerted me. So I did not make a complete set of one of the sub-directories.

Which, of course, is a reminder to double check each download and directory. (This detail work is not in my list of fun things to do.)

And if you’re the communications professional “in charge” of your corporate web site — be sure to ask your IT department to initiate a regular back-up of your web server (if internally hosted). The databases sitting all ’round your web server are undoubtably being backed up regularly, but it’s unlikely that a web server backup will be initiated without a specific request.

If your site is externally hosted, check your contract for backup promises. And confirm. Having a complete backup is essential if, after cutting over to a new design, someone decides that the old design was “okay” after all. And wants it reimplemented. Now.

3. Consider Print-Outs
Go ahead and groan. I hear the objection: “But the Web is an electronic medium! Why should we proof from print-outs?”

For the very same reason that we preach “skim-ability” and “information chunking” in Web site design. Reading online is hard on the eyes. Finding inconsistencies in design requires a lot of page-balancing in one’s head. Finding grammatical or spelling errors is at least an order-of-magnitude easier from a print-out.

Yes, a print-out can give a false sense of “this is how our site looks.” Colors on paper don’t match those on a laptop or standard monitor. There’s the omnipresent platform difference in fonts (faces, size, styles).

Despite these obvious drawbacks, a print-out of a medium sized site (I certainly wouldn’t want to do this for a 1,000 page site, for example, although I might want to print down to three levels) will help all concerned with final publishing: the designer, the programmer, and the client.

4. Know the Chain of Command
Otherwise known as “who are the show-stoppers?”

In just about every project, there comes a time when the project lead says “this [problem/aggravation/change] isn’t a show-stopper. Let’s correct it in the next version of the site.”

But do you know who the show-stoppers are on the management team? It’s important to keep all decision makers in the loop; the size of this loop depends on each corporate environment. Managing the loop is usually reserved for the project manager – but that person may be internal or external (or part of staff augmentation).

Who are they? When do they want final sign off? Do you need morethan a verbal “go-head”? If they decide at the last minute that there’s “a problem” — do you have any other recourse or is this the ultimate gatekeeper? It’s possible that something deemed “minor” (not ashow-stopper) by the project manager may not be perceived as such by a higher-up.

A key to everyone’s sanity (as well as that celebratory glassof champagne) is ID-ing these folks before the day before (or after!) cut-over.

Bottom Line
This is not a complete guide to Web site project management, but keeping these guidelines in mind will make it more likely that the fat lady will sing for your project — and on your timeline.

Referenced URLs