Frontend style guide miniseries, part one: Introduction

Welcome to part one of our frontend miniseries on style guides! In this first installment, we will be defining what a style guide is, how you can benefit from investing in one, and how to get started with this whole thing.

Defining a style guide

A style guide, or pattern library, can consist of many things and/or be defined in several ways. At its simplest form, it is a collection of reusable components that can be utilized in various areas throughout a web system. For example, you may have a “button” component…

What is a web design component?

A component can be defined as a graspable piece of web design presentation. In several web component vocabularies, a component, as a term, can have slightly different meanings due to the subject nature of creation. Typically, an example of a single component might be “main menu” which would define the visual presentation of the website’s main navigation system. If you were to take this one step further, one might define a “compound component” as the header presentation because the header presentation consists of a group of components: logo, main-menu, secondary/user menu, search bar.

Process overview

The technical process is focused on creating semantic, reusable, (ideally) platform-agnostic components that can be dropped into any existing digital system or content management system. It can also be a living thing and evolve and iterate with the creation of your new website. If you’ve paid a design firm to help craft your identity, say, in a typical print-focused fashion, it would behoove you to hire web design professionals to extend that print identity to the web.

A style guide starting list of components might include:

• Logos: variations of branding assets for use on the web, including lockup variations for different monitor resolutions.
• Typography: the typefaces that should be utilized to uphold your identity on the web. Perhaps you have print-based typography that would be cost prohibitive to carry over to the web (separate licensing costs) and you’re opting to utilize a web service to serve similar-to-your-print typefaces? Maybe you have no idea what your options might be? Style guides can help with all of that. Capturing what those typefaces are and how to use them is important—perhaps the most important aspect of your website and its creation.
• Color schemes: how color interacts on your site. Whether you’re seeking to mirror your brand print colors on the web or adding new values to augment your digital presence, adherence to a color scheme is important. Aside from the usability angle, color should be used to give the user a sense of expectation, of clear visual relationships to content, e.g., one may use blue to clearly identify URL-linked text from black paragraph text.
• Imagery: the balance of imagery to chunks of text is an important one to consider in authoring content. What tone should your imagery convey? How should it complement or oppose your content?
• Menu Systems: how should menu systems be presented to users? This is as much a result of parallel or prior information architecture work by a user experience specialist or other efforts around understanding web analytics data and how your users best consume your content.
• Action Items: buttons, link styles, call to actions; these typically relate to your color scheme and have a defined value assigned to reinforce expectation and usability.
• Icons: similar to imagery, iconography can be an important component to consider in user experience and your brand.
• Forms: inputs, text-areas, email and phone number fields; form inputs should be semantic and user-friendly in how they instruct a device in interpreting them properly. For example, an Email Address form item should be labeled as such opposed to being a plain text field that your mobile device then can’t interpret as email address. This is especially helpful for usability, screen readers, and for autofill form services (e.g., Lastpass, 1Password, etc.).

And from there, we could take some of those components and create compound components.

Those might include:

• Header: a header presentation might consist of the combination of a logo, menu, and search input components. How do several of the above components actually combine together?
• Paragraph options: paragraph with text-only or a paragraph with image layouts. How should images appear when left-aligned with a paragraph?
• Sidebar: if you have lots of ancillary content that needs to exist in the periphery, then a solid sidebar presentation might be just what you need.
• Footer: similar to a sidebar, the footer is best for periphery information related to site structure.

Why do you need a style guide?

The modern web is a fast-moving, ever evolving thing. Having a style guide assists you in ensuring consistency. A living style guide provides:

• Single authoritative source. A living style guide becomes the authoritative source for your branding, design and code. Too often, authority is spread across multiple iterations—multiple rounds of mood boards, wireframes, mockups/prototypes (not to mention written conversations including email or ticketing systems). These are all necessary pieces, but a living style guide serves as a final definitive source—one that should be authorized by the entire team including designers, developers and stakeholders.
• Quick iteration. Speaking of authorization, a style guide offers a faster way for designers and stakeholders to sign-off on components while the backend or API is being developed. Free from these constraints, it is faster to iterate and easier to digest in terms of approvals, allowing the whole team to more rapidly move through the design and prototyping phase.
• Speed of development. Along the same lines, style guide-driven development—particularly one that emphasizes a component-based approach—greatly reduces duplication of efforts. Re-usability is enforced rather than encouraged because of the authoritative nature of the style guide and the designed nature of the style guide makes it much faster to locate pre-built components.
• Scalability. A component-based style guide is also the strongest foundation for a scalable, maintainable frontend system. CSS is one of the worst languages in terms of scaling, and not only does the style guide-driven approach reduce duplication but it also can set establish a methodology for growing/pruning the design system over time (especially when paired with something like BEM).
• Testing. Although not required, an authoritative style guide can also become a litmus for automated testing. Jim Newberry has a great series on the different kinds of design testing available as it regards style guides.

Existing style guide systems

What are options and how to choose an existing system or going custom?

Everyone has their own approach to workflow standards, technology toolsets, and structure for a style guide. There are several widely-adopted open source style guide systems to choose from. Your project may favor a style guide that is dependent on your website’s CMS—utilizing its template files and theme components. It may be in your best interests to choose a platform agnostic style guide solution as a deliverable. In this scenario you would pay for the construction and design of a style guide that can be applied to your new site.

The best solution for your website/project can be determined by asking some simple questions.

• How often will your style guide need updating? If your goal is to have individuals on your internal team uphold and own the iteration and growth of this style guide system it’s important to determine this up front.
• How far should the reach of this system extend? Will the style guide be applicable to all digital projects and branding? Is there only one specific project that necessitates the creation of a style guide? Ultimately this depends on any existing brand guidelines.

Here are some options for creating style guides that we’re excited about and/or currently using:

KSS node

• Pros: This option might be the holy grail of an implementation solution for all web systems. Because KSS relies on CSS commenting to generate its style guide HTML and define components, it can be highly adaptability to meet the markup needs of any CMS or web system.
• Cons: If used effectively, this option might have the least amount of cons of the bunch. If you can match production website markup in the KSS style guide (use the same template files) this is a fantastic option.

Pattern Lab

• Pros: Though it is rooted in its own vocabulary and ethos, it remains one of the more popular options for good reason. It could be worked into an existing project, CMS, or exist as a completely standalone entity. The tried-and-true format of top component bar and easy-to-grasp vocabulary naturally falls on the more accessible side of the fence.
• Cons: It has its own vocabulary and architecture opinions that may not align or commingle well with your own.

Static HTML and your own frontend toolset

• Pros: Depending on the technical level of your in-house design team this can be a desireable deliverable because it is the least opinionated of the bunch. In this type of setup, we use a static HTML index file with semantic markup that strives for cleanliness and adaptability. This HTML combined with Sass-based design components can be more approachable and have less technical overhead to being used by in-house teams or less technical visual designers.
• Cons: This approach can quickly become out of date if developed as part of a website redesign. Meaning, as markup changes depending on your CMS it does not automatically get updated in your static HTML style guide.

But there are really so many options to choose from.

In conclusion

Style guides are wonderful things. Identifying your own needs allows for a scalable deliverable solution. Their creation seeks to unite the collected efforts of visual designers, front end engineers, user experience designers, and most importantly, your business/marketing goals in one transportable unit. The size, shape, and details are unique to you.

Read the rest of our Frontend Style Guide Miniseries:

• Part one: Introduction by Joe Tower
• Part two: KSS Node by Randy Oest
• Part three: Pattern Lab by Evan Willhite
• Part four: Discussion with Evan Willhite and Randy Oest