Why Your Team Needs Its Own Style Guide and Where to Start

Cross-posted from DIGITALGOV

My team at the Federal Reserve is about to launch our first style guide and now that we have gone through the process and created this valuable resource, I can’t imagine creating another app or website without it. Here’s why your team needs a style guide and lessons learned from our experience.

What Is a Style Guide?

Let’s start with the basics. A style guide is a reference document that can consist of styles, interactions, and user experience patterns and solutions that solve common and recurring design problems. Here’s what our guide consists of:

Our guide has three different sections:

• Design Elements: This section describes stylistic choices our team is committed to, including typography, color palette, logos and icons.
• Patterns and Interactions: This section contains best practices for solving coming design problems and tensions, from alerts to error messages and tags to tables. Design elements can typically be applied to the content in this section.
• Assets: This section contains other downloadable design resources we’ve created, like PowerPoint templates and SharePoint layouts, that don’t fit into other sections of the guide.

Within every section of our style guide, we answer the following questions about each topic:

• What does it (the design element, pattern or interaction, or asset) do?
• Why use it?
• How to implement it?
• When to avoid it?
• Best Practices for Accessibility?

Like other style guides created for the web, we’ve also included code snippets where applicable to each topic we cover.

Make It Your Own

Consider your team’s needs, preferences and context to create a style guide that works for you. Here are some tips:

• Lead with Language: While the three sections of our style guide – design elements, patterns and interactions and assets – might seem simple, it took many iterations to find clarity. Our team plowed through examples of existing style guidesExit Disclaimer to better understand how to organize relevant content and material. Some style guides were too complex for our needs or laced with unfamiliar jargon our team doesn’t use. We wanted everyone on our team to know where to go to find the answer to their problem – no middleman required. Simply copying and pasting using other people’s information architecture and labels didn’t work for our team, and it likely won’t work for you.
  

  After pursuing other style guides for structural ideas, pause and think about your team. How does your team communicate? Do you have a shared language around design and development topics? Does any part of your process, whether agile, learn or otherwise, need to be considered in the structure? Information architecture should be your first step, and don’t expect to get it right the first time.

You can also think about user testing your style guide, or particular sections, to confirm that your team is aligned with other departments. Would agency communications or public affairs be interested in editing or contributing? Is your guide easily accessible as judged by its copy?

• Provide a Design Education: Design can appear confusing and complicated – and even pretentious – for those that haven’t studied it. Your style guide is an opportunity to show how a streamlined design system can create clarity and showcase just how far design decisions can reach. If you reframe the project as a way to educate about design, how would your approach change?
  
• Integrate Other Design-Related Resources: Has your team hashed out its own set of design or experience principles? Does your agency have a writing guidelines or guidance on grammar? Where do you store your current assets – like photography and icons? Does everyone know where these files live? Think about other useful and existing resources to incorporate into your style guide.
  
• Reduce, Reuse, Remix: Our team has a set of user experience principles that explain what we do and how we approach our work. One of our tenants, “reduce, reuse and remix,” is easily my favorite. It’s not always necessary to build from scratch, and if we can reuse code, design or copy from existing places, we encourage each other to do so. Fortunately, there are incredible existing pattern libraries that take into account the needs and challenges of designers in federal government. The U.S. Web Design System, the USPTO UI Design GalleryExit Disclaimer and the CFPB’s Design ManualExit Disclaimer all helped us follow patterns where it made sense, but allowed us to get creative in solving design problems unique to our organization.

Instant Impact

Even though our style guide isn’t fully launched (yet!), I’ve already seen changes in our team’s productivity and communication. Why? Because at its heart, a style guide is a tool to better communicate. When communication is clear, productivity improves.

Resources, including your time, can also be used more effectively the launch of a style guide. Instead of spelling out every single design decision, it’s possible for teammates to reference the same guidelines. When you don’t have to delve into side conversations about when to use a radio button and when to use a checkbox, larger conversations about design can happen.

Once you have a style guide, it’s much easier to scale. You have a foundation to make products in a modular way, if you choose. Your style guide will help you build whatever is next.