Edward Yarnold

We’ve all been there.  Working flat out on a project for day after day, to finally see the light at the end of the tunnel and start to consider launching.  But wait!  This is a dangerous situation to be in.  Having looked at the same site for so long, you’re not going to be able to spot the mistakes that you’ve made.  It’s worth spending an extra couple of hours to double-check your work – rather than have the embarassing situation of launching a site with mistakes present.

Until I worked for a couple of established Web Development companies, I never realised the importance of a ‘Checklist’ at the end of a project.  You know, simple things.  Does the site’s markup validate?  Do all images have alt tags?  Is php display_errors off?  But even after getting in the habit of ticking all of the items off this checklist for every site I build, there are still little mistakes that creep through – miscapitalised letters, incorrectly pluralised nouns… eg “There are 1 comments on this post” should be “There is 1 comment on this post”.   No checklist can possibly cover all of these possible errors (though the one I link to later in this post gives it a good go!).

The best way of discovering these problems is to ask a favour of (or even to employ) someone you know – preferably without a technical background – to go through the site and see if they can spot anything that needs changing or fixing.  You will find that they will probably produce a list twice as long as your original checklist!

The beauty of this approach is – as well as spotting spelling mistakes and other simple errors – you may also get some vital usability feedback, especially if you are with them when they are checking the site.  Do they seem frustrated? Did they use the site in the manner you would expect them to?

I was once fortunate enough to be behind a one-way mirror in a usability testing session and it was simply amazing.  We had a captcha image on a form (I know, I know.. don’t start) and the error message was misunderstood or found to be confusing by nearly every user.  The abandonment (and frustration) rate on the contact form was therefore extremely high.  This kind of problem would not normally be picked up in smaller projects where a usability testing session is not included (and you wrote the error message – so find it simple, right?), but if you run through the site with someone to whom the site is fresh, there’s a much higher chance that you will pick up the problem.  Remember that this issue wouldn’t be picked up by a checklist either!

So.. checking through a site with somebody non-technical (and who has never seen the site before) can save you a whole bunch of headaches in the future.  And remember – if you’re launching your web sites without a flight check list (check this one out from Box UK), that’s probably one of the first things you should consider implementing in your project schedule.  It will save you a lot more support time than it costs you.

This entry was posted on Monday, March 22nd, 2010 at 10:00 pm and is filed under Best Practice, Tips, Web Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.