Checklists and Why We Use Them

Building a website is not a simple task. It involves many steps, languages, systems, applications and technologies. However, a build can be very easily compartmentalised and broken down into more manageable chunks. There are also a lot of tasks, potential issues and technical requirements that are present from project to project.

Therefore, our job lends itself to the heavy use of checklists. I’d like to say that checklists aren’t there to hold your hand through the build of a website but effectively, they are. They’re there to make sure that something simple is not forgotten, missed or ignored. They perform a number of roles throughout the build process:

• A reminder of important steps to complete
• A list of testing criteria
• A list of people to talk to at certain stages of the process

Checklists in Front-End Development

In front-end, we use three main checklists; one before we commence the build, one on build completion before internal QA and a final one pre-launch. These are our main, structural checklists that make sure we deliver a well rounded project.

Our first checklist is all about information gathering, planning and preparation. Internally, we will speak to everyone who is involved in the project to reaffirm features and requirements and fully understand the design, specifically how the user interface should behave. Externally, we will speak to the client, explaining next steps, getting clarification and determining expectations.

Our second checklist is our way of ensuring that our builds consistently contain everything they should, that they are fully tested on multiple platforms and meet our standards of quality. We cannot put a build into our internal QA until this checklist has been completed and signed off by a project manager, so this is a very strict stage of the process.

Finally, our last main checklist is undertaken just before a website is due to go live. More often than not, we will complete a build, train the client and pass it over to them for content population. When they are done, in theory, the site is ready to set live. Before that however, we will check through the site, again from a quality point of view, to make sure that we are happy for the site to go live. At the end of the day, we have spent time and effort on the site and we want to be proud of it when it goes out into the wild, so we want it to be in the best possible condition when that happens. We will check the quality of content and images and make sure that all settings and configs are correct for the site to work when it is set live.

More Specific Lists

On top of the lists detailed above, we have a bunch of smaller, more specific lists to help us cover off smaller tasks, such as installing and setting up a cms or setting up the local development environment for a build.

Our Approach to Checklists

Every list that we have is project agnostic and while the odd point may not apply to a specific project, the lists do not get chopped and changed to suit. They are meant to be rigid and persistent from project to project to ensure their success, otherwise they lose all purpose. Our lists do evolve over time though as new process and technologies get introduced, old ones are removed and certain requirements become redundant.

Why You Should Use Checklists

Among others, there is one simple reason why checklists are a great idea. They take any task, big or small, easy or complex, and make it manageable. They won’t complete it for you and they certainly won’t make everything go trouble free but they do a lot of heavy lifting and free up your brain for fixing the bugs.