Style Guides with Jeremy Keith
In Style Guide Podcast episode #12, Jeremy Keith from Clearleft discusses his thoughts on the three purposes of design mocks (designer's concept iteration, communication to development, and buy-in from client), how real decisions should be made in the browser and not in static mocks, and how Clearleft builds into contracts that the deliverable (in certain cases) is a pattern library (a set of well written code that is ready to implement) and that they will revisit/regroup at a later date after the client has lived with and accommodate the code to their purposes.
I really find that last idea poignant. As creators of web products often train our clients on CMS and try to document as much as we can, but we really don't know how they are going to use the end product until they get their hands on it and start running it through the ringer with their content and processes. And if/when they break what we've designed, because our design or code couldn't accommodate the unforeseen, it is perceived that our product is broken. It is a much better idea to treat the product we are creating for our clients as a tool they are going to use and a part of an ongoing relationship where we are supporting their use of said tool.