Anna Debenham: Style guides, pattern libraries and code standards

Anna Debenham was talking about styleguides at Dot York, these are my notes from her talk.

Styleguides are a set of guidelines:

• Branding guidelines.  Normally geared to print - often using mm and pantone.
• Print guidelines - even more detail to ensure accessibility and consistency.  Often ignored :-(
• Content guidelines - consistent tone of voice that is appropriate.  Keep language consistent with the house style.
• Coding standards - allows multiple developers to work on the same code.
• Style guides for websties - often contain elements of all of the above.

Not all style guides will be appropriate for all uses.

Start by taking an interface inventory, look at all the bits and pieces that make up your interface.

Style tiles are a more specific evolution of mood boards but not as detailed as a mockup.  Tool for conversation, not a deliverable - use at the start of a project.  Tiles will have words associated with them that will use specific typography.

Element collages are a mock up of design elements.  Starting to get into the details of how elements actually work in the context of a website rather than a static comp.  Presented on a wide horizontal canvas to stop it looking like a page.

Style prototypes are now moving into code, this is the start of actual prototypes.  Not production code but actually working in the browser.  Allows you to test out ideas quickly.

Pattern primer is ongoing documentation of a library of working components.  Built using the same markup as the site itself.

Code guidelines are how and why you write code.  See Welcome Trust.  Should be living documents.

Styleguides help you keep on track if you have a large site with lots of people working on it.  It helps ensure consistency and you don't have to start from scratch each time.  Useful for QA teams to check against known good.  Making code visible helps get better code.   Helps with code reviews, people can see examples.

Retrospectively creating a style guide can highlight areas you weren't aware of.

A styleguide can be easily tested in multiple devices.

Explaining the why helps people with the how.  Helps if you have an evangelist to keep it up to date and being maintained.  Makes onboarding new team members easier.  Provides a quick reference for answers to common questions.

Performance is critical.  Keep testing the performance of your style guide.  Add perf stats to your styleguide.

Styleguides helps for rapid prototyping, you have all the core elements you can drop into something.  Modules deal with the basic 95% allowing you to focus on the 5% that makes the difference.

The strictness of the language in the style guide will depend on the use case.

Put each pattern in a single HTML file when building.  Each pattern has an associated CSS and JS file.  There are site wide styles (main.css) and styles just for the styleguide (styleguide.css - selectors prefixed with xx-). Barebones is a good starting point for creating a styleguide. KSS generates from comments in the code.

The style guide is no good if it's behind an internal network - it needs to be public.

Gotchas

They don't replace conversations, it has to come with communication.

Do it at the start, not at the end.

It doesn't have to be pretty - it's a tool. A messy toolbox is hard to use - keep the styleguide easy to use. Don't add things that are unlikely to be used or don't really have to be consistent (e.g. keyboard selector).

Keep them maintained. Don't just walk away once it's done: an out of date styleguide is about as much use as no style guide at all. Ideally use content from the live site.

Make it public

Keeps you honest.

Acts as a recruiting tool: People have joined companies because they have seen the styleguide.