A few weeks ago I wrote a somewhat frivolous post that used 11 animated gifs to explain what it is like to build a website for a client.  I wanted to loop back and write a bit more substantively about the review phase of a project (represented in gif 9), which is the period between showing the client a functional draft of a site and its launch and completion.

In the post, I focus on how difficult it is to work through the final details that come during the review phase.  Correcting typos.  Switching out text and images.  Fixing small IE and mobile bugs.  Testing and debugging forms, ecommerce elements and CRM integrations.  This is all hard and tedious work that is mostly unavoidable.  You just have to grab some whiskey and power through.

However, a lot of the more painful aspects of the review phase can be avoided with good communication and planning.  Below are the most common mistakes I’ve made over my illustrious career, and some simple advice for how to avoid making them.

Hidden requirements

Hidden requirements are critical client needs that surface unexpectedly towards the middle or end of a project.  These hidden requirements are discovered most often during a project’s review phase, when the client first sees a working site draft.  The missing Salesforce integration the client finds when testing a form. The Member’s Only section the client forgot to tell you about.   Hidden requirements are one of the main reason projects go over budget and off schedule.

The best way to prevent hidden requirements from popping up is to have a discovery phase for every project.  During a discovery phase, everything should be put on the table.  The web development firm needs to ask good questions and the client needs to share anything and everything, no matter how small it may seem.  It seems obvious, but in order for a web development firm to efficiently build a website for a client they need a full understanding of the requirements of the project.   As Jordan Hirsch put it in his great Drupalcon session on requirements gathering: “You can’t ever truly skip a discovery phase.  You end up doing it even if the client doesn’t pay for it.”

Misunderstood deliverables

During the planning and design phases of a project, typical deliverables include user personas, site maps, wireframes, mood boards and eventually draft designs.  The goal of these deliverables is to help define a site’s structure and visual language prior to actually building the thing.  When used correctly, these tools dramatically increase efficiency.

A lot of our clients are communicators or policy folks who haven’t managed a ton of web development projects.  While the deliverables referenced above may seem self explanatory to me, they are frankly a little baffling to folks who don’t have a lot of web development experience.  As a result, sometimes clients end up approving deliverables without really understanding what they are approving.

As an example, for nearly all of our projects we produce a draft design composition in PSD form.  These comps show what a site page will look like when built.  When reviewing design comps, clients tend to focus narrowly on branding (photos, exact language, etc.) as opposed to structure (the elements of the page).  So we’ll often go back and forth with a client a ton on photography, and then find out about major structural problems only after we have a site draft done.  This is completely backwards.  Changing photos out once a site is built is easy.  It is much more difficult and disruptive to change structural elements after a site is in beta form.

When this sort of thing has happened on projects I’ve managed, it has pretty much always been my fault for not clearly explaining the purpose of the deliverables, and the ramifications and changes late in the process.  Clients need to understand what they are approving.

Poor review process on the client end

One of the first questions we ask new clients is what the review process looks like on their end.  Is the core team working on the project on a day-to-day basis empowered to make final approvals on all deliverables?  Or is there a Board or President or CEO that needs to review things in order for them to be truly approved?

If a review process requires approvals from people on the client side that aren’t involved on a day-to-day basis, it is vital that key deliverables are shared and approved throughout the site build process.  As an example, if a client requires CEO approval we might solicit their feedback and approval on our site plan, wireframes and the draft designs.

The key is to get feedback from all stakeholders early in a project’s life cycle, when changes are inexpensive.  What you don’t want is to build an entire site only to find out during the review phase that the CEO has a completely different vision for the project.  This has happened to me more than once.

Poor review process between client and web development firm

Back when I was younger and stupider, I was guilty of sending draft sites off to clients with vague direction asking them to tell us what they think.  The result was sometimes a free-for-all, with changes trickling in one-by-one over email from multiple people on the client side.  The changes often contradicted each other.

We now ask our chief client contact to compile feedback into a single batch of changes that are vetted and approved by all internal stakeholders.  We usually use Basecamp to track changes and to communicate where we are on tasks with the client.

It sounds obvious, but simply communicating to the client how feedback should be sent can save a ton of headaches.

Lack of resources on client end

Building a website is a lot of work.  Once we turn over a project to the client for review, the ball is largely in their court.  At that point they are responsible for reviewing and testing the site, getting buy-in from relevant stakeholders and filling any content gaps.  This takes more time, and is a less fun, than reviewing a site map or a design comp.

I’ve worked on projects that were delayed for months due to the client simply not having time to review and compile feedback on the draft site.

To mitigate these sort of delays, we try to be up front at the beginning of the project about the amount of time that will be required from the client during the different phases of the project.  The beginning (discovery and planning) and the end (review) of a project tend to be the periods that require the most time from the client.

Lack of a solid content creation plan

Most people approach the drafting of website content the way college students approach term papers: it is something done at the last possible moment with the aid of caffeine and a hard deadline.  For a website, the content should be one of the first things you work on, not one of the last.  There are a few reasons for this:

• I’ve written about this before, but content has a huge impact on design.  If text you expect to be one sentence ends up being three paragraphs an entire page layout may need to be redone.  Producing content early in the life cycle of a project, instead of at the end, will prevent expensive and time consuming changes during a project’s review phase.
• People consistently underestimate how long it takes to write and edit a site’s copy.  If content is done at the last minute delays are pretty much inevitable.  We have completed sites and then waited for months for the content to get finalized.
• Once the copy is produced, it can take a long time for the web development firm to drop the copy into the site and format it so that it looks right.  Content delays can cause a chain reaction, with other work held up until the content is ready to go.

To prevent the content from slowing down a project, we try to work with our clients to establish a clear content creation process and plan at the very beginning of a project.