State of Design Systems: A Survey

How Are Design Systems Being Used?

I’m a big fan of systems! In my own work design systems have made it easier to make small design choices, focus on the overall experience, and collaborate more easily with developers. If you’re anything like me, you may have found yourself looking for resources to better understand, create and share design systems — in that process, you may also have found that there is a very diverse and overwhelming amount of tools, best practices and information on this topic. This made us wonder. How are others in day to day practice working on design systems?

Who is actually using design systems? How are smaller teams taking all of this guidance into their work? What’s working well? What isn’t?

In casually talking to designers about their experience, a theme began to emerge —design systems seem promising, but are often described as the luxury of larger teams with long timelines and abundant resources. Why is this the case?

What do design systems mean to teams? What tools are being used to support them? What’s working well in using systems? What isn’t?

To better explore some of these questions, we set out to survey and learn from the community. We heard from 55 digital product designers in the process. While this is a good cohort size to begin to unearth larger trends, it’s not big enough to be representative of the larger community. Nonetheless, the difficulty in being able to gather more data was a helpful learning and indicator of its own – at the time of this survey, it’s hard to find designers actively thinking about and interested in design systems.

Below are some of our findings and larger themes that emerged.

Survey Results

Profile of Design Teams Surveyed

Many of the designers we heard from work on cohesive, related products within a single company.

Design Project Types

A large portion (40%) work in smaller teams of 2–5 designers.

Team Size Distribution

Identifying Reusable UI Elements

Looking to glean how designers understand what constitutes a system, we asked respondents to describe the typical UI elements they reuse in their projects. The responses were stripped of stop words. Below is a word cloud representation, with scale denoting response frequency. Components, icons, colors and typography were the most commonly mentioned elements.

Do Designers Work Using Systems?

We asked designers this question directly, while leaving out a strict definition of “design system.” We provided a few versions of “Yes” and “No” responses to choose from (Yes — I maintain and extend an existing system, Yes — I create my own design systems, No — there’s another designer or team responsible for creating and maintaining a design system, No — I prefer to work quickly without a formal system). We also gave respondents the ability to provide their own response. Most respondents (76.4%) answered a form of “Yes”, though it is worth adding that — perhaps in this question more than any other — there is likely significant sampling bias in the self-selection of a voluntary, design systems survey. Another really interesting observation here was the variety of added responses used to describe respondents’ particular practice of applying systems.

Design Systems Usage — Variety of Answers

To help up-level the diverse responses above, we sorted through each answer and separated them into more distinct categories of “Yes,” “No” and “Other” (to account for responses like “I manage the people who create systems”). Looking at the responses in these buckets, 76.4% of participants said that “Yes,” they currently use systems in some form.

Design Systems Usage —Simplified

Further breakdown of the above data let us sort the “Yes” and “No” responses into more explicitly descriptive buckets. Many respondents (41.8%) said they create their own design systems, followed by those who extend an existing system (36.6%).

Tools Used in Managing Design Systems

We also asked designers what tools they actively use for creating and maintaining design systems. Sketch symbols and libraries were the most commonly used, followed by CSS + SASS. It was interesting to observe that although a less frequent answer, working in design tools “without a formal system” was still relatively significant. Lastly, in what is perhaps an opportunity to improve this survey in the future, users were allowed to add their own multiple choice responses. While outliers, the addition of responses like “Notebooks (hand written)” are indicative of a core issue of design systems — their definition is interpreted very fluidly, to the extent that it removes the utility of a system as a forcing function within a team. The intent with allowing flexible answers was indeed to capture the variety of meaning, but a takeaway from this data is that a more strict definition should be added in a follow-up survey, to dig deeper into the specific usage of current tools.

Finally, we also asked designers to share their general opinions on design systems, what’s working well, what isn’t, and what could be improved. Below are some takeaways from what they shared.

Where Design Systems are Succeeding

Added Value is Becoming More Clear

As teams are scaling design in Agile environments, designers are starting to see the benefit of investing in creating systems.

“I think they are the answer to all the challenges of consistent, agile design/development. ”
“…a great way to focus on the experience rather than the pixels.”
“They are extremely important for scaling organizations, and can help designers onboard quickly into an existing product and brand”

Advocates Leading the Way

While design systems remain an early prospect for some teams, dedicated champions of systems are the way to disseminate their value and establish best practices.

“Something that has worked well for designer buy-in is to explain and present how things could be created quicker within Sketch with our design system.”
“In order for this to be successful there needs to be company wide adoption and awareness of the system and a team who focuses on it needs to be set in place.”

Developers Are Involved Early & Often

Collaborating with developers is key to the success of design systems; having active support from engineering is an important part of the process.

“Having developers involved fairly early in the process has been helpful though it’d be better to have them involved more often.”

Shared Source of Truth & Better Communication

Once established, design systems become a central reference point for teams, enabling better distribution of patterns and establishing common language for components.

“Design systems are really helpful to keep the UI consistent and people [speaking] the same language”
“Can provide a source of truth to any designer working across our web properties.”

Improved Speed & Consistency

In addition to improved clarity, the consistency created enables designers to work faster as they pull from common guidelines.

“They allow me to work quickly. The system for the marketing site is just components derived from the brand guidelines that we can repeat often.”

Systems Evolving Over Time

Successful systems are designed and developed iteratively, and are a living representation of components that changes over time.

“I typically make them as I’m designing pages/screens and then organically updating as I go.”
“… a design system is a living document, and must respond to the changing needs of our users.”

Empowering the Team to Contribute

Teams that have succeeded creating design systems involve cross-disciplinary teams early on, encouraging others to actively contribute to its shape and language.

“Multidisciplinary team working together since the beginning (UX+UI+Front-End+Back-End)…”
“Having manager buy-in and early-as-possible input from designers and developers alike along with an agreed-upon, shared, and documented lexicon and vocabulary for the shared design system HAS worked well.”

The Challenges of Design Systems

Getting Buy-In Can Be Tough

Creating an artifact that manages process across teams is an effort that requires cross-functional conversations about benefits, best practices, and workflow. A lack of clear tools and methods can make convincing others more difficult, leaving designers to shoulder much of the burden on their own.

“I love design systems, the biggest hurdle is to get your organization on board.”
“Changing the mindsets of designers and engineers has been the hardest part about introducing a new design system to existing team. Transparency and communication is key.”
“[The] living styleguide [was] never fully implemented and never referenced by the dev team…”

Systems Are a Team & Process Challenge

At the heart of design systems are people. Ultimately, the way systems are built and how they are used is enabled by what is also their most important outcome — better communication and process. It is no surprise then that this is one of the toughest and most elusive barriers to creating systems.

“It’s really challenging to maintain and evolve a design system over time, especially if there isn’t a process in place around how the team collaborates to make these changes.”
“I also haven’t seen a design system successfully translate into development practices”

Documentation is a Big Challenge

Given the myriad tools and approaches to design systems, the daunting process is but one part of the challenge — where and how to capture the holistic system is a big question for designers.

“Communication and design system architecture seems to be the main challenge. I’ve often seen component libraries, or style guides rather than cohesive systems that define how the parts interact among themselves.”

A Value vs. Time Tradeoff

In making the case for design systems, teams need to balance the amount of time spent creating them with the sometimes unclear value those systems could bring. This can be a non-starter when the practice of building systems isn’t yet widely adopted or understood. Further, teams need to allocate time for maintaining a system as products evolve. Perhaps few feel this more than consultancies or agencies, who often cite not having enough time as the biggest reason for not building systems.

“It’s always a delicate balance between making a thorough system vs taking too much time to keep it up to date.”
“I just don’t always have the time to build one for the client. The system itself is its own project for me.”

A Sense of Restricted Creativity

There also seems to be a perception that creating systems restricts the ability to work creatively, and can prevent new and innovative design from challenging existing patterns.

“It restricts creativity a bit, the designer might have to subdue an experience because they are aware that a certain component exists.”

Hard to Maintain Irrespective of Team Size

Distributed methods and assets can make design systems difficult to scale in large teams.

“It’s really hard to maintain systems as teams grow and we onboard new people. Evolving the system is unclear, assets live in disparate places, and design decisions are made in silos.”

Interestingly enough, similar challenges are echoed in small teams, where system decisions might be less collaborative and more siloed.

“More feedback and collaborative decision making about the style would be great, our team is just too small for that.”

Design Systems Need to Be Prioritized to Succeed

In the midst of impending deadlines or a big product release, design or development work that isn’t directly seen by customers can quickly be de-prioritized. It’s easy to see how design systems work can be akin to any refactoring or cleanup efforts—unless perceived as mission critical, they can quickly be forgone.

“Has to be managed like a real product”
“Getting buy-in right now is good and bad; devs are on board mentally but haven’t been able to help us make the leap in the day-to-day work”

Steep Learning Curve

Ultimately, the biggest hurdle to designers seems to be a lack of established best practices, refined tools, and general guidance. When faced with a lack of time, team buy-in, and unclear resources, it’s no wonder designers sometimes opt-out of creating systems altogether. A lack of close collaboration with developers or knowledge of development patterns is also a likely challenge in designing “componentized,” scalable systems.

“Sooo overwhelmed by them. I don’t know the modular strategy to create a flexible design systems yet.”
“Designers often don’t understand how components in code actually work.”
“Knowing where to start and how to bring team into the same mindset seems to be the hardest thing”
“The learning curve is steep. A running baseline checklist of elements is always needed for the smaller, often forgot about elements that pop up at the most inopportune time.”
“It’s been difficult to find resources on best practices for starting design systems, modifying existing ones, or even what the different options are.”
“Developer buy-in and education about how to use components and other elements of our style guide has been a real struggle for our team.”
“[We need] some kind of framework to facilitate how to decide what should or shouldn’t become a component in a system.”

Design Systems, Looking Forward

What Can Be Improved

It’s clear that there’s a lot of room for improvement in how we create and share design systems. From the survey, a few key areas stood out as best practices to support design systems and the teams using them.

  1. Establish a strong statement of value for Design Systems and share it with your team
  2. Get buy-in early and continue to advocate for the system
  3. Adopt system building as an iterative part of the development process
  4. Create team guidelines for how and when to create system elements
  5. Establish a set of limited, shared tools to collaborate on the system
  6. Prioritize and manage Design Systems like a product or feature
  7. Collaborate with cross-functional teams to create and maintain the system
  8. Build systems iteratively and flexibly over time
  9. Incorporate shared documentation (live style guide, wiki, etc.)

Moving forward, a number of products out there (Sketch libraries, Invision Studio, Abstract, Adobe XD, Figma, etc.) are already working on better ways to support workflow and collaboration. It still stands, however, that while tools will make this easier, success will come from the processes and shared communication we establish in our teams.

A design system is, after all, only the output of strong workflow and a collaborative, streamlined team working together.

How You Can Get Started

  1. Start reading and learning about design systems. There are tons of resources out there on how design systems work, and how you can get started — below are just a few.
  2. Talk to your team about design consistency and communication in your projects, any challenges you see, and how you might begin working together to solve them. Start the conversation and keep it going.
  3. Begin experimenting with systems in a subset of your design work — try creating components on a new feature or screen you’re tackling. Continue to work iteratively on the components and start sharing some of that work and process with your team.
  4. Stay tuned! Tools and processes are actively evolving.
  5. Let us know what you think! Are you actively using design systems? What’s working for you? What isn’t?

Resources

(Update!) Figma’s Design Systems Site & Recent Meetups
A collection of resources and evolving reference for designers building systems

On the Current State of Design Systems in UX
A brief history of systems and overview of benefits

Selling a Design System at Your Company
How to get buy in

Brad Frost: Atomic Design
A methodology for creating design systems using atoms, molecules, organisms, templates and pages.

Atomic Design: How to Design Systems of Components
How to structure scalable components

Resources, links, references and articles on Design Systems
A collection of systems examples, articles, videos, specialists and more