Design systems, style guides, and pattern libraries are all the rage lately. With similar goals of fostering a more consistent and cohesive design style, they can all be a valuable addition to your tool set. Many people, though, use the terms interchangeably when they are, in fact, different concepts. Let’s take a few minutes to explore their differences.
A few definitions
- Design system
- The comprehensive set of values, semantics, syntax, and context that form the foundation of a shared design language
- Style guide
- The physical or digital document that represents the styles, patterns, practices, and principles of a design system and teaches how to use it
- Pattern library
- An organized set of related, reusable components, often containing code examples, design guidelines, and use cases
- Component
- A self-contained and reusable pattern that represents a specific piece of interface or functionality
Design systems are a shared language.
A design system is the shared language among a team. At its core, a language is a system of communication. Programming languages let people converse with computers. Spoken languages enable a person to speak with anyone else who speaks that language. A design language gives your team’s design ideas meaning and helps your team communicate that meaning between each other. By using a shared language, it becomes easier to communicate ideas in ways that are unified and concrete.
Even if you have not intentionally built a design system, your team has one. Think of how you impart design concepts. Certain words define a specific type of interface element and certain components are expected to look or behave in distinct ways. Without even putting in the effort of documenting it, you all have a shared assumption of how things should work. (Without documentation, your shared assumptions may not always align neatly.)
To make your design language more consistent and defined, your team should build a style guide.
Style guides document systems.
Style guides are the physical or digital representation of a design system. By consulting a design style guide, a team member can begin to grasp the pieces and decisions that define that system.
Before the web, style guides mostly served to define writing and print design standards and styles. Books like the AP Stylebook or the Chicago Manual of Style still serve as the foundational resource for how writers and editors maintain consistency and define best practices at most major publishers.
Nowadays, digital publishers and product design teams build style guides to help cement their team’s design language. A style guide helps them to codify established norms, document existing patterns and processes, and more quickly get new teammates up to speed.
Style guides for digital design can encompass some or all of the following:
- Design principles: These basic tenets define the core values of your product(s) and team. Good design principles differentiate your products, define your values, and help determine successful outcomes.
- Best practices: These highlight the most effective methods, tools, and processes that your team chooses to implement.
- Brand style guide: A brand style guide defines how your brand is represented in different mediums. It may touch on how logo(s) should look, how you write the brand name(s), and what colors, fonts, and imagery match the brand style.
- Writing styles: Like print style guides, design style guides often have a section to define common grammar, preferred spelling for words with variants, brand voice, and messaging tones.
- Iconography: Whether you develop icons in-house or use a stock set, an iconography section highlights commonly used icons, how to implement them, and possibly even how to choose or make new icons.
- Imagery: You may have a set of stock imagery, an illustrator, or an in-house photography team. An imagery section helps define and catalog existing options for images, where to find more, and how to use them.
- Pattern library: A subset of your overall style guide, the pattern library is an organized set of interactive, reusable components that can be used to build out more complicated modules, pages, and templates. Pattern libraries often include example elements, sample code, variations, use cases, and considerations.
- Code style guide: Consistency is important not just in what your users see, but in what your team produces. A code style guide lays out conventions and best practices for producing maintainable, scalable code that’s easy for other team members to understand and reuse.
- Templates: Make sure no one has to start from scratch with helpful templates for documents, artifacts, presentations, and more. Templates help set a standard style and remove the friction of starting something new.
- Tools & Utilities: Share what software, plugins, apps, and techniques you use team-wide. Go deep and share the best preferences and configurations to save time getting new teammates set up.
- Further documentation: Write about how to contribute to the style guide, who was involved, where to get help and training, and anything else your style guide users might want or need.
Pattern libraries are a part of the whole.
As you can see above, pattern libraries are just a piece of the puzzle that can make up your style guide. They may constitute the largest portion of your style guide in terms of substance and use across your team, but they are not a substitute for an entire style guide.
When building a pattern library, you should consider the following for each pattern you add:
- Pattern name: Giving each pattern a name makes it easier to discuss and reference them. Meaningful names help people quickly grasp what the pattern may look like and how it may be used.
- Visual representation: What does the pattern look like? An interactive visual representation of the pattern can show different states (like active, focus, hover) and include other variations.
- Design elements: Add a downloadable design file that can be easily edited. Designers can then incorporate the pattern into their workflow more quickly.
- Code samples: Sample code includes the code that defines the semantic structure, visual style, and behavior for each pattern. For web-based libraries, this would be the HTML, CSS, and Javascript. In most cases, the CSS and Javascript should already be defined in existing stylesheets and scripts. Sample code should document how to apply those styles and behaviors.
- Variations: Some patterns have multiple variations. Show each of the visual variants, how to implement them, and what problems they are intended to solve.
- Use cases: Use cases define where and how to use patterns most effectively. They may even suggest alternative patterns for specific circumstances, good pattern combinations, and examples of when NOT to use the pattern.
- Considerations: Even the best patterns have tradeoffs or potential pitfalls. Including considerations can help tell your team why (or more importantly why NOT) to use a pattern in certain circumstances.
- Related elements: What patterns are similar to this pattern? What patterns commonly accompany this one? Is this pattern a part of a larger component?
Want to learn more?
So, that’s how you differentiate between design systems, style guides, and pattern libraries. Here are some great resources to get you started building your very own:
- Brad Frost’s excellent Atomic Design is a great in-depth starting point.
- Smashing Magazine has a great book on Design Systems written by Alla Kholmatova.
- StyleGuides.io collects articles, books, tools, examples, and more to showcase how to create great style guides.
- Emmet Connolly wrote about the full-stack design system.
- Josh Clark thinks the most exciting design systems are boring.