What To Expect When You’re Expecting CSS/HTML Handoff

Picture this: You're a designer at Fancy Design Firm, charged with building out a design that another group will implement. You might never meet this group, you don't know how adept they are with buildout, and you're not entirely sure what they'll want to do with your CSS/HTML.

Even worse, maybe you're only delivering a sliver of the site, just one or two pages, and this team will need to finish out the other 90% of the markup. You'll be credited with the buildout or blamed for it, but the final results are out of your hands. What do you do?

Or, imagine that you're a client who's hired Fancy Design Firm to design the site, and you want your Stressed-Out Internal Team to develop it. You need to make sure that S.O.I.T. can correctly implement the stuff you get from F.D.F., and you even want them to expand on it, stretching the design into a full site with new styles.

The trouble? You don't know how F.D.F. codes or what to expect from them. Whatever you get from them will be final - you can't go running back every day until launch and asking them for stylesheet tweaks. You're not a CSS/HTML expert, so you're not sure you'll be able to tell what's good or not. What do you do?

A Bad Place To Be

Both parties are in a spot here: Designers are hoping their work doesn't get mangled, and clients are hoping their deliverable isn't crappy and inflexible, but neither party has a sure-fire way to get what they want.

I've been delivering buildout a lot recently, so I've been reflecting on what works best in this situation. In the interest of helping designers and clients agree on deliverables, I've written this little reference list. This is by no means a "client bill of rights," simply a set of topics clients and designers should discuss when expecting a CSS/HTML deliverable.

What To Expect from CSS/HTML/JS Deliverables

Reusability - Styles should be named and implemented with re-use in mind. Simple utility classes like "right", "left," "intro," and "hide" let clients quickly achieve design effects, and more specific classes like "feature-set" can be reused sitewide and modified to client needs. In contrast, "fall-2009-promos" is a dead class: a set of styles that the client will need to basically rewrite in order to copy.

Note about semantics: While classnames should be semantically meaningful whenever possible, clients will run into situations where their boss just asks them to float a photo to the right. Rather than making them add a ".secondaryPhotoArticle" class to the stylesheet, I'd rather give them something meaningful to THEM, like ".right."

Documentation - A designer's first instinct might be to leave comments in the code, but these tend to get ignored and bloat the filesize. Any buildout deliverable needs some kind of documentation of how the more complex elements interact, and offer ideas on how to reuse or change them.

Quick tip: Sometimes we hand off sites with an "element list" page, which has all the site's major components laid out on a single page with notes. Developers can mix and match elements as they please, instead of trying to copy pieces from finished designs.

Design Files - Nothing is final on the web, and the PSDs received from a designer should reflect this. At the very least, they should still have slices in place, but major images and sprites should be broken out into files that can be easily tweaked and Save-For-Webbed.

Quick tip: I've found that breaking elements into individual PSDs is a huge help during the buildout phase itself — it makes quick adjustments a snap.

Styles for Every Tag - Even if the design doesn't have a <dl> or <table>, for example, it needs to anticipate one with some simple styles.

Quick tip: I actually use a class of ".data" to style tables, just in case clients need to use a table for layout or import some existing tables. In a perfect world, clients wouldn't use tables for layout, but designers need to design for imperfect situations.

Validating Markup - The final markup validate, even if it won't be perfectly valid on the final site (due to outside plugins or requirements). This is a simple way to check for bad markup, as well as a way to tell if designers are working with web standards in mind.

Bugs - Everything should be built for flexibility, but between handoff and launch, there's always going to be something the design just didn't anticipate. If the client doesn't have the technical expertise to work on these bugs, they should consider keeping 10-20 hours of support time on the contract for help during the development phase. (Actually, put this time on the contract regardless!)

IE6 Support - Sorry designers, but clients should expect that you tested everything in IE6 and got it running. Clients, install something like MultipleIE to check this out for yourself.

What NOT To Expect

IE6 Perfection - Nothing should look broken in IE6, but it won't look exactly like the comp. There are some visual touches that are just too time-intensive to implement in IE6, and quite frankly not worth the time a client pays a design firm for.

Hyper-Changeable Design - There's no way around it - some things are just going to be a pain to change. Graphical navs and big backgrounds tend to be time-consuming to update, so if clients anticipate new nav items or color changes a month after launch, they should let the designer know early in the process.

"Our Internal Designer Will Finish It" - Javascript and CSS, while familiar to most designers, might not be a strength that a client's in-house designer has. If the designer needs to make major changes to complex pieces of the site (an image carousel, for example), make sure everyone knows up front, and make sure the internal designer talks to whoever's doing the buildout. This also goes for Photoshop effects: if a client expects to copy a designer's style month after month, they should ask for a tutorial on the style.

Happier Clients, Happier Designers

No one's off the hook here: In order to get a good, appropriate buildout deliverable, both parties need to set expectations and be ready to make compromises. These guidelines are just a starting point. So what do you think? Did I miss anything, or put something in that you absolutely disagree with? Let me know in the comments.