A Pocket Guide to Front-end Style Guides

While I like the Atomic principles and I think about them when I’m writing front-end code, my preference is to stick with the word “component”. I find the Atomic terminology too rigid– it’s not always obvious whether one of these building blocks is an atom, molecule, or organism, and I don’t want to pass on this confusion to the client.

The term pattern library is sometimes used when discussing style guides. A style guide explains how things are going to look, whereas a pattern library tends to focus on how they are assembled. Style guides are a fantastic tool for designers, and pattern libraries are generally more useful for developers, but there will be some overlap. The term design system is frequently used as an overarching term covering core principles, language, design, and tools used to implement these. Its application may be similar to a component library, but with more emphasis on behaviour and interaction.

I often have ideas for pieces of a site in bursts. A full comp often requires ideas to be fully realized. An element collage allows me to document a thought at any state of realization and move on to the next.

Element collages are perfect for designers who aren’t yet comfortable putting their designs straight into code, but want to move away from full mock-ups. Both style tiles and element collages are intended as discussion pieces. There’s a sensible trend away from grand reveals towards experimentation and showing little and often.

In his article “Responsive Deliverables”, Dave Rupert suggests that customised, small, Bootstrap-like systems could become “self-documenting style guides that extend to accommodate a client’s needs as well as the needs of the ever-evolving multi-device web.”

Assess your style guide frequently, such as at the end of every sprint, testing in multiple browsers and devices as you build. Using tools like Ghostlab, Browsersync, and BrowserStack, you can check your style guide on multiple browsers and devices simultaneously. Run this testing throughout the build, otherwise it will become a source of stress right before a deadline. When you’re rapidly iterating, inconsistencies can creep in. Having all your modules in one place during code review helps keep track of what’s new, what’s a duplicate, and what’s not being used.

Installing a browser plugin such as total11y allows you to review common accessibility issues like colour contrast.

Since performance in this project was critical, Dan and Tim thought about performance from the beginning and let it influence their design decisions. Tim even created a Grunt task to measure how fast each pattern was loading. Lonely Planet also think a lot about performance. Each JS and CSS file has performance statistics logged in the style guide, and changes to these statistics are highlighted and plotted on a graph.

Every time you build a new but commonly used feature, such as an image with a caption or pagination controls, remember to pull the module into your style guide. That way, you can use the style guide as a prototyping tool, slotting modules together to test new ideas. By using real code rather than a design tool, you’ll be able to see exactly what a new feature will look like on different devices, and how it will work alongside existing components.

Front-end style guides are also invaluable as a way of delivering work, especially in Agile projects where different parts of a website may be completed at different times. Rather than getting feedback on a whole system at once, you can deliver parts of it, and really focus that feedback on the individual components.

People will resist adopting a process they don’t feel a part of. Get team members involved in planning and building the style guide right from the start so they are more likely to want to maintain it.

One way to make sure your style guide is kept up to date is to appoint someone on the team as an evangelist: someone who keeps it in check, and makes sure new patterns are always added.

Only add components that are needed. MailChimp only add new patterns when there’s a sound case for doing so, because new patterns come at a high cost in terms of additional code, maintenance, and increased cognitive load on users. MailChimp know that the more they add to their style guide, the more features they have to support and the more complex the style guide (and the site) gets.

Aim to make all your components self-contained so if the component becomes obsolete, you can remove it without breaking something else. If you’re using Sass or Less, these files should have the same name as pattern files so they’re easier to find, and so you can see that the matching files are related.

A week after the US Web Design standards went live, Maya Benari tweeted that they’d merged nine pull requests from people outside government.

GEL is packed with insights. Since the BBC has a massive audience, its design teams spend a lot of time thinking about and researching design for diverse environments.

Dan Mall proposes baking in time after the project to revisit the style guides he delivers to clients. This is brave, because it admits the system is not going to be perfect at first. Dan uses this extra time to see what’s working, what’s not working, and how the style guide can be improved, making tweaks based on this feedback.

A style guide isn’t a silver bullet – it needs good practices, care, and attention. Its success should be measured not by how good it is when it launches, but by whether it is kept up to date and referred to months, even years, later.