Web design ‘pre-flight’ checklist

Over the years of being a freelance web designer, I've been developing my own processes for the business of designing websites. One of those processes has been compiling a list of tasks that need to be completed before launching a website, whether it be a new site or a redesign. This list is kept in a spreadsheet which I work through, ticking off each item after the client has given final sign off for the site to go live. I view it as my final quality control procedure and I usually find that the process will highlight a few of the 'little things' that I might have overlooked in general development. Usually nothing too major; more a case of 'dotting all the Is and crossing all the Ts'.

I haven't included everything that I check during the development process (for instance, there's no mention of browser checking) because there's some things that I do that have just naturally become part of the process; they're instinctive and don't need a reminder to be checked. This is list is more for those things that need to be ticked off so I can be sure that I've done them.

The order in which these items are presented isn't the order I usually do them in. I'm actually a bit haphazard in the way I approach them, but because I'm ticking them off in a spreadsheet, I always know which items are done and which aren't so an order's not really that important. I've collectioned them into groups that seemed to make the most sense.

Validation

• Validate HTML

  It goes without saying really and it's something you probably would've been checking as you go along. If you want to validate your entire site, about your only option is the Web Design Group (WDG) Validator which will only validate up to 100 pages (check the Validate entire site box). There used to be another option called Nikita the Spider but it ceased operation in November last year. Another limitation of the WDG validator is that it won't correctly parse pages with a HTML5 doctype.

• Validate CSS

  This is easier to do as there's fewer stylesheets and in this case the W3C CSS Validation Service is best.

• Validate feed

  For those sites that have them, you can validate your feeds with the W3C or Feed Validator. Errors in your feed can affect the display of your feed items just as errors in your HTML or CSS can, or they can even stop notifications of new items being sent at all, so it's worth checking that everything is correct.

Stylesheets

• Print stylesheet

  Check that you've got one! Or at least check what your pages will look like when they're printed. You'll find in most cases that a print stylesheet is required. My position on the styling of the printed page is to make it as minimal as possible. The majority of people who will be printing the pages of a website will be doing so for the information content and not for its presentation, so you can do away with areas of navigation or anything else that isn't required to understand the message of the page being printed. Likewise, decorative background images aren't needed either and in fact, as background images and colours aren't printed by default, there's little point including them in your print stylesheet.

  And when I say print stylesheet, I should explain that I don't actually mean a separate stylesheet with a media attribute of print. I used to do it that way: include a stylesheet <link> with a media attribute of screen and one for print, but now I just have a single stylesheet with no media attribute and instead use media queries inside that file to target the different media, e.g.:

  @media screen {
    body { font-family: sans-serif }
  }
  @media print {
    body { font-family: serif }
  }

  This does make the overall file size of the stylesheet a little bit larger, but you're also reducing one HTTP request which has more benefit than saving a few bytes.

• Dust Me Selectors

  This is a very handy Firefox extension provided by Sitepoint that you can turn on while you're browsing the pages of your site and it will examine your pages and determine which rules in your stylesheet are unused. I find this quite useful as I always start new sites with a base stylesheet which contains a lot of rules I don't use on every site (but they do get used which is why I leave them in) and this helps me identify the ones I might've overlooked, or to weed out rules that have been added in during development but which aren't needed in the final shakedown.

Accessibility/Usability

• JS disabled

  Hopefully you've been developing your site with progressive enhancement, but to ensure that your site still functions correctly with the layers peeled off, you should turn off javascript to make sure that no content is inaccessible or functionality impaired. To be honest, this isn't really the sort of thing that should be left to the last minute just before you're ready to launch, but I generally find that as I'm constantly aware of how things might work if javascript or CSS is turned off, I don't encounter any nasty surprises at this time, and if I do need to change anything, it's more minor tweaking than anything else.

• Skip link

  I'll leave discussion of the pros and cons of skip links to others, and I don't use them all the time (for small brochure sites with very few links I tend to omit them), but having this item on the checklist is useful as it makes me stop to consider the complexity of the navigation.

• aDesigner

  ACTF aDesigner is a "disability simulator that helps designers ensure that their content and applications are accessible and usable by the visually impaired." It has four accessibility checking modes – HTML, OpenDocument, Flash and GUI. I only ever use HTML mode which has two main simulation modes – blind and low vision. You can run reports in both modes which will highlight errors and areas that should be manually checked to verify they meet accessibility criteria.

• Colour contrast check

  There's various tools you can use to do this but I use the Juicy Studio Accessibility Toolbar (which also has other features like examining landmark roles). This is another one that could/should probably be used much earlier in the design process because you're not really going to be able to change colours around just before site launch when the client has already signed off on how things look. The main reason I use it at this point though is because it helps me pick up when I haven't specified a background colour. This usually happens when a background image is used but if images are turned off or unavailable for whatever reason, you might find that the background colour of the parent element might not have sufficient contrast to make the text readable. Also, if the background colour is of a fixed height, a different colour might show when the text size is enlarged.

• Total Validator

  This is another Firefox extension that I use, but you can visit the Total Validator site itself or download a standalone application. As their site says:

  Total Validator is a free one-stop all-in-one validator comprising a HTML validator, an accessibility validator, a spelling validator, a broken links validator, and the ability to take screenshots with different browsers to see what your web pages really look like.

  At the moment it doesn't validate HTML5 pages or include WCAG2.0 checks.

• UITest

  UITest lets you input a URL and have checked by a bunch of different accessibility and usability checking online services – ATRC, WebAim, Cynthia Says, the W3C and WDG validators, and services that check links, load time, spelling and performance amongst others. I usually find that I pick up one or two things that I've missed after having run through the different tests on this page.

Handhelds/mobiles

• Small screen view

  It's debatable whether I should have this item on the list as I generally don't give it a lot time in checking but you can get a quick idea of how your pages might look on handheld devices by choosing View › Small Screen in Opera or by using the Small Screen Renderer extension for Firefox (hasn't been updated for v3.5 yet). I say it's debatable because even though I do the checks, I don't spend much time fixing any issues I encounter.

• Mobile tests

  This is one item on the list I mostly never do but it's there in case a client ever specifically requests that their site be mobile-ready. There's a few different tools you can use (apart from actual mobile devices themselves):

  • W3C mobileOK Checker
  • dotMobi emulator
  • .mobi Report
  • Opera Mini Simulator
  • iPhoney (Mac-only)
  • OpenWave simulator

Performance

• YSlow

  YSlow is another Firefox extension that analyses web pages and suggests ways to improve their performance based on a set of rules for high performance web pages developed by Yahoo.

  It offers suggestions for improving the page's performance, summarizes the page's components, displays statistics about the page, and provides tools for performance analysis, including Smush.it™ and JSLint.

  Running tests on your pages using this extension will point out areas where you can improve the optimisation of images, stylesheets, external scripts and server configuration.

• Minify javascript/CSS

  One of the areas that YSlow will usually highlight is the minifying of javascript and CSS which is the process of combining these external resources, compressing their contents (i.e. by removing whitespace and comments), and serving the results with HTTP encoding (gzip/deflate) and headers that allow for optimal client-side caching. There are various tools and utilities available for this purpose but the one I use is Minify which also has been incorporated into an ExpressionEngine add-on, SL Combinator.

Search Engine Optimisation

• Microformats

  Microformats have been around for a while, but they're becoming increasingly more useful and their implementations more widespread. In particular, Google and Yahoo are now including Microformats content in their search results (actually Yahoo have been doing so fo a couple of years now). I generally always mark up contact details as a hCard and, again, it's not something I leave until the end, but having this on my checklist is just a reminder that I've done it and also a prompt to see if there should be any other places where hCard information should be added (for instance if contact information appears in the footer).

• Geo tags

  Like including Microformats information, another way to boost your site's performance in local business searches is with geo tags. And with something like the Geo Tag Generator, it's a piece of cake. Just type in your address, copy the tags and then paste them into the <head> of your page.

• Robots.txt

  This is a particularly important one to check particularly if you've been creating a new design on the same domain and have been using the robots.txt to prevent indexing of the new pages. I haven't done it myself (yet), but I've read about SEOs who have forgotten to edit the file after launching a new site until a few days or even weeks after the initial launch. It's also important to check that you're blocking areas of the new site structure that shouldn't be indexed.

• 404 page

  This is more a usability enhancement than an SEO issue, but it ties in to the next point; creating a custom 404 error page will give your site visitors a helping hend when they've reach an out-of-date link. It can serve up a list of alternative options or a search box or at the very least will reassure the visitor that they're on the right site, but just in the wrong location. Creating a 404 page that looks like the rest of your site rather than a default browser or server error page might make the difference between a visitor making the effort to explore your site to find what they were originally looking for, or leaving immediately.

• .htaccess

  A .htaccess file is used for a variety of different functions including setting up custom error pages, redirects and for setting expiry headers on various files (recommended by the reports from the YSlow extension), so it's worthwhile checking to make sure you've included everything that's required and that it's also functioning as it should.

• Google Analytics

  To ensure your site is performing correctly you'll want to use some sort of analytics package. I use Google Analytics and I leave it until just before site launch to add the necessary tracking code. This is for two reasons:

  1. you don't really want to be tracking any activity on new pages while they're still being developed as you'll get skewed view of how pages are performing;
  2. if you're refreshing pages on a regular basis to view changes you've made to CSS or javascript, you may find that you have to wait a little bit longer each time while the Google tracking code loads too.

• XML Sitemap

  XML sitemaps are used to tell search engines about the pages of a site to ensure better indexing of your content. I use a sitemap generator for smaller, static sites and depending on which CMS I'm using, might use a module or extension.

• Google Webmaster tools / Live Webmaster Center / Yahoo Site Explorer

  Another important part of monitoring a site's performance is adding it to these services by the major search engines which provide information on crawl issues, inbound and outbound links, sitemaps and subscriber stats.

• Portfolio sites

  Portfolio sites, e.g. W3Sites or Professionals on the Web, can be used to the benefit of both the designer and the sites you're creating for other people. Your clients may benefit from having additional links pointing back to their sites and if you use portfolio sites to help promote your work, then you owe it to yourself to keep them updated with your latest and best work.

Other

• Back-ups

  Any web host worth its salt should have adequate back-up procedures in place, and you should of course have a local copy of all the files you've worked on, and additional back-up procedures for all your local files (either phyiscal or in the 'cloud') but one thing that you won't automatically have local copies of is any databases used with your application. Some applications will have in-built systems for creating database back-ups; others you may have to set up cron jobs for.

So that's my list. How does it compare to your list (if you have one)? Is there anything you think should be added?