Post-Implementation, Pre-Launch: A Crucial Checkpoint

There's a certain type of project we find ourselves working on every now and then that can turn me into a puddle of stress until (and often after) the site launches.

It goes something like this:

The client has an internal web team and/or budget is tight -- so UX and design get full attention, but build-out is minimal. Our front end devs might build 2-3 pages, a basic elements page, or nothing at all. The client's internal web team is tasked with absorbing a set of PSDs and deconstructing the visual system. They need to create mark-up for the comps we've given them, and they need to extend the design and mark-up considerably to cover a large site. Oh, and they also have to port all of this into some type of CMS templating system. Usually under a hard deadline. Easy-peasey, right? 

On top of all that, we often don't get to meet the people that are going to carry out this work. This means there is no opportunity to explain our vision or establish trust in either direction. As Doug points out in his excellent post about planning for hand-off, this can be a scary prospect for both teams.

The Current State Of Things

At Viget we already do a lot to help make sure the client's internal team has the tools it needs to rock it out. Our PSDs are organized, our layers are named, and layer comps are put to good use. Reusability and flexibility are considered throughout the process and built-in wherever possible. We have made element list pages (a comprehensive set of reusable pieces with CSS/HTML - example) a standard deliverable. And, of course, we always leave a line of communication open, so we can answer questions when implementation actually starts.

The problem is that sometimes this is not enough. We send our hand-off deliverables out into the world, and months pass without any word. Then, suddenly, we notice that the site is up ... And it's not at all what we -- or the client -- dreamed it would be.

Common problems:

• There is a need for additional layouts, but the client team doesn't have the skill/time to make something consistent with the established design. Extensions of the design (new page templates, callouts, graphic elements, etc.) look piece-meal or are left without any style at all. The site feels disjointed.
• Small but important nuances have been overlooked. Often these are details we've provided in the build-out, but they just weren't noticed or prioritized. Tiny things being off -- a few pixels shifted here, or a bad sprite alignment there -- makes everything look buggy and loosey-goosey.
• Design elements have been used in ways we never imagined they would be. They start to break the visual system, creating clutter and confusion.
• We've neglected to style something basic that didn't show up in comps, like a blockquote. The client's version of it looks out of place with the highly styled elements around it and feels incomplete.
• Content looks nothing like what we had planned for in the UX and design phases, so it feels like it has been shoehorned in. The design needs to change to better accommodate this new content.

Small things make a big difference, as we all know. When one or two of these things go wrong, the entire site begins to look jumbled and unprofessional. 

How can we make it better?

Nobody wants to see this happen. Designers are sad to see their carefully crafted designs fall apart, and clients must be disappointed to launch a site without the polish they envisioned. But, a little more communication between teams and a few hours of pre-launch QA on our side can make a huge difference.

I recently had the pleasure of working on UPenn.edu, which was a great example of how we can improve/avoid these issues. The project process was similar to what I've outlined above, but with two major differences that made a big impact:

1. The Penn web design team was involved in all of our conversations from the very start. They were at the kick-off and followed along with our progress from wireframes to final comps. We got to know each other over the course of the project. They were familiar with us and our vision.
2. Shortly before UPenn.edu launched, we had the opportunity to take a look at the development site and help with QA.

Bullet point #1 was awesome, because everyone was on the same page, so we all felt comfortable asking questions. It felt like a collaboration rather than one team handing down directives to another. Big props to the Penn team; they were really fun to work with.

#2 is really big and doesn't happen as often as we might like. I jumped at the chance to help with final tweaking, as did other team members here at Viget. I cannot stress enough how great it was to have a chance to help tighten things up before launch. Though the Penn team did a great job of implementation, there were still, inevitably, a few improvements to make. We were able to provide a few extra design elements and layouts, find and knock out some bugs, and just generally support the Penn team as they raced toward their deadline. IMs and emails were flying back and forth all week. Everyone seemed to feel the excitement as the site started pulling together. We didn't have direct access to files, so we sent over code snippets and their team was extremely patient about even our (okay, my) most nit-picky requests. It was the best-case scenario with this type of project. The result is a site that everyone can be proud of.

When we're handling UX and design but minimal build-out, I'd love to see this become standard procedure. It is a crucial checkpoint. Everyone gets to take a step back and look at the big picture, to evaluate how our deliverables have stretched and grown to fit the full site, and to revisit our decisions and make sure they're still working. It's inevitable -- there will always be things that need to change between design and implementation. We should plan for a few light design, UX, and FED updates to accomodate those changes whenever possible.

Does anyone else have good suggestions for smoothing the internal/external pre-launch process?