A design system maintains the visual and functional elements of IDX in one place. It may include a sketch library, style guide, pattern library, organization principles, best practices, templates, code snippets, and more. Creating and maintaining a consistent UI and UX across every part of your product helps your users intuitively navigate and successfully interact with different sections of your applications without confusion.

Design System Examples

Visit http://styleguides.io/examples.html for an extensive list.

Atomic Design by Brad Frost, https://atomicdesign.bradfrost.com/

Starting with atoms, the smallest module, to build molecules, and molecules to build organisms.

Spectrum by Adobe, https://opensource.adobe.com/spectrum-css/

Uses tokens (design variables) to define modules.

Polaris by Shopify, https://polaris.shopify.com/

It offers a section for content, with guidelines for the tone of voice, grammar, and copywriting tips.

Material Design by Google, https://material.io/

It's an adaptable system of guidelines, components, and tools that support the best practices of user interface design.

Atlassian Design, https://atlassian.design/

It's very detailed and composed of design patterns, code components, and a library of UI assets in Sketch.

Airbnb Design, https://airbnb.design/building-a-visual-language/

It consists of components that are “like elements of a living organism,” where a set of properties defines each component, with its own personality and function.

Lightning by Salesforce, https://www.lightningdesignsystem.com/

It's a professional and comprehensive guide to accessibility, components, patterns, utilities, design tokens, and more.

What's the difference between a style guide and a pattern library?

A style guide defines brand identity, design language, voice and tone, writing, and code style.

A pattern library—also known as a front-end style guide, UI library, or component library—defines reusable modules.

Design System Advantages

Design systems are essential tools for preventing chaos in modern web design and development.

They serve as 

Consistency

Ensure the same experience across all devices and resolutions.

A shared vocabulary

Is this component called a slider, slideshow, or carousel? Establish a shared vocabulary between everyone in an organization, including outside vendors.

Education

Provide helpful documentation to clients, stakeholders, and other disciplines and prove there’s thoughtful work behind IDX design and development.

Collaboration

All disciplines are forced to think of the greater good when they contribute to patterns.

Testing

A style guide allows you to view interface patterns in isolation, allowing developers to make cross-browser/device, performance, and accessibility testing easier.

Speed

Once the pattern library is established, subsequent design and development become much faster, saving time and money.

Commitment

Provides a rock-solid, future-friendly foundation for teams to modify, extend, and improve on; even if that future work looks totally different.

Design System Challenges

What treacherous challenges come with the territory?

Hard to Sell

It's difficult to convince those with a short-term, quarter-by-quarter mindset that establishing a thoughtful design system is a smart investment in the future.

Time

Aggressive timelines and finite budgets detract from the effort required to make style guides happen, even when teams are committed to the cause.

Auxiliary Projects

Treating pattern libraries as something separate from the core project puts them into the nice-to-have category and are dropped when the going gets tough.

Maintenance and governance

Style guides will be abandoned without a proper strategy for who will manage, maintain, and enforce them.

Audience confusion

Style guides can be misunderstood as tools useful only to designers or developers, which doesn't foster a culture of collaboration.

Style guide structure

It should be welcoming and useful for as many people as possible.

Lack of context

Without providing context, designers and developers don’t know when to use a particular pattern.

Lacking a clear methodology

Many pattern libraries are little more than loosely arranged modules.

Atomic Design (excerpts from Brad Frost's book)

A methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner.

1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages

Atoms

Atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional. They demonstrate all your base styles at a glance.

Molecules

Molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule. They give abstract atoms purpose.

Organisms

Organisms are composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface. For example, a header can contain a logo, navigation, and search form.

Templates

Templates are page-level objects that place components into a layout and articulate the design’s underlying content structure.

• provides context for molecules and organisms
• demonstrates how components look and function together
• focuses on structure rather than content

Note

Design systems must account for the dynamic nature of the content, so it’s helpful to articulate image sizes and character lengths for headings and text passages.

Pages

Pages show what a UI looks like with real representative content in place. This is what users will see and interact with; this is what stakeholders will sign off; this is where all those components come together to form a beautiful and functional UI. Pages are essential for testing how patterns hold up when real content is applied.

We must create systems that establish reusable design patterns and also accurately reflect the reality of the content we’re putting inside of those patterns.

Atomic Design Advantages

Atomic design provides a few key insights to create more effective, deliberate UI design systems.

The part and the whole

Quickly shift between abstract and concrete, moving from seeing the whole picture down to the smallest component. Atomic design is not a linear process. It would be foolish to design buttons and other elements in isolation, then cross our fingers and hope everything comes together to form a cohesive whole. Don’t interpret the five stages of atomic design as “Step 1: atoms; Step 2: molecules; Step 3: organisms; Step 4: templates; Step 5: pages.” Instead, think of the stages of atomic design as a mental model that allows us to concurrently create final UIs and their underlying design systems.

Clean separation between structure and content

The close relationship between content and design requires us to consider both as we construct our UIs, and atomic design recognizes the two very much influence each other.

What’s in a name?

Why introduce terms like atoms, molecules, and organisms when we can just stick with established terms like modules, components, elements, sections, and regions? Atoms, molecules, and organisms imply a hierarchy that anyone with a basic knowledge of chemistry can hopefully wrap their head around. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

Show, don’t tell: the power of interface inventories

Content audits are usually performed in the early stages of a website redesign process to take stock of all a site’s content. It’s a tedious process involving spreadsheets and caffeine, but all that hard work pays off. By the end of the exercise the organization’s content is laid out on the table, giving teams valuable insights into how to handle their content as they tackle the project.

An interface inventory is similar to a content inventory, only instead of sifting through and categorizing content, you’re taking stock of and categorizing all the components that make up your user interface. An interface inventory is a comprehensive collection of the bits and pieces that make up your user interface.

Conducting an interface audit

How do you go about conducting an interface audit? How do you round up all the components that make up your UI? The simple answer is screenshots. Lots of them!

Step 1: Round up the troops

it’s absolutely essential to get all members of the team to experience the pain of an inconsistent UI for them to start thinking systematically. For the interface inventory to be as effective as possible, representatives from all disciplines responsible for the success of the site should be in a room together for the exercise. Round up the troops: UX designers, visual designers, front-end developers, back-end developers, copywriters, content strategists, project managers, business owners, QA, and any other stakeholders. The more the merrier! After all, one of the most crucial results of this exercise is to establish a shared vocabulary for everyone in the organization, and that requires input from the entire team.

Step 2: Prepare for screenshotting

The interface inventory exercise generates a ton of screenshots, so naturally, you’ll need software to capture and display those screenshots. Online slide-building software like Google Slides to be very effective as it provides a canvas for free-form image positioning.

Step 3: Screenshot exercise

The interface audit exercise involves screenshotting and categorizing all the unique UI patterns that make up your experience. Bear in mind this exercise doesn’t mean capturing every instance of a particular UI pattern, but rather capturing one instance of each unique UI pattern.

Assign each participant a UI category. You may need to pair people or have participants document multiple categories, depending on how many people are taking part in the exercise. Once again, it’s helpful to have as many participants as possible since more people screenshotting will result in more thorough documentation.

What patterns to capture?

Obviously, the categories are going to vary from interface to interface, but here are a few categories to start with:

• Global elements: components like headers, footers, and other global elements that are shared across the entire experience.
• Navigation: primary navigation, footer navigation, pagination, breadcrumbs, interactive component controls, and essentially anything that’s used to navigate around a user interface.
• Image types: logos, hero images, avatars, thumbnails, backgrounds, and any other type of image pattern that shows up in the UI.
• Icons: icons are a special type of image worthy of their own category. Capture magnifying glasses, social icons, arrows, hamburgers, spinners, favicons, and every other interface icon.
• Forms: inputs, text areas, select menus, checkboxes, switches, radio buttons, sliders, and other forms of user input.
• Buttons: buttons are the quintessential UI element. Capture all the unique button patterns found throughout the experience: primary, secondary, big, small, disabled, active, loading, and even buttons that look like text links.
• Headings: h1, h2, h3, h4, h5, h6 and variations of typographic headings.
• Blocks: also known as touts, callouts, summaries, ads, or hero units, blocks are collections of typographic headings and/or images and/or summary text (see Nicole Sullivan’s write-up about the media object as an example of a block).
• Lists: unordered, ordered, definition, bulleted, numbered, lined, striped, or any group of elements presented in a list-type format.
• Interactive components: accordions, tabs, carousels, and other functional modules with moving parts.
• Media: video players, audio players and other rich media elements.
• Third-party components: widgets, iframes, stock tickers, social buttons, invisible tracking scripts, and anything else that isn’t hosted on your domain.
• Advertising: all ad formats and dimensions.
• Messaging: alerts, success, errors, warnings, validation, loaders, popups, tooltips, and so on. This can be a challenging category to capture as messaging often requires user action to expose.
• Colors: capture all unique colors presented in the interface. This category can be aided by fantastic style guide bootstrapping tools like CSS Stats and Stylify Me.
• Animation: animation is an elemental aspect of user interfaces, and should therefore be documented. This requires using screen recording software such as QuickTime to capture any UI element that moves, fades, shakes, transitions, or shimmies across the screen.

Timing is everything

It’s important to set time limits on the screenshotting exercise to avoid going down a rabbit hole that ends up lasting all day. The amount of time you allocate will vary depending on how many people are participating, but I find between 30 and 90 minutes to be sufficient for a first pass of an interface inventory.

Dig deep

Which parts of the site should participants capture in the interface inventory? Short answer: everything. Any piece of UI that is or could be managed by your organization should be documented. Areas like customer support, FAQs, reports, modals, 404 pages, and legal terms should not be neglected.

Step 4: Present findings

After a break, it’s time to discuss what's been captured. Have each participant spend five or ten minutes presenting each UI category to the group. Here’s where the fun begins. Presenting to the group allows the team to discuss the rationale behind existing UI patterns, kick-starts a conversation about naming conventions, and gets the team excited to establish a more consistent interface.

Naming things is hard. It’s fascinating to hear the inconsistent names designers, developers, product owners, and other stakeholders all have for the same UI pattern. This exercise is an opportunity to unearth and iron out disparities between pattern labels, and also establish names for previously unlabeled patterns. Once every category has been presented and discussed, all the participants should send their slides to the exercise leader. The leader will then combine everything into one giant über-document, which will soon become a wrecking ball of truth and justice.

Step 5: Regroup and establish next steps

With the über-document in hand, it’s time to get the entire organization on board with crafting an interface design system. Laying bare all your UI’s inconsistencies is a great way to make that happen! One of the most powerful benefits of interface inventories is that you can show them to anyone, including non-designers and developers, and they’ll understand why inconsistent UIs are problematic. You don’t need to be a designer to recognize that having 37 unique button styles probably isn’t a good idea.

A smaller, cross-disciplinary team will be going through the über-document and establishing the next steps for the design system. Once the gaps in the interface inventory have been filled, the working group can have some important conversations about next steps for the design system project. Some key questions for this group to cover include:

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

Benefits of an interface inventory

Creating an interface inventory can be quite an undertaking, but the benefits of making one are many:

• Captures all patterns and their inconsistencies
• Gets organizational buy-in
• Establishes a scope of work
• Lays the groundwork for a sound interface design system

Ask forgiveness, not permission

Despite all your efforts, the sound idea of establishing an interface design system and pattern library was shot down. What’s a responsible web team to do?

Do it anyway.

For the same reason performance, accessibility, and responsiveness are built into our products; a design system should be built by default. Interface design systems are a means to create great work for our clients and organizations. And to create the whole, you need to create the parts of that whole.

(Re)setting expectations

Unfortunately, we humans are creatures of habit, and stepping outside familiarity’s warm embrace is uncomfortable. We don’t like being uncomfortable. We must overcome our existing predispositions if we’re going to embrace our ever-shifting industry’s best practices and create successful digital work.

Redefining design

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. - Dan Mall

How did we get to the point where we sell and design websites like they’re static images?

Death to the waterfall

A team is tasked with making a website. Once the kick-off meeting dust has settled, a UX designer goes away, puts their head down, and eventually emerges with a giant PDF document detailing the entire experience. This monolithic wireframe document gets passed around to the project stakeholders, who sign it off after some feedback and suggestions.

The UX designer then passes the wireframes to the visual designer, who hops into Photoshop or Sketch to apply color, typography, and texture to the structured-but-sterile wireframes. Behold, a website design! Now for the feedback:

“This looks fantastic, and I think really hits the mark for what we’re trying to accomplish with this project. But…”

Once everyone has rambled off their wish list of what they’d like the design to accomplish, the visual designer retreats back to their tools to work on a redesign.

“I feel like we’re almost there. Could we just…”

Weeks pass and seasons change. Nerves wear thin, and the deadline date looms over everyone’s heads. Finally, the visual designer slips the approved design under the door. They scamper away, yelling, “Can you get this done in three weeks? We’re already behind schedule and we’re out of budget!”

The front-end developer picks the design off the floor. With one glance at the composition, a strange feeling—some combination of bewilderment, rage, and dread—washes over them. The front-end developer tries in vain to raise their concerns to the broader group but is quickly dismissed. It’s too late to make significant changes, especially since it’s already been approved. So the developer tries their best to make lemonade out of the lemony static comps. They bend over backward to create responsive layouts that still retain the integrity of the static comps, normalize some of the more blatant component inconsistencies, establish pattern states (like button hover, active, and disabled states) that weren’t articulated in the designs, and make some on-the-fly decisions.

The team finally launches the site. While no one says it out loud, there’s a tinge of disappointment in the air alongside the joy and relief of getting the project out the door. After all, the live site lacks the glossy polish that the comps promised to the stakeholders, and friction between disciplines has bruised some relationships.

Rather than a rigid, sequential waterfall process, a more collaborative process over time looks something like this:

Development is Design (this section really speaks to me)

When a previous employer discovered I wrote HTML, CSS, and presentational JavaScript, they moved me to sit with the engineers and back-end developers. Before too long I was being asked, “Hey, Brad. How long is that middleware going to take to build?” and “Can you normalize this database real quick?”

Here’s the thing: I’ve never had a computer science class in my life, and I spent my high school career hanging out in the art room. Suffice it to say those requests made me extremely uncomfortable.

There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still code, front-end development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many front-end developers, myself included, a severe identity crisis.

Organizationally, there is often a massive divide between designers and developers (or marketing and IT, or creative and engineering, or some other divisive labels). Designers and developers often sit on different floors, in different buildings altogether, in different cities, and sometimes even in different countries on different continents. While some of this organizational separation may be justified, creating a division between designers and front-end developers is an absolutely terrible idea.

The fact remains that HTML, CSS, and presentational JavaScript build user interfaces—yes, the same user interfaces that those designers are meticulously crafting in tools like Photoshop and Sketch. For teams to build successful user interface design systems together, it’s crucial to treat front-end development as a core part of the design process.

When you show stakeholders only static pictures of websites, they can naturally only comment and sign off on pictures of websites. This sets the wrong expectations. But by getting the design into the browser as fast as possible, you confront stakeholders with the realities of the final medium much sooner in the process. Working in HTML, CSS, and presentational JavaScript allows teams to not only create aesthetically beautiful designs, but demonstrates those uniquely digital design considerations like:

• flexibility
• impact of the network
• interaction
• motion
• ergonomics
• color and text rendering
• pixel density
• scrolling performance
• device and browser quirks
• user preferences

Crucially, jumping into the browser faster also kick-starts the creation of the patterns that will make up the living, breathing design system. More on this in a bit.

This is not to say teams must design entirely in the browser. As with anything, it’s about using the right tools at the right time to articulate the right things. Having the design represented in the browser in addition to other design artifacts gives teams the ability to paint a richer, more realistic picture of the UI they’re crafting. Teams may demonstrate an aesthetically focused design idea as a static image, and simultaneously demonstrate a working prototype of that same idea in the browser.