Your team’s web designer just orchestrated the most pristine example of what a powerful and effective website should look like for one of your clients. It is a digital canvas that has been caressed with careful, deliberate brush strokes of vibrant color and crisp, clear typography.
The layout is composed with the perfect balance of contrast. The viewers’ eyes follow an intentional path designed to affect emotionally-driven purchasing decisions, beginning with the header at the top of the page and carving all the way down into the lonely depths of the website’s footer.
It is magnificent in its conception, and the client is absolutely electrified with excitement.
After receiving the client’s enthusiastic approval, it’s time to hand this magnum opus off to your team’s developer, who will meticulously translate this artwork into hundreds of lines of semantic markup that will be delivered over the network to millions of prospective consumers, who will undoubtedly be just as awed and inspired by this masterpiece as the client is.
But the team’s developer is drowning in work and cannot see an end in sight (a nice problem to have, by the way). What are you going to do? How will you ever get this masterfully envisioned work of excellence delivered to the client in a timely manner without sacrificing the quality they are so eagerly anticipating?
Cue in the team’s “go to” third-party web development firm. These dedicated code slingers exist for the sole purpose of lessening the burden of looming development deadlines. They’re ready to deploy their team of keyboard wielding wizards to lift the weight from your shoulders.
However—as good as they may be at what they do—sometimes they don’t share your team’s vision and determination. Perhaps your team wasn’t able to communicate the mission as clearly as it could have, and there are discrepancies between the design and finished product.
It’s not clear that anyone was at fault, but these things can happen. Our job as problem solvers is to seek out elegant and workable solutions. The client deserves the best we can deliver.
Rather than blame the hired help, maybe we can find a middle ground and mitigate some of the efforts between both teams.
In the scenario above, multiple people attempted to transcribe a static design into a digital format with HTML, CSS, and JavaScript. The way one person interprets a design element might not be the pixel-perfect representation of what the original designer had in mind.
Or, perhaps the third-party developers were working remotely, and communication became a barrier that hindered their consistency. Regardless of the ‘hows’ and the ‘whys’, there must be a way to reduce the probability of erroneous effort, right?
Enter the Style Guide!
Think of a style guide as being like a brand guide for a website. Your company has guidelines that describe its identity through the use of color choices, typographical rules, and logo treatments.
Your website can also benefit from having a single source of truth that dictates what each element should look like and how they should be used to compose a web page.
A selection of colors from Hubspot’s Canvas Design System.
The major difference between a brand guide and a style guide is that the development of a style guide should serve the purpose of gathering a collection of reusable elements that can be plugged into various parts of your website.
While a brand guide would show you a selection of colors and their related hexodes and Pantone values, the style guide would actually offer a class name for each of those colors that can be applied to any element within the markup of a page.
A brand guide might display the sizes and weights of the different typefaces the brand uses. The style guide would allow you to also apply a class to a heading that forces that heading to follow those rules.
An excerpt from Atlassian’s Design System.
Now that you know what a style guide is and why you might choose to add the production of a style guide to your workflow, how do you actually go about doing it?
There are about as many ways to accomplish the building of a style guide as there are ways of developing websites. A lot of it will depend on your preferred workflow. In the end, all that really matters is that there is a singular sharable collection of elements, so that there is no confusion on what a button should look like or how large a heading or subheading should be.
Perhaps your design tools offer plugins that can translate your design into a working prototype that you can pull code from. More likely, you’d build a complete webpage based on the original design to be used as a reference point for anyone working on the website’s development.
In Part 2 of this series, we will offer a more in depth look at how you might build a style guide.
Many bigger companies actually have complete design systems that are used across all of their products and services. For example, Audi Auto Group employs a design system that spans their website, mobile devices, and even the user interfaces within their vehicles.
Starbucks uses a design system that they call the “Starbucks Pattern Library” to ensure consistency across their products and services.
One thing that a large number of these design systems have in common is that they provide access to CSS libraries, React component libraries, and even have collections of icons that can be plugged into any of their websites with examples on how to use them.
Some companies, such as Airbnb, provide template libraries that you can import into Sketch, Adobe XD, or Photoshop to use for mocking up quick prototypes or wireframes.
There are many ways to develop a solution to this problem. These are just a few examples. But, a collection of prebuilt elements and fully fleshed out libraries of styled classes and markup, contained in a single sharable resource, is an invaluable tool in any web team’s toolbox.
The results of taking the time and putting forth the effort are clean, readable code, consistency across the board, and the satisfaction that there will always be a resource available should someone need to reference it when building a new page for your website.
Stay tuned for Part 2 where we’ll explore how to actually create a style guide for your website!
