With the website redesign for our sister company, HealthComm, we found ourselves needing to come up with a whole new workflow to adapt to how rapidly the web and technology are changing. With responsive design, you hear a lot about sketches, HTML prototypes, content wireframes, etc., but one part of the process that is often overlooked is the style guide.
First of all, why a style guide? A style guide leaves documentation for current and future designers and developers. This keeps the brand, content, and/or markup consistent. Traditionally, design style guides are passed along as PDF or a PSD document, while markup standards documents remain their own separate entity. With the workflow changes, we've found that the process is not as linear as it used to be, and the line between designing and developing are more blurred than ever. So, it seems the natural evolution of the style guide is to become web-based where it is a happy marriage between to the two, usually separate, processes.
An HTML style guide is a great transition from static design to working markup. For people like me who are more designer-than-developer, it grounds your design and lets you consider how your design's elements would apply site-wide as opposed to a specific page. It adds a level of interactivity that static images of your up/down/hover/active states couldn't encapsulate. Larger projects are now streamlined with more clarity in both the visual and markup aspects without having to reference separate documents.
There are different ways to go about creating a style guide depending on its primary purpose. Some style guides are more focused on the markup, while others on the branding and visuals. A major component of our style guide is formatting text for our blog posts, so that'd include base styles such as headlines, lists, figures, and others. A user-friendly style guide that has the logic behind each stylistic decision and its use goes a long way for those who aren't as familiar with the project. One tip is to create one long page as opposed to separate pages in order to keep it simple and free of any conflicts. If it gets too lengthy, you could consider having navigation that uses anchor links.
You can check out the work-in-progress of the style guide here. We've started with the desktop view but will be enhancing it for tablet and phone devices. Cheers to one less PDF to look at!