Wouldn’t it be great if clients new exactly what they wanted and could articulate it to you at the beginning of a project? At the very least it would make things faster, but that’s not he world we live in. No matter how much questioning and planning you do before sitting down at your computer to create, there will be an iterative phase of every project. When you think you’ve created exactly what your customer wants, there are going to be a few tweaks requested. And while it would be a stretch to describe these changes as desirable, they do have a small benefit. Your client will feel a stronger sense of ownership of the site, knowing that his or her input was a part of the process.

If you’re lucky the change requests will all be relatively minor, but I have yet to meet the web designer who’s lucky all the time. So fully expecting your “completed” web design to be met with some constructive criticism, how can you prepare to make the revision process as smooth and painless as possible? I doubt a single blog post can cover the topic completely, but I can offer one tool that I find extremely helpful: a change request log.

The larger your project is, the more important a change request log becomes. It’s a way or sorting out the feedback you may be getting from multiple sources. Do any of the requests conflict? When did you receive the requests? Who is making the requests? Does solving one problem eliminate any of the others? It’s also useful just to help you keep track of what’s already done and what you still have left to do.

I’m sure there are sophisticated software packages you can buy, designed to most efficiently manage the issues your customers report. Not having used one, I can’t really comment for or against them. I can say that I feel like I get everything I need out of a simple spreadsheet. Here’s an example of what one of my change request logs might look like:

For each request, we can see where it came from and when. If more than one person on the client side is providing input on the site, this information is critical. When the big boss questions why you made a particular change, you need to be able to cite exactly who asked for it. Ideally you’ll be able to convince your client to designate one person to communicate with you about all changes, but if you can’t sway them this information on your change request log can prevent a lot of frustration.

I find it helpful to classify the different types of requests I get. Feel free to work with whatever classifications make sense for you, but I use the following:

• Bug – the site isn’t functioning the way it was intended
• Incomplete – some portion of the site or design hasn’t been completed
• New Feature – the request falls outside of the original scope of the project and the additional cost will need to be approved
• Minor – the request requires very little time and effort, should be done whether part of original scope or not

If your working on a large batch of requests at once, it can be helpful to group them by where they occur. If you have 5 changes to make to the login page, it’s often easier to tackle those all at once.

Obviously you’ll also need to include the actual change request. How does the actual behavior or appearance of the site differ from the expected behavior or appearance?

Finally I keep track of when the problem was resolved and by whom. I jot down any notes about the particular issue. Later when I’m talking to the client, I can scan through my notes to see if there are any questions I have that need to be addressed before I can proceed.

Thanks to Trotzke for the original idea of the change request log so many years ago.

filed under: Dealing With Clients