The use of style guides in web projects has been on the rise in recent years, thanks to a heightened community awareness, with various industry pros demonstrating their use and effectiveness. This increase could also be a consequence of more ambitious web projects, coupled with the adoption of responsive web design on a more capable web. No matter what the cause, style guides are an effective tool as part of the modern web design workflow. They will help you design and build faster, with more accurate and consistent results.
Whilst they are primarily a tool for you as a designer and/or developer, they can be a deliverable for clients too. Style guides give clients an insight into the design system being established, and the palette that will form their product. Samantha Warren has explored this idea in detail with her Style Tiles , which is a method for demonstrating a visual language to clients in the form of fonts, colours and interface elements.
What is a style guide?
In contrast to a traditional static web design layout composition produced in Photoshop or similar, a style guide is a set of elements and components that when used together can form a complete layout or parts of that layout. When produced correctly, they are scalable and flexible, making them the perfect tool for building responsive designs. In this article, I’ll use the terms ‘style guide’ and ‘design system’ interchangeably, as I believe style guides are most effective when they form a system for managing existing designs and allowing the production of new ones with ease.
So why would you want to switch from a traditional workflow? For a start, introducing a style guide means you will be able to get into the browser quicker and spend less time in desktop design tools. At their most useful, style guides enable you to work up all your design concepts in the browser, demoting the likes of Photoshop and Sketch to asset creation tools, rather than what you use to envision layouts.
The problem with the traditional approach of asking clients to sign off on static layouts is that these are essentially photographs of what the website might look like. Of course, we’ll try our best to make the final product look like the promise we’ve made in this photo, but we’re creating an idealistic render, without having to contend with all the living parts of the web. Many small nuances – such as type rendering and spacing – may change. This can amount to the client feeling like they have been misled by the Photoshop render.
Using style guides as a design deliverable eradicates these difficult discussions with a client, and can dramatically speed up your workflow. They make design changes easier to complete without much hassle, and get you in the modular mindset from an early stage in the project workflow.
Starting with the basics, let’s look at the ingredients of what makes a good style guide.
This includes the whole typographic hierarchy, covering headings, lists, block quotes and paragraph text. It should also cover any variations within these categories, such as captions, drop caps and any other special typographic treatments, and UI contexts like buttons, navigation and form fields.
Grids and spacing
This should include both horizontal and vertical layout grid systems. Grid guidelines enable you to rapidly prototype and build layouts without having to make time-consuming adjustments to spacing and margins.
Your primary colour palette, including the main link colours, actions and element colours (for example, buttons, labels and icons). There will also be colours outside of this palette for circumstances outside of the ideal design state, like error and system messages, and validation.
Modules comprise elements such as buttons, form fields, tabs and navigation, as well as collections of elements such as captioned images and blog post meta data. They also include combinations of elements working together – for example an article heading, date and introduction paragraph, a tooltip with a small heading and text, and so on.
Ideally your style guide should give you everything you need to design and build a page at a moment’s notice, without having to open up Photoshop or Sketch. In regards to the format, a style guide should be live HTML, categorised in a manner that is easily maintainable for you and any other designers that might come into contact with it.
I find the headings I’ve covered here help as a base to get started with, but feel free to add sub-headings and get more specific. Take a look at Brad Frost’s Atomic Design as a potential methodology for organising this part of a design system.
Planning a style guide
Before you code a single line of your design system, you need to know roughly what parts you’re going to need for it. Early on in the project, when a client has provided the initial content and assets you’ll be working with, you should aim to establish the foundation of your design system with a set of wireframe sketches.
Wireframes are a style guide’s secret weapon. Taking time to sketch out all the screens in your product, including any specificUI design components you’ll likely need in the final product, means you’ll have a list of all the required elements and can start building a strong, informed design system.
Get a bird’s-eye view
It’s at this point I recommend finding a large physical work area where you can spread out your wireframe sketches, so they are all visible at once and you can get a broad view of the system you’re about to establish. Look over your sketches and notice patterns emerging. Perhaps a combination of elements appears together frequently, and could become a reusable module?
Also look for patterns that are trying to emerge. For example, a list of blog articles might take a similar format to a list of search results, but let’s say the elements are arranged in a different order. Perhaps changing one of the two to match the other will help the user read a pattern they have subconsciously learned elsewhere in your product.
I like to use a set of Post-It Note page markers to label all of the elements in my wireframe pages for reference. For example, a module like a breadcrumb that occurs throughout the sketches could be labelled ‘M01′. ‘M’ indicates it’s a module. The number indicates which module it happens to be in my system – the next module would be M02, M03 and so on.
The element itself could be repeated elsewhere, so this breadcrumb pattern might appear on a product page as well as a blog article, both labelled M01, so I don’t end up designing and building multiple versions of the same element when it comes to prototyping the wireframes.
After you’ve finished cataloguing and labelling the wireframes, it’s simply a matter of taking that catalogue of elements and modules and building them as a live HTML style guide. Think of it like an Airfix model. You have an instruction sheet (your wireframe sketches) and a set of labelled parts (your style guide) corresponding to the instruction sheet. Once you have a concept of what you want to create, you will know what parts you are going to need, and at that point you’re ready to start building your design system.
The best part of approaching design systems in this manner is that it enables you to rapidly produce new screens and components – each scenario is only a wireframe sketch away. The style guide reminds you of your existing components and patterns when drawing your next sketch. Once the sketch is complete, you are ready to build quickly with the wireframes as your instruction sheet, using the ready-made elements in your style guide.
After the guide is complete
Technically speaking, a style guide is never really complete; it’s an ever-evolving document that grows with your project. It’s impossible to know in advance every combination of elements, patterns and modules that will need to exist, beyond what you currently have planned. But that’s OK! True to the ever-changing nature of our web, a style guide can only be as complete as the current state of your product.
In its (mostly) complete state, a style guide is a reference for the over-arching visual language of the product you are building. It means you can visualise how new features might take shape, and the look and feel they adopt. It’s also a living library of tested elements and components that can be used to quickly construct new screens or parts of a product, making it the most efficient way to rapidly build projects on any scale.
It is essential a style guide is maintained beyond its initial conception. It must remain current, rather than being a snapshot of what the product’s design system looked like at a particular time. It should be the visual lexicon of your project – the entity you consult whenever a design decision is made after sketching. All new components and modules are made from its DNA, so from a user experience perspective, any new pieces will look consistent as part of the complete brand picture.
If you have never used a style guide in a web project before, try it on your next project and see the difference it makes in helping you design, build and prototype quicker. With practice, they’ll become easier to create, and you’ll even find patterns within your style guide that can be reused to speed up the process of creating the next style guide!
A useful style guide goes beyond the capabilities of a visual reference. It becomes your product’s DNA, from which every piece of current and future design originates to produce the consistent style and characteristics of the rest of the product.
This article originally appeared innet magazine issue 278; buy it now !