advergirl: Get Interactive: 10 things you'll be glad you thought of

Sometimes interactive projects dramatically dissolve into mayhem. More often, they get tripped up on little goofs that are quickly blown way out of proportion. From my years of experience fielding late night / early morning irate phone calls (from clients and colleagues alike), I share with you 10 things you'll be glad you thought of:

Understand your client's technology environment. Not the servers. The desktops. Find out what browser? What version? What plug ins? What internet connection? And test the heck out of the site in that environment. In most cases, if the site doesn't work at HQ, your clients will assume it doesn't work anywhere.

If the site is complex, consider creating a content strategy. Start with the site map that you probably already have handy. Then sketch out all the raw content you'll need by page. (For example, newsletter signup page - sample newsletter, privacy policy, etc.)

Then, importantly, assign a name to each bucket of content. Not a writer. A content source. Who is in charge of tracking down all the white papers? The policies? The product lists? The prices?

Tip: Think about what questions people will have on each page and use the content list to answer them.

Change of address plan: If the new site will be on a new server or in a new hosting environment, put a plan in place early for transferring the DNS and make sure you set expectations on the move. Let me explain the relevant terms:
- A domain name is an easy way for people to get to a site - it's the "www." handle. Think: www.advergirl.com
- The DNS (or domain name system) is basically the yellow pages of the Internet. It translates that friendly domain name into an IP address
- An IP address is - simply put - a number-based computer address. Think: 172.31.255.255
If you do move to a new server, you need to update that record in the yellow pages (i.e. update the DNS). This process can be a bear because you have to find the original records for the domain name ... where it was purchased, who has the rights to change it, etc. AND it takes up to 72 hours (usually 24) to "propagate" across the Internet. That means it takes that long to update all the local yellow pages. So, some people will see the new site right away (if their local yellow pages are updated first) and other people may not see it until days later. Oh, and, love this - there's no way to control that.

Think about search terms early. Make lists of how you want people to find you. Think of other ways they might express those same ideas. If you're working with Google on advertising, ask them for similar search terms. Go long. Then cull down.

Get to 15-25 words that are important to the identity of the Web site. Lay them out like a tag cloud so that you can see which are most important.

Once you get the client's buyin, arm your writer, your programmer, your Flash guru and your designers with the list. The writer will prioritize those terms in headlines and top-of-the-fold content, the programmer in code and tags, the designers in image names, etc.

Trust me: It's a royal pain to retrofit later

Look for hardcoded links. One of the trickiest things to find when testing in a staging environment is hardcoded links. The ones that point to a specific server in the development environment rather than just agnostically referring to whatever computer they might be on.

Two ways to catch them. Ideally: test the entire site in the live environment before you do #3 above. Or: Ask the programmers to run a painstaking search for the URL of the server they're working on. It should never appear in the code.

Understand your client's compliance obligations. Retail has to be ADA compliant. Most university's are W3C. Regardless of the protocol, it impacts everything from the timeline to the budget. Better to know upfront than hack it in later.

Set aside hours and budget for production graphics. Just because the main site design is approved doesn't mean there isn't tons of design work ahead. Headers, extensions, icons, you name it. Rolling that design out to every page and every application will create a library of JPGs. Make sure there's time to create them.

Ask your programmers to document their logic in the code. This one's about a pesky little thing called turnover. Either within your own staff or of the files to the client.

Remember me mentioning how programmers are some of the most creative people you'll ever meet? Well, that's because they're writers and innovators in complex foreign languages. And, if you think art directors are a little confrontation about the 'right' way to do something, just put a couple of these tigers in a room together.

The purpose of adding notes to the code is so that another person - at a completely separate time - can go back and understand the storyline. Can pick up where the first writer left off.

Test the goal, not just the path. A very cool user experience chic I know tells a great story about how everyone was sure this consumer financial app worked perfectly. Lots of people used it. Completed transactions. Didn't complain.

Well, a few people thought it was confusing and went so far as to head out into the field with video cameras and the street addresses of a few willing customers.

Once inside, these ad hoc ethnographers gave the customers a list of transactions to complete online. Each completed them and thought they were correct. EVERY SINGLE ONE OF THEM DID IT WRONG. Screwed up their own accounts.

Use in-person (even make-it-work testing with others in your agency) to make sure that users can not only blissful nav around working pages, but also successfully complete the available tasks.

Last one. Make a cheat sheet for you and your client. The logins to admin tools, reporting, etc. PLUS a tree of emergency contacts and the protocol and response time you've agreed to. Nothing - nothing - will escalate error to emergency faster than a desperate client unable to get in contact with the people who can solve her problem.