The approach to designing web applications has changed a lot over the past few years. Nowadays, it’s typical not to design full pages but to create a system of elements and components instead that can be connected to build a page or shareable partial, which can also be referred to as a component. Using this workflow lets us create a flexible, logical and consistent interface system that can be described with a style guide.
You probably know something called a branding style guide, but this does not have much in common with frontend style guides. The former is mostly about logo variations, usage rules, and brand's color palette or typography. The frontend style guide, on the other hand, is a visually represented collection of described UI elements that’s accessible in an easy and clear way and is specific for particular application(s).
Those elements can not only be components like input fields, panels or navigations, but also colors or even spacings. In this example, you can see the Buttons section from Netguru’s style guide for netguru.co:
As you can see, we have a few variations of the button component: full color, outlined, and greyed out, which is less prominent. Each variation also has its hover state described in the style guide. Such collections offer many advantages for both designers and frontend developers. For example, a designer could work more efficiently and be more consistent by picking those already created elements to build pages or bigger components. A developer that’s new to the project could quickly learn what components have already been created and how they should be used.
Living frontend style guides are websites which represent your components using the actual code that will be also used in production. The major benefit of it is that the style guide is always consistent with the code. Then, if you need to change the style of any component, you just update those in the style guide and all of the elements on a website are changed consistently.
Of course, you still need a designer who will update the Sketch or Photoshop template that contains all the elements of a living style guide.
Every project is different and is made of other elements, so there’s no simple answer to this question, but there are some “golden rules” for popular applications, which will make your style guide more usable and worthy.
Having a color palette in the style guide helps designers create more logical and visually consistent elements that will fit components existing before, because you wouldn’t use new colors unless you really need them. It also makes it very easy for developers to create a list of color variables that will be used in CSS to keep the code DRY. In this example, you can see the Color schemes section from Netguru’s style guide for netguru.co:
Most applications are about consuming and sending data, mostly text data, so it’s pretty important to include the information about used typography. The best way to present such information would not only include the visual aspects such as colors, font-weights, and line-heights, but also the context that a particular font style should be used in, the Typography section from Netguru’s style guide for netguru.co is a perfect example of this:
Forms can be really hard to manage in a frontend with a poor codebase. Many times, I’ve seen a combination of Bootstrap and custom styles for forms. Usually, there were also many variants for every input that only half of them were actually used. This can happen when you have no style guide for forms, and every form looks different.
Imagine that on some designs there are inputs with a 6px vertical padding, and on another design, there’s an input with an 8px vertical padding. Let’s assume that it happened because a designer wasn’t precise, and those inputs should actually look the same. A frontend engineer would probably create styles for both of them, doing away with the unnecessary code for the additional variant of input and inconsistent designs. Imagine what the creation of those designs would look like if a style guide existed – a designer would go to the Forms section of a style guide, and if the input they needed existed there, then they would copy-paste it. The effect would be consistent designs and a simpler codebase. Unless there’s no input fit for the designer’s needs, because then they would need to create a new variant of input and add it to the style guide.
Here you can see the Forms section from Netguru’s style guide for netguru.co:
Our style guide should, of course, contain a list of already created and made available components that we could use for designing pages and other components and those components could serve nearly any purpose, for example:
Ideally, every component should have a specification including instructions for correct implementation, a code snippet and, of course, a visualization.
If you have many components in your style guide, it might become harder to find the one that you need and manage them, and this is where a living frontend style guide comes in.
As we have already mentioned, living frontend style guides have many benefits. One of the benefits is the ease of creating the navigation for them (it’s not a graphic file, but a real website made with web technologies) to make them manageable and easily searchable.
We’ve already told about a few advantages of having a frontend style guide, but nowadays, most style guides are living style guides, and we also recommend that you use those. Let’s see the benefits of using living style guides:
When you can see all elements together, it’s easy to notice something that’s inconsistent and should be changed/removed or to add a new element that’s visually compatible with the rest.
You can include combinations of your components in your style guide, and each time you change one of the components, you can quickly see if any of combinations look broken.
This is rather a benefit of taking the atomic design approach, but this is what a style guide forces you to – writing modular, DRY code.
When you go to your style guide and see that there are components that you haven’t seen on your website/app for a long time, then there’s a large probability that you don’t need them and can remove them to save some bandwidth.
It works especially if you have some bigger combinations of components in your style guide. There are situations that you change some component’s styles, and it looks pretty good on its own, but in conjunction with other elements, it’s not the same. With a well-written style guide, you can easily spot inconsistencies before deployment.
Each time that a new frontend developer or a designer is engaged in the project, they have to spend some time on understanding what’s going on in the project, what has already been created, and how the pieces work together. Looking into a style guide can speed up this process a lot.
Estimations will be easier because developers/designers/clients (everybody benefits!) can quickly check which components have already been created and which haven’t when they’re planning a new feature.
This one applies only to living style guides, where the code for creating components in a style guide and on a production server is exactly the same.
Having a frontend style guide, especially a living style guide, brings a number of benefits to designers and frontend developers, making their work much more efficient at very little cost – the cost is defining and updating the guide. What we get is a cleaner codebase, reduced probability of bugs occurring, and more efficient work of both designers and frontend developers. Engineers are not the only people who will benefit from a style guide – project managers and clients will also be happy to have it, since estimating processes will be much easier, when you can see all created components in one list and check what has already been done and what hasn’t.