Designers are tasked with making more products, services, features, content, and functionality for more people, who are accessing our interfaces in more contexts, on more devices, on more browsers, and in more environments than ever before. This flood of “more” isn’t going away anytime soon, so we need solid ground to stand on.

That’s where design systems come in—they provide a mental model to help us think about user interfaces in a more systematic, hierarchical way so we can create thoughtful UIs and their underlying components at the same time.

If you want to know all there is to know about design systems, there’s no better person to talk to than Brad Frost—he wrote the book on them. So, we did just that.

Brad Frost

What is your definition of a design system? What are the most crucial aspects?

Naming things is hard, which turns out to be one of the big things design systems try to address. What teams name their components, animations, and other design ingredients is a big challenge, so a design system can help establish a common vocabulary between everyone in the organization. Turns out, the definition of “design system” is actually one of those terms that’s tough to pin down.

I tend define a design system as the official story of how an organization designs and builds products. That story can include ingredients like design principles, UI components, UX guidelines, code standards, processes, design toolkits, code repositories, resources, and more. What ingredients are included in an organization’s design system depends on what they need in order to create successful work together.

“A successful design system accurately reflects the real needs of real applications.”

Why is building and maintaining a reliable design system so challenging?

There are so many speedbumps that can prevent a design system from taking root at an organization. I’ll walk through some of the things I’ve seen:

A company’s culture needs to be properly primed in order to adopt a design system. This shift in thinking doesn’t just appear out of nowhere. A design system initiative needs both top-down and bottom-up support. That means the teams creating digital products need to be on board with design systems at a fundamental level. And that also means leadership needs to be on board and dedicate real money, resources, and time to the design system initiative.

A design system needs to be born of reality. That means the system needs to build real, working software. Anybody can create a component library in isolation and say “Okay, here’s our design system’s components.” While that might be a nice design exercise, a successful design system needs to accurately reflect the real needs of real applications.

A design system needs to fit teams’ workflows. If the system requires a massive departure from how teams are used to working, the system won’t be adopted.

Processes for updating and maintaining the system aren’t defined, which means that the system dies on the vine as soon as it’s created. Maintaining the system over time is extremely challenging. What happens when the horizontal tabs component gets a bug fix? What happens when that card pattern gets a visual design overhaul? What happens if the data table pattern gets a team 90% there, but needs tweaks in order to fully meet their needs? Establishing these processes before the system is complete is critical to its ongoing success.

Related: Your guide to design systems from the world’s leading brands

Brad Frost’s book, Atomic Design

In your book, Atomic Design, you say that people need to create more than a “collection of pages”—that it needs to be a thoughtful system. How does a team know when they have a system versus a collection?

Having a handful of pages gets a team somewhere. “Look, here’s what the homepage looks like. Here’s the contact page. Here’s the dashboard.” And so on. But even if those things look cosmetically consistent, that doesn’t mean that there’s a system underpinning it all.

A design system recognizes that the components that build up all those pages are interconnected and are built of the same stuff. So changing the card component on the homepage has ramifications for any of the other pages that include that card component. Components need to be designed to fit not just the needs of one single context, but rather a whole host of scenarios and content types.

Tell us about your book’s cover and the design of the text inside.

I wanted a quick way to demonstrate the concept of a hierarchical UI, so I made 5 symbols that represent atomic design’s 5 stages: atoms, molecules, organisms, templates, and pages:

I wanted to include those symbols on the book cover, but the portrait nature of the book didn’t lend itself to the horizontal logos. So I went with the simpler, bolder atom symbol.

I’d be lying if I said I was a good type designer, so the inner text design was really just a matter of finding some typefaces that looked good together. And as far as colors were concerned, I’ve been using this weird mustard/cream yellow, orange, and brown motif for years now, so it felt natural to weave that into the book’s design.

“Components need to be designed to fit with a whole host of scenarios and content types.”

What happens when a design system doesn’t address the problem you need to solve?

It’s important to define the processes for updating/modifying/extending patterns in order to ensure the system remains grounded in reality. If a team reaches for a data table pattern but that data table pattern doesn’t have a “zebra stripe” option, how does the team go about creating that pattern variant in a way that works with the grain of the system rather than abandoning it?

Inayaili de León Persson, who works at Canonical, created an absolutely amazing decision flow chart for how their team should address scenarios when a pattern should be modified or when a new pattern should be established. It explicitly defines how and when team members should go about creating and modifying patterns, which sets the system up for long-term success.

If full pages are already built out in template form, at what point do specific user needs change or influence the final design? And would those needs just affect this one product?

Of course user needs should always influence the design. Any good design process considers user needs throughout the entire process. That’s not just something you can sprinkle on at the end.

A successful design system strikes a balance between 2 perspectives: a high-level, system-wide perspective and an in-the-weeds, product-specific perspective. Specific user needs must be balanced with the fact these solutions need to be shared across different products. For instance, if you have a scientific audience that demands to have information packed densely on a screen, a product designer would want to accommodate that. But what if other products aren’t meant for scientific audiences? This is where systems thinking comes into play. A system designer would help create a data table component that has a few stylistic variants: one data table with adequate padding for non-scientific audiences, and one variant with less padding for scientific audiences. It’s possible to create systems that simultaneously address specific user needs while scaling those solutions to many products.

Where does design thinking come into play? Do you rely on both?

I love this post by Jared Spool about design thinking. Design thinking as a term helps evolve design from simply “making it pretty” into something that’s more about solving problems. An organization that’s adopted design thinking can create a design system to help put all that thinking in one place so it scales to every product making use of the design system.

“Any good design process considers user needs throughout the entire process.”

What’s the biggest advantage of building a design system?

From a user standpoint, they get a more consistent, cohesive user experience. From a design/development process standpoint, teams can launch higher quality work in a fraction of the time, effort, and cost.

Is the “smaller world” effect coming into play where teams are increasingly remote and encouraged to adopt these systems out of necessity?

I think so. I pretty much work exclusively on remote teams, so frequent communication and clear documentation become paramount for successful work to happen. Chatter in tools like Slack and side conversations in Hangouts and Skype can get lost in the mix. That’s why style guides, pattern libraries, and other guidelines are so critical to maintaining a consistent design system across a distributed team.

Related: 50 things only remote workers understand

What’s the next evolution of these systems? Will we see motion added to systems? Will these systems scale to VR, AR, voice, etc.?

Absolutely. There are a few different flavors of style guide out there: brand, design languages (like Material Design), voice and tone, writing, code guidelines, and pattern libraries. UI design systems will continue adding things like motion into the mix, and voice-based UIs will need to extend the voice and tone of the brand. It’s all interconnected, so having a solid set of design principles, brand assets, tone of voice, and UI guidelines are becoming increasingly imperative.

“Each screen isn’t a special snowflake, but rather part of a big, interconnected system.”

Over the last few years, how have things changed in terms of the way design teams work?

First, people are finally embracing the fact that design isn’t just about aesthetics. It’s also about flexibility, interactivity, performance, motion, ergonomics, and all the other factors that make digital design fundamentally different from other mediums.

Addressing those fundamental aspects of design means getting into the final environment much faster than we used to. That means getting front-end developers involved in the design process. That means iterating in the browser. That means design teams need to communicate and collaborate better than ever before. I talk about this in depth in chapter 4 of my book.

Lastly, designing in a team environment means that everyone needs to be contributing to an over-arching design system rather than simply focusing on their little corner of the universe. Once upon a time at an agency job I had, I was on a project where there were 8 distinct design teams for a giant brand/ecommerce site. The problem was that there wasn’t any sense of a style guide and there weren’t leaders holding the project together. The result was what you’d expect: 8 different button styles, 8 different typefaces, 8 different hero treatments, and so on.

Design teams now understand that each screen isn’t a special snowflake, but rather part of a big, interconnected system.