by Sarah Shealy

A web style guide, in it’s most basic form, is a document that lets everyone employed at a company know exactly how the website should look. Many large companies have enormous ‘brand books’ that cover everything from types of shoes worn by employees to the color of paint in the restrooms of stores and how to answer the phone. Since the focus here is on websites, that covers a little much for the purpose of this article.

It does not matter if you work at a large educational institution that has a brand book or are the single librarian that maintains the entire website, online resources, databases, etc., you can (and should) make a specific style guide that relates to your website.

Website Style Guides Should Include

  • Correct colors with the hex codes
  • Snippets of code that are basically drop-in ready
  • Font/style choices for different circumstances
  • Width/height of columns and/or distinct areas of a page (header, footer, etc)
  • Background colors for buttons, form fields, menus, image padding, etc.
  • Anything that is specific and unique.
  • What NOT to do – like “do not use underlined, bolded, red text in comic sans followed by 17 exclamation marks in page copy” or “Don’t use collapsible menus above the third list of sub-items”
  • Anything that is important to the look of your site. Even if it seems small. Even if it describes the amount of padding around elements, if it seems important to you, put it in there.

7 Reasons You Should Have a Style Guide

  1. It allows continuity between generations of staff members. You may not be around when the next person in your position is hired, and there is no one else to tell them that a specific shade of coral is only to be used in H3s on pages devoted to penguins and nowhere else.
  2. New employees need to be familiar with your brand as well as the intricacies of how the website in particular looks and how it gets that way. A style guide is an easy way to get all of that information into one place. They will not have to poke around your files to get any of that information.
  3. A lot of vendors allow (minimal) customizing of their interfaces and it is much easier to send them a concise list of colors to use, along with logo specifications.
  4. If the above minimal customizing is done in house, it is still easier to have the information directly in front of you while you change things. Even better, hand it to your intern/unicorn and they don’t even have to find the right CSS file to pull from.
  5. At some point in time, there will be a site rebuild. No one likes it, but they happen. If your branding remains the same you can simply pull from the style guide to new files and not bring any extraneous code with it. The beauty of the style guide is that you can keep what you need and change what isn’t relevant anymore.
  6. A style guide keeps everyone on the same page. Especially on large projects where a contractor/co-worker may decide to create a stylesheet just for his work, having a style guide that lays down the fundamental rules is the best. I have had to meld 4 different stylesheets from 4 different people for one project before and it would have been so much easier with a style guide.
  7. Think about what happens if your CSS files get corrupted, mistakenly saved over, or drastically broken by the intern/unicorn mentioned above. Oh, and your GitHub repository was erased. Hopefully you have a backup, but it’s always good to have backups of backups. At least the basics will be safe.

Style guides, unless you just love design and details, can be tedious to put together if you aren’t really into it. Many times, it seems like extra work when everything is already stored in various files. Your time is valuable, and taking a few hours (or less, or more) to create a document that shows everyone the basics of how to make the site look good. It will save you drastic amounts of time when trying to get others familiar with the insides of your site’s look.

Remember that after the Apocalypse, when things get running again, you’ll be glad you stashed a paper copy in the back of your drawer so you can brand that site all over again.

About the Author

Sarah ShealySarah Shealy is a Librarian who accidentally stumbled on Front End Development at Richland Library. She teaches teens how to code, makes the site look pretty, and tries to keep a toe in Libraryland.

You can find her on Twitter @Sarah_Shealy