The final countdown
For things to go horribly wrong it often takes only a single point of failure. More often than not, however, when things go wrong there is a cascading effect of multiple points of failure. It is said that the most dangerous moments for an aircraft are takeoff and landing. The most dangerous moments for a website is launch time. Below I list ten points to consider before launching your new (or renewed) website.
I can hear all you seasoned developers and designers now; we know! We never make these mistakes. Well, someone does, and I’m counting on you to make sure these people see this article.
Update: As soon as this article went ‘live’ people pointed out issues with the font (Lucida Sans) not rendering properly on XP before SP 3. Thanks, everyone who pointed this out. It just goes to show that no matter how hard you test; the one situation you can’t replicate will come and bite you in the posterior. Point made, I would say.
You are not your customer
One reason many websites (and businesses in general) fail is because people assume that their own experiences, perceptions, likes and dislikes mirror those of their customers. The thing is; you are by definition disqualified to judge your own product. You are too intimately involved. Routing, look and feel, even the things you think should be in the FAQ are all too close to home. Try to get lost in your own neighbourhood; you can’t. Things your users will find confusing are so obvious to you that you don’t even consider them.
I once was tasked with building a community site for teens. I’d made a quirky design and for the FAQ I’d used the phrase “FAQ me!” The client shot it down because he’d asked his friends, all middle-aged ladies, and they found it offensive. Would it have worked? I don’t know. Are middle-aged ladies the right people to judge a design aimed at teens? You answer that one.
What to do about it:
Test, test and test again. Get people from your target demographic or actual userbase involved and ask. You may hire a marketing research firm or simply invite some ‘round. That’s up to you and your accountant. Just never assume.
Who is your customer?
Another client wanted a design aimed at, and I quote, “Young children.” So I read up on the browsing habits of young children and made a design that I think would have worked. I had it judged by an expert on child psychology and I think it was good. I handed it over to the client, who decided to do his own focus group testing. Never a bad idea although I was glad I wasn’t involved with what I was sure would involve a clown and wet seats.
When I got the report back, the first thing I noticed was the age group: 14 to 17. And they hated it. Well, to someone nearing his sixties that would perhaps be “young children” but I had worked for an audience a decade younger.
What to do about it:
Make sure you know your audience. Don’t be vague but inquire, hire a research firm if your budget allows, and find out as much as you can. Don’t go for broad demographics, but narrow it down. Find the trends and break them down into sub-trends. Just do not put one single pixel on screen before you know whom you are working for.
Test on different platforms
So you know whom you are working for and you’ve built a very suitable site. Now test on different platforms. I do not mean just different browsers. Try different operating systems and various types/sizes screens. Do not assume!
For example: I once shot down a design aimed at CEO’s. It was a good design, but it was built for large screens and rather heavy on the loading times. When I pointed this out the reply was along the lines of “CEO’s can afford good computers.” I asked my CEO, who was sitting in, to get his laptop from his bag. It was old. It was heavy. It was falling apart.
The more specific your target audience, the more important each and every single visitor. Test! Only 20% of your visitors may be using obscure platform X, but those 20% may just be your biggest spenders. In any case; if you think 20% is peanuts, can I have 20% of your paycheck?
What to do about it:
Test on as many platforms as you can get your hands on. Test off-site and use something like Browsershots for those platforms you can’t lay hands on.
Load
Before you go live, consider the changes in terms of load on your servers. Are you making more, or less, queries on your database? Is the new site heavier on the graphics? Have you introduced video or Flash?
Depending on the changes you may also expect a spike in visitors coming to see the new stuff. Are you ready to handle them?
What to do about it:
Keep staff on standby, make sure you interface with your host or tech staff, make sure your servers are up to the task.
Database / Content / Oversights
Your new site may display the content differently, better of course, and during development everything looks fine. But many sites have a huge archive of old content. Often this content can’t be removed. Usually you shouldn’t because you’d be throwing away a huge chunk of SEO. Many sites I worked on had seen a succession of different maintainers. No matter how well organised, it may very well be that no one in the company really knows any more how things were done back in the days… So, are you really sure that content from five years back will display well? Maybe back then the sub-header was different, or images were a different size…
What to do about it:
Don’t just test with dev. data but pull in data from across the scale and test with a destructive mindset; assume it is your duty to break things. Think like a malicious visitor; what can you do to screw things up? Try them.
Make sure all inputs are sanitized! I can’t stress this enough. Make sure they were back then.
Websites fail because companies hire a web designer and expect him or her to do the coding and database too. Would you expect he pilot of your airliner to repair the engines, too? Get experts and assign jobs based on competencies. I like this quote from the airline industry; “If you think safety is expensive, try an accident.”
Timing is everything
Often a launch is planned when things are quiet. This is not a bad thing, but things are quiet for a reason. Your staff may be out to lunch, too. When you launch, make real sure everyone you might conceivably need to fix emergencies is on-hand, including external support (provider, host, design bureau, etc.) and someone to make coffee for the poor folks pulling an all-nighter if things do break down.
What to do about it:
Plan your launch well ahead. Don’t let people (client, design bureau, boss…) rush you. Refuse, and I mean flat-out refuse, to meet unrealistic deadline changes. You may be fired on the spot, but you may not. An all-out disaster at launch will get you in trouble far quicker and far harder. Trust me.
I once simply stated I couldn’t take responsibility for a project given the unrealistic deadlines and resources. I went home with serious knots in my stomach. The next day I arrived at work to find new deadlines and a bigger budget. It may not go bad. Your superiors may not understand your job; they understand taking responsibility and honesty.
Backoffice
So, you are launching and the site works! People are trying all the new options and the site is starting to bring in fresh business… Where is Sales? Where is Support? The orders pile up. The CRM can’t handle the new order format; things go to pot in a hand basket. I’ve been there.
What to do about it:
Make sure all departments are ready for the change. Make the rounds, and make them again. Skip no one. I literally once delayed a launch because the janitorial staff used part of the old site to plan their schedules.
Surprise!
Once I was working on a page. Obviously I worked in dev. not live. I had dummy data in there and comments that were for my eyes only. While I was typing, a deploy started running. My boss was over at the tech department, and “while they were at it” had insisted they’d deploy some changes. People could hear me scream two rooms over.
Obviously I dealt with the situation, my team was fabulous and we fixed it within the hour. But I nearly resigned over that.
What to do about it:
Keep lines of communication clear. Keep set milestones and deadlines, do not deviate if not absolutely necessary. Make sure there are two people who can order the actual launch, like those guys in missile-silo’s: only together, not on their own. One who knows the ‘paperwork’ side and one who has two feet solidly on the factory floor. Before you push the button, call around and make sure everybody is ready. They may deride you for being overly cautious and a certain type of manager will get all rooster-in-a-henhouse on you, but again: you are far more likely to get fired for a disaster than you are for bruising some seagull-manager’s ego. (Flies past, makes a lot of noise, craps over everything, flies away.)
Back … it … up
So, there you are. You’ve launched and you get a frantic phone-call. Someone forgot about some obscure legal issue, or any of the above issues has reared its head despite your best efforts. Please return to how it was ASAP! But you can’t… the data is gone…
What to do about it:
No matter how much data it is, no matter what it costs, back up everything from the old site before launching. And I do mean everything. Just do it. Not buts or ifs. If you (or your client) can’t afford it, you (or your client) can’t afford the redesign.
Test, Test, Test
Didn’t I say this before? Yes, I mentioned testing. But this time you are not testing with focus groups or on Linux with SeaHorse 1.1. Before launch, test everything. Put data in, take data out, test all E-mail addresses, test all paths, menu items and links (And I mean ALL of them). Is everything pointing to the live system? Are all Dev paths gone? Are the comments placed by that weird Russian developer cleaned up to PG 13? Do this before launch, repeat after.
What to do about it:
Get as many people you can, geeks and luddites alike. Ask them to visit the site and root around as much as they can. Get your own staff together and assign clear tasks: One person to test the menu, one to hunt down URI’s, one to play hacker, etc.
Take your time. Stuff WILL turn up, trust me.
Bonus reading:
A good, if concise, checklist: http://www.e-moxie.com [... ] successful-website-launch/
No Comments yet.