Style guides aren't new, the printing industry has been using them for a long time, but we don't see them nearly often enough on web projects. Just as a coding guide is useful for programmers, a style guide is useful for front-end developers. A style guide is useful for all projects, but it really shines on large projects with many front-end developers or projects that you will be coming back to regularly.

A style guide can help:

  • A group of developers produce consistent looking user interfaces
  • Bringing in new developers that much faster without having to mentor them as much
  • Developers focus on content rather than thinking about how to display the information

What's in a style guide

Fonts

Which fonts (or preferably font stacks) to use in which situations. Headers, sub-headers, text, notifications, etc. should all be mentioned. The list of fonts should be complete and no other fonts should be used without adding it to the style guide first.

Colors

What colors can be used and in which situations once again. Just as with fonts, the list should be complete.

How to display the different UI elements

Hhow should error messages be displayed? how about the notifications, instructions, tables, links, all headers, etc. Don't hesitate to specify how each element can be displayed with minimal input from the developer (by using reusable components or partial views or whatever mechanism your web framework supports). You could even specify the styling that should be used or better yet, simply the CSS class.

Images

Which images should be used and when. If I need an image that isn't provided yet, where do I find more from the same pack (and the new ones should be added to the style guide). How screenshots or other images should be included in the design. When should a thumbnail be used, what are the maximum dimensions and file size, etc.

Of course, a lot more can be included in the style guide, the goal is to leave as little room for thinking as possible. The style guide is a living document and can be modified to accommodate a new situation, but this should be a rare occurrence and big deal.

How to create a style guide

The style guide should be the responsibility of the UI lead (or a group of leads). He's in charge of the design direction for the project so he should be the one putting the constraints. If someone disagrees with the style guide, the lead should know about it and a revision to the style guide should be considered. If it's simply a case of a missing design specification, it can easily be added to the style guide.

There are a number of ways of creating a style guide, some use images, some use only a wiki-like text guide, but the most useful and accurate style guides will be coded in HTML and use the same stylesheet(s) as the project. The guide should be very visual, with at least one example for each situation. Headers should look like headers in the project and the same colors, fonts and images should be used. The style guide should be consistent with the UI and look like a page from the website being built. Don't be scared of adding code snippets (CSS or HTML), it will make everyone's job later much more simple.

Multiple style guides can be used, but they should never overlap each other, otherwise they risk contradicting each other and you will forget to update both. They should share the same stylesheets (the secondary guides can use specific stylesheets just for them). However, keep in mind that the less style guides you have, the easier it is to follow them.

So, next time you embark on a new project, make sure to create a style guide or ask for one to be created for you.