Pattern Libraries & Design Systems: Methods

November 10, 2017 // By Meghan Lien, Manjiri Acharekar

In the previous blog--Part 1 of this series--we were introduced to the theory behind the importance of building and documenting pattern libraries & design systems. We learned about the benefits and how they are essential for the future of products and organizations. In this second blog, we will learn about specific proven methods to create these pattern libraries & design systems.

Recap of Benefits

1. Speed up time and team’s workflow
2. Lead to cohesive and consistent experiences
3. Become a shared vocabulary by preventing chaos for designers, developers and future of the product
4. Make it easy for third parties to follow guidelines and maintain the look and feel of the existing products UI

Keep in mind, the secret sauce to all of this is ultimately team collaboration and communication. If people aren’t involved, the outcome will be negatively affected. Developing and maintaining a successful, cohesive UI Design requires effort across the organization.

Let's begin!

Interface Inventory

Before diving into the core of methods, let’s take a step back and first consider gathering an interface inventory. It’s recommended to perform an audit of all of your sites early on in the process so that teams can get insight on how to handle the content for the project. Though a laborious task, it reinforces the shared vocabulary aspect by requiring team input.

So, what exactly is an interface inventory? To simply put it, it’s a collection of all the components that your user interface is made of.

Inventory Workshop

In order to get started, it is best to create a workshop to gain input from the team as they deconstruct an existing design system. Engage a team that can consist of representatives from each of these groups:

• UX designers
• Developers (both front-end and back-end)
• Project managers
• Business analysts
• Quality assurance testers
• Other key stakeholders

Process

To get started we would conduct a workshop where team members would begin by capturing screenshots of patterns. They would then cut up these printed screenshots and reorganize them by grouping, labeling, prioritizing and archiving components. This helps generate momentum and align the group on next steps. There are several stages within this workshop, and the main benefits are:

• Identify differences
• Capture inconsistencies
• Get buy-in from the organization
• Decide which UI patterns will stay and which will be eliminated
• Reinforces a holistic design vision

Questions to Ask

• Which patterns should stay, which should go, and which can be merged together?
• What naming conventions should we use?
• What are the next steps to translate the interface inventory into a living pattern library?

Once the team has established what the new components are for the user interface and have received buy-in from the stakeholders, we move onto the next phase of construction of UI using a specific methodology.

The Atomic Design Methodology

Though there are many design methodologies out there, we suggest Atomic Design by Brad Frost because of its structural approach to Pattern Libraries and Design Systems. The atomic theory is that all matter in the universe can be broken down into a finite set of atomic elements. Similarly, interfaces can be broken down into a similar finite set of elements.

5 Stages

Brad Frost has taken cues from chemistry and defines these 5 stages that help create design systems in a hierarchical way.

1. Atoms: Functional components that cannot be broken down further.
   The building blocks of matter; these include form labels, inputs, buttons and basic HTML elements.
2. Molecules: Groups of atoms bonded together.
   These include simple groups of UI elements functioning together (e.g. Search form molecule consists of 3 atoms: form labels, search inputs, and buttons).
3. Organisms: Groups of molecules that include complex UI components.
   These groups form a larger section within the interface (e.g. Header organism consists of 3 molecules: logo, primary navigation menu, and search form).
4. Templates: Organisms and molecules applied to a layout.
   These are not related to chemistry but are specific to the design language of your application. They focus on the page’s underlying content structure vs. the page’s final content. Think of templates as the skeletal system of the final pages.
5. Pages: Instances of templates showing the real content on a page with text, images and final content.
   This stage brings the design system to life; it’s what the users will interact with when they visit the page. We also are able to take a look at how all the patterns hold up when real content is in place. If there are any concerns, we can go back and modify our molecules, organisms, and templates to better address our content needs. Pages are also essential for testing out the resilience of the design system as variations are established (e.g. one user has one item in shopping cart vs. another with 10 items). The underlying template is the same, but variations influence the construction of the molecules, organisms and templates.

When combined, these abstract atoms and molecules must result in UI elements that can be reused across the interface. It’s important to keep in mind that this isn’t a linear process, but a mental modal that requires evolution, iteration, and varying workflows to fully document an entire user interface.

Advantages

The main advantage of the Atomic Design method is to be able to quickly shift between abstract concepts (atomic elements) and concrete examples (pages). We can visualize and develop interfaces gradually—aligning with Agile methodologies. Establishing a holistic structure in this way makes it easier to navigate between the different UI elements, and rapidly produce solutions comprised of them.

Organizations often think of application elements in terms of: base layouts, components, and modules. This often results in designing elements in isolation—with the hope that they all work together cohesively. Adopting the Atomic method instead puts things into place in a more logical and hierarchical manner.

Design Systems & Their Components

There has been an increased demand in design systems to tie the whole product together, as organizations are realizing the importance of systematic design. Design systems are more extensive and larger than pattern libraries. They encompass all design elements while pattern libraries focus mainly on the components.

They include but are not limited to the following elements:

• Documentation of principles and processes
• Style Guide
• Writing / Editorial guidelines
• Resources
• Pattern Libraries

Principles

Principles (and rules) for your design system detail the information structure and different use cases of your product. These often include the organization’s: foundational ideas, web policies, culture, and mission (e.g. Material design guidelines). This documentation is critical and saves time explaining core beliefs, strategy and tactics to collaborators, organizational teams, and third-party vendors. Try to keep the documentation easy to follow by:

• Using clear instructions & labeling
• Providing images, animations or demos wherever possible
• Explaining its functionality in detail

Style Guides

When building a complex system, starting with creating a style guide is the quickest way to gain more knowledge about the product and the brand.

Style Guides vs. Pattern Libraries

Style guides and pattern libraries are essential tools to design systems. They establish a common language and also make testing easier. They are integral parts of both your organization’s process and workflow. A style guide usually consists of documenting brand identity and brand guidelines, whereas pattern libraries consist of documenting UI components like buttons, menus, accordions etc. Style guides directly influence the look and feel of pattern libraries and do not need to specify the relationship between data and content.

Style Guide / Branding Inventory

Leverage your interface inventory to start documenting the UI. Make it a cross-disciplinary tool so that it’s useful to the entire team’s organization--not just designers and developers. It should be a shared language used by everyone in the organization.

Style guide elements include, but are not limited to (e.g. Dropbox Branding Guidelines):

• Visual tone / voice
• Logo usage
• Colors & color combinations
• Typography
• Design rules (including do’s and don’ts)
• Collateral material (business cards and PowerPoint templates)
• Messaging (mission statements and taglines)
• Writing guidelines

Web / Editorial guidelines

Writing / Editorial guidelines provide guidance on specific writing patterns, vocabulary, and content voice or tone. It’s meant to communicate the brand’s personality and content strategy, and encompasses guidelines for writing only—not typography. It’s especially helpful for non-writers to have these formalized guidelines. There are commonly fewer sections to this guide, including but not limited to:

• Overview
• Media treatments
• Animation
• Navigation
• Icons
• Naming conventions and file directories
• UI patterns
• Writing guidelines

Guidelines for content writing:

• Subjective: These cover the target audience and voice/tone of writing style (e.g. casual vs. professional).
• Objective: These cover specific language and grammar choices (e.g. customized spelling of words, number and date rules, etc.)
• Suggested/ prohibited language: Some brands choose to either identify themselves with or avoid particular words or phrases—highlighting those that are specifically prohibited.
• Appropriate language: The guidelines here will specify what is and is not appropriate language, including profanity.

Resources

These are a helpful list of tools, links and downloads to improve the overall workflow within your design system. This centralized hub (for both designers and developers) provides access to files that help with the maintenance and development of the product. These can include:

• UI Kits
• Code components
• Web components
• Developers tools
• Other references: Books, web links, articles etc.

Pattern Library

A pattern library is component-based and more elaborate than a style guide. This is the holy grail for designers, developers and stakeholders. This is where the rubber meets the road in your design. Let’s dig a little further to understand the fundamental elements of a pattern library.

Pattern Libraries: Putting Atomic Design into Practice

The very foundation of pattern-based design and development is the pattern library. This consists of all the UI components that make-up your user interface. The best practice would be that a pattern library be a part of the design and development process instead of an afterthought. It makes the interface come together on a more solid and tested foundation.

The main purpose of pattern libraries is to enforce consistency throughout the interface and make maintenance seamless. There are other benefits including:

• Speeding up the team’s workflow and, in turn, saving time and money
• Establishing a shared vocabulary for everyone involved
• Providing helpful documentation to educate stakeholders and third parties
• Making testing easier
• Formulating a foundation for future teams and improve on over time

Before starting the design, make sure you have organized all your files and have a checklist ready. Pattern libraries evolve as the product develops, so you also might want to create a document explaining how to use everything--avoiding guess work for new designers in the future. Please keep in mind that the following is a guide and your UI requirements should be unique and modified based on the specific user interface you’re working with.

Using the Content Inventory

Using the initial inventory created in your workshop, it’s time to formally document everything. Be sure to select a tool that is easily scalable to all of the teams within your organization. We recommend robust software tools like Sketch and Invision. Here’s a list of what that inventory should look like:

Branding:

• Typography: Includes headings, body copy, lists, etc.
• Icons: Search icon, social icons, arrows, favicons, spinners, etc.
• Colors: showcase all colors presented in the interface
• Image types: Logos, Hero images, avatars, backgrounds, ads, etc.

Structure:

• Global elements: Headers, footers and other that can be considered as global elements.
• Navigation: Primary navigation, footer navigation, pagination, breadcrumbs, interactive controls any other navigation components.

Form Entry:

• Inputs: Standard, text areas, select menus, checkboxes, switches, radio buttons, etc.
• Buttons: primary, secondary, small, big, activated, deactivated, loading or text links.
• Messaging: alerts, notifications, validations, error, warnings, tooltips

Interactivity:

• Interactive elements: accordions, tabs, carousels, and other functional modules
• Media: Video and/or audio players
• Animation: UI elements that moves, fades, shakes, transitions across the screen. Use QuickTime to record and capture these elements.

Technical:

• Third-Party components: iframes, widgets, social buttons
• Code: HTML/CSS snippets, framework-specific templates, best practices, accessibility guidelines, naming conventions, standards, etc.

Best Practices for Documentation

Thorough documentation helps teams understand both context and usage of components to easily navigate through the library. Be sure to consider the audience who will be consuming this library—ensuring that the level of detail meets the needs of users from varying groups and skill levels.

Recommended list:

• Title: Keep this simple but descriptive. Agree upon names that make sense for everyone rather than only designers or developers.
• Description: Provide an overview of the pattern and what it does.
• Live Example: Showcasing a live pattern is more valuable than a static picture. These examples can demonstrate responsiveness, interaction, motion, text rendering, etc.
• Context: Give examples to show where and how a pattern is used—in context of the actual applications. Both screenshots and video demos are helpful.
• Usage: Showcase the usage rules (e.g. do’s and don’ts) and design instructions (e.g. sizing/spacing) so others can determine when to consider a particular pattern.
• Code: Provide code snippets for your integrated systems--HTML/CSS and or JavaScript.
  • HTML--markup syntax, structure, and accessibility mandates
  • CSS code--including LESS/SASS guidelines
  • Templating code--markup and any dynamic aspects of the pattern
  • JavaScript code to control a particular pattern
  • Implementation code to show how to pull a particular pattern into a backend system.
• Resources: These are provided as a supporting reference material to the components. This explains industry best practices and considerations for forms, tables, tabs, and more. The resources can include UI Kits, CSS tricks and/or maybe an article from a tech magazine.
  • Author(s) names: Including this provides direct contact information in case someone has questions or proposed changes to a pattern.
  • Meta data: This provides information such as: pattern status, current version, version history, compatibility, and dependencies.
  • Context: Link to parent, child, or related patterns—including usage details and testing ramifications of any change.

Conclusion

Collaboration with the entire team is critical when establishing a design system or pattern library. Using helpful methodologies like Atomic Design or others, building a modular design and reusable components ensures a strong foundation that is easily scalable for future product enhancements. Once these standards are in place, we can focus on designing holistic user experiences and consistency for customers. In our next blog– part 3 of our series—we will cover helpful tools to use in building well-constructed systems.

Reference design systems: Google (Material), Salesforce (Lightning), Microsoft (Fluent), Mozilla (Firefox), GE (Predix), and IBM (Carbon).

Categories // User Experience
Tags // Pattern Libraries, Design Systems, User Experience