In today's Nerdery Webcast, Interactive Style Guides, Susan Robertson and Ryan Carlson discussed their workflow around and justification for web based style guides.

Here are my notes from their webcast:

Overview & Justification of Interactive Style Guides

• By creating a style guide (SG) you ensure uniform code, cleaner styles, less markup and a faster build process in your project.
• An interactive style guide is not a traditional branding guideline. It's more about how the site should be made. It's about your front-end code.
• Most design decisions should have already been made, client signed off, etc. Construct the SG when the team is ready to actually build the site.
• Style guides can include HTML snippets. CSS and JavaScripts are typically accessed by the developers through basic browser tools like inspect element or view source.
• Typically they show the actual visual representation right next to HTML. Makes it easier to visualize and pull reusable code.
• Build a system. Get your system right in the beginning, and life will be far easier throughout the process. Think in terms of modules or Lego's. Put them together to form your pages.
• Your SG should be a living document. Always up to date and current. It's a hard habit to keep, but imperative to the success of the SG.

Why Use Style Guides

• It's a better workflow. You find problems earlier. Opens a door for conversations among the team members, especially between designer/developer.
• Overall design consistency. Less of an impact when team members change.
• Great reference for new team members.
• Reference for back-end developers. Makes it easier for team to mock up ideas.
• Fosters fast prototyping. Grab pieces of the puzzle and put them together into pages. HTML is already written if you want to mock up an interactive prototype.
• Gives the team a common language to reference. Everyone knows what your talking about when you reference a specific element or style.
• Scaling speeds up exponentially. New pages can take 10-15 minutes once it's well documented.
• Takes some more time up front.. But always worth it, especially for larger websites that may scale in the future.
• Easier cross-browser testing. All elements on one page.

How to make a Style Guide

1. Take an inventory. Use PSD files of the site and look for repeating elements. Grids, colors, etc.
2. Have a conversation with the designer. Is everything expected? Can anything else be standardized? Ask all questions about inconsistency. Is it on purpose? Don't just make assumptions. Get development involved as early as possible.
3. Plan. Determine which elements to include, standardize everything that you can. Then, find a logical place to begin.
4. Start coding. Layout the style guide within the frame of an actual page. Show examples of every possible element, in every context. This includes mastheads, headings, grids, buttons, body copy, and any other important elements.
5. Keep it up to date. This is your teams reference for everything. Admittedly a difficult process, but try to make it an important step in your future processes.

Q&A Session

• Would you recommend the designer or developer write & maintain the style guide? This depends on your team's workflow. If they know front end code, designers should do it. Ideally, the person who writes the SG should be working closely with those writing the actual front end code, if not the same person/people.
• In your experience, how do project managers feel about interactive style guides? Project managers tend to sign off on these, they think it's great! Once they've seen it in action once, they tend to ask for it, even push for it on all future projects. They see the benefits clearly.
• You mentioned that you often include HTML snippets in your style guides, do you include CSS/JS also? They could be included.. Not always necessary to show on the page visually, as developers can use inspector to get those things.
• For mobile and responsive websites, should styles be represented on the same guide, or should there be multiple SG's? Responsive should be build in, drag the browser on the SG page and see the response! Also, don't do an m. site! If you must, be sure to include a link to the full website. Give users the option.

Resources & Further Reading

• 24 Ways Article Check the comments section here too!
• ClearLeft's Style Guide
• Starbucks Style Guide The most robust interactive style guide out there!
• BBC Global Experience Language Style Guide
• Stanford Style Guide

Susan is on twitter @susanjrobertson, and Ryan is @ryancarlson.