Viget Inspire

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.