What We’ve Learned About Design Systems Through Supernova’s Mapping Test

It's been a month since we launched the Design System Mapping Tool. While it's still live, we thought it would be a great opportunity to peek at the data from the Mapping Test and see what design system insights we could find.

We analyzed around 300 responses to uncover fascinating insights about design systems. From the definitive design system and its characteristics, to the impact of team roles and company size — we hope our findings provide a valuable perspective on building design systems.

The definitive design system — today

The Mapping Test helps categorize your design system with a set of scales. So the first order of business was to see what respondents chose as their design system. We sorted through all the data from the test and got the average definitive scales that reflect design systems today.

The definitive design system:

• Main Objective — Aims to help users maintain consistency in their work without strictly enforcing it.
• Deliverables — Emphasizes components and tokens, but also considers patterns, experiences, and their connections.
• Theming — Supports an intermediate level of theming that can accommodate multiple products or a few color themes.
• Governance — Is centrally managed but not completely closed off to other contributors.
• Structure — Centralizes all reusable components primarily in one system, with support from other tools.
• Focus — Expands documentation while maintaining focus on the health of the design system.

Distribution of scales

Main Objective

The Mapping Test revealed that consistency remains a top priority for design systems, with 96.8% of respondents indicating it as part of the main objective. But interestingly, a whopping 92.5% of respondents agreed their design system aims to balance consistency with experimentation with a majority 64.3% leaning on the side of consistency.

Deliverables

Components still reign supreme when it comes to design systems, with 86.4% of respondents reporting their design systems being more component-heavy rather than focused on patterns or experiences.

Theming

We were expecting theming support for design systems to be heavily weighted to the None or Basic side of the scale, but surprisingly it tilted the other way towards Advanced. This might indicate that design system tooling might finally be catching up to the advanced demands of designers and companies.

And while theming looks evenly distributed from the scales distribution, a closer look at the answers show that the biggest reported use case of theming was adapting to multiple platforms with a 62.4% agreement.

Governance

The responses highlight an interesting pattern in design system governance, where a majority (66.4%) leaned towards centralization, which we expected to be the case before diving into the data. However, the remaining 33.6% of test takers that saw their design system as more decentralized could indicate one of two things. A desire for more flexibility and autonomy among design teams within their organizations. It could also reflect teams not having the necessary resources, personnel, or design system in place to make it centralized.

Structure

When evaluating the structure of design systems, 98.2% of respondents either favor a single centralized design system or have something mostly central like a hosting code or some assets elsewhere, for example. However, a very small 1.8% prefers managing multiple connected systems, which typically demands substantial resources and coordination.

Focus

The Focus scale sheds light on the top priorities of design systems, with 95% of respondents keeping an eye on stability, even if expansion is their primary focus. Striking a balance between expansion and stability remains crucial for most organizations, as they aim to ensure consistent and reliable experiences for their users.

Navigating the influences on design systems

Along with the main test questions, we asked participants about their roles and company size to understand how different factors can impact a design system.

Developers view their design systems differently

Developers represented almost 20% of the survey respondents compared to designers’ majority of 67%. However, developers that were not part of a design system team showed the biggest variance from the average results.

You can mainly see this in the Governance scale, where developers were much more likely to view their design system as decentralized than the more commonly centralized design system. This goes along with our hypothesis that design systems don't cater to developers as much as designers and therefore they're less likely to adopt.

Design system creators and consumers face misalignment

Being part of the design system team seems to come with a certain amount of bias. Consumers and contributors outside the design system perceive their design system differently, which you can see in the previous Governance scale. Designers and developers who are not part of a design system team are far less likely to view their design system as centralized, with only 36% and 57.1% viewing it as such respectively. It could also indicate how decentralized design systems would not have dedicated personnel catering to the design system. Still, this varies greatly from 73.1% and 79.5% respectively of their design system team counterparts viewing their design system as centralized.

You can also see this in the Focus scale. We see that contributing to a design system is not the same as owning one, and you'd likely be much less focused on stability and maintenance.

The data shows that 85.7% of developers agree that expansion is their main focus, compared to 64.7% of developers within a design system team which is closer to the average. But this means that those working on design systems need more alignment with their consumers on their design system and what it's trying to achieve.

Does size truly matter? Yes!

We had a lot of anecdotal experience with huge companies having different needs and focuses when it came to design systems. Part of the goal of the Design System Mapping Tool is to test these hypotheses and knowledge to see if there is data to support them. And from the results of the test, we found that companies with 5000+ employees showed the largest variance in results compared to any other data point.

Naturally, the scale of a company has an impact on the scale of a design system. So when it comes to governing a massive design system, the results look a bit different. A completely decentralized design system would be a tough challenge to undertake. No 5000+ person company had a completely decentralized governance model. They also had a much larger 80.4% centralized preference compared to smaller company sizes.

The structure of their design system also skewed quite differently, with only 17.6% having only one design system being the lowest among company sizes. And also lends more evidence to what we touched on earlier with multiple connected systems needing more resources and a larger company to be able to sustain.

Other stats

We pulled together some other fun stats that you might find interesting:

The design system approval process

We were expecting an overwhelming majority of respondents to have more fleshed-out design systems, but to our surprise, only 65.9% of respondents have a centralized approval process for contributions. Meaning that although a minority, a significant chunk of design systems are either still not there yet, or they're targeting a more decentralized approach.

Dedicated design system teams

Only 59.2% of respondents have a dedicated team in charge of managing their design system, which lends more evidence to the previous point of a sizable portion of design systems being in their infancy and relying on passionate contributors.

Utilizing different color themes

The growth of dark mode and more accessible design could potentially be behind the significant 53.9% of design systems supporting multiple color modes.

Do teams have all the building blocks ready?

8.5% of people disagree that they can create experiences and patterns from the smaller composable building blocks provided by the design system. This could be a result of poor documentation or components, but in either case, it's useful for practitioners to sit with their consumers and understand what can and can’t be done.

Thinking outside the box

We weren't sure if design systems were at a point where they could loosen up on strict consistency rules and empower their consumers to experiment. But to our surprise, a significant 38.7% of respondents agreed that their design system encourages them to break the rules and create new patterns and experiences.

We hope you found these insights helpful. We're grateful to everyone who took the Mapping Test (which you can still take) to help shine a clearer light on design systems. If you're curious about anything from the data or have your own questions or hypotheses, reach out to us on Twitter. There's still so much to come with the Design System Mapping Tool, so stay tuned.