Design Systems Report 2026
Welcome to the fifth annual Design Systems Report. This year, we heard from 147 design system practitioners across organizations of all sizes—from scrappy startups to global enterprises. As always, our goal is to provide an honest snapshot of where design systems stand: the wins, the struggles, and the emerging opportunities.
Want to download the report and read at your own pace?
Download PDFTable of Contents
Welcome
The industry is maturing—but so are its growing pains. Gartner's 2025 Hype Cycle positions design systems sliding from the "Peak of Inflated Expectations" into the "Trough of Disillusionment"—a phase where early enthusiasm meets the hard realities of maintenance, adoption, and organizational buy-in. Our data reflects this transition: while practitioners know design systems are essential infrastructure, many are struggling to secure the resources and executive support needed to sustain them.
The resource crisis is accelerating. Teams are doing more with less, and this year's data shows the strain. Understaffing, competing priorities, and a widening gap between stakeholder expectations and practitioner capacity are defining themes. Buy-in satisfaction dropped significantly year-over-year, from 42% to just 32%.
Adoption remains the existential challenge. For the fifth consecutive year, driving adoption and raising awareness top the list of biggest challenges. The tools and components exist—getting people to use them consistently is another matter entirely.
AI is here, but expectations are grounded. Unlike the hype elsewhere, design system practitioners are remarkably pragmatic about AI. Excitement is highest for documentation generation and process automation—the repetitive, time-consuming work that stretches thin teams even thinner. Conversely, AI-generated design is met with significant skepticism. As Gartner notes, "a codified design system will be essential to enable GenAI"—but our respondents are clear that AI is a tool for efficiency, not a replacement for design judgment.
Documentation is both the biggest pain point and the clearest opportunity. It's the task everyone knows is essential, no one has time for, and AI might finally help solve. The convergence of need and emerging tooling makes this a space to watch.
Despite the challenges, this remains a community of resilient, thoughtful practitioners building the infrastructure that makes consistent, scalable digital products possible. We hope this report helps you benchmark your own efforts, advocate for resources, and chart a path forward.
Who took this survey
This year, 147 design system practitioners shared their experiences – a passionate community spanning organizations of all sizes. Product design and UX professionals still make up the largest group (around 50%), but we're seeing a notable shift: engineering participation continues to grow, and specialized roles like DesignOps, accessibility, and content design are increasingly represented. This diversification reflects the maturing reality of design systems – they're no longer 'just a design thing' but cross-functional infrastructure that touches every discipline involved in building digital products.
Let's get into the data of who took this survey…
What role are you in?
| Label | 2026 | 2025 |
|---|---|---|
| Product design & UX | 50% | 53% |
| Software engineering | 20% | 12% |
| Management or leadership | 9% | 5% |
| DesignOps | 8% | 5% |
| Hybrid design & engineering | 8% | 3% |
| Content design | 2% | 0% |
| Accessibility | 1% | 0% |
| Design strategy | 1% | 0% |
Year on year, we’ve seen a balancing of roles across design systems. Not only are we seeing more engineers represented in our survey, but we're also seeing a rise in more specialized roles, such as accessibility, content, and designops, as well as management and strategic layers. As design systems mature, more voices are being heard within the practice.
Are you in-house, agency or freelance?
| Label | 2026 | 2025 |
|---|---|---|
| In-house and internal teams | 88% | 91% |
| Agency or consultancy | 7% | 7% |
| Freelance or self-employed | 5% | 2% |
It feels that in-house is still the home for design system professionals, especially those who spend all their time thinking about design system. However, there’s been a small uplift in freelancer and consultant design systems people. Perhaps a symptom of the job market of the last few years?
How big is your company?
The majority of the respondents are in companies with over 1,000 employees, with the largest proportion being in 5,000+ size companies. This supports the fact that design systems is gaining more traction in the enterprise world than it is in startups and small-to-medium businesses.
Where in the world are you located?
There is a feeling that design systems are dominated by the “global west”, supported by 90% of the respondents coming from North America, Western Europe and Oceania, with the leading number of respondents from USA and Canada. The Middle East, Africa and South-East Asia accounts for just over 1% together.
Your design system structure and team
Design system teams remain remarkably lean. The most common setup is still 1-2 dedicated people, often juggling design system work alongside other responsibilities. This 'doing more with less' reality is a recurring theme throughout this year's data. While some organizations have invested in larger, dedicated teams, they remain the exception. The gap between what design systems are expected to deliver and the resources allocated to them continues to be one of the field's defining tensions.
Do you have a design system team?
Year on year we’ve seen a growth in dedicated design system teams, and 2026 is no different, with a 5% jump in organizations who have dedicated resource for their design systems. It makes sense too, as previous years have shown that having a dedicated design system team strongly correlates to higher trust, adoption and team happiness.
| Label | 2026 | 2025 |
|---|---|---|
| Organizations that have a dedicated design system team | 83% | 78% |
What is your design system model?
- Centralized
- Hybrid
- Federated
Have you changed your design system model in the last year?
- Switched to hybrid
- Switched to centralized
- Switched to federated
What are the main issues with each design system model
Centralized
- Under-resourced
- Can't keep up with product team requests
- Siloed from product work
- Poor feedback loops
- Governance and contribution complexity
- Prioritization conflicts with product teams
- Multi-platform alignment challenges without dedicated engineering resource
- Documentation burden
“We are one small team and our DS is used by hundreds of teams. that makes it harder to manage and govern.”
Federated
- No dedicated time/resources
- Unclear ownership/accountability
- DS work deprioritized for feature work
- Managing communication across the whole product organization
- Bottlenecks waiting on busy contributors
- Getting good quality, non-use-case specific contributions
“Without a dedicated team working on the systems, they regularly fall out of date, or bottlenecks end up happening where teams are waiting for a new component to be released but the designer responsible for it is too busy on feature work.”
Hybrid
- Under-resourced core team
- Unclear ownership/responsibilities
- Conflicting opinions on DS direction
- Getting good quality, non-use-case specific contributions
- Difficulty getting dedicated contributor time
- Maintaining consistency across products and teams
- Communication and collaboration gaps
“In short: it's a war of responsibilities in large organizations.”
Feeling stretched as a team?
Documentation shouldn't be a full-time job. zeroheight's built-in AI tools write, build and audit your docs for you — and seamless integrations with Figma, Storybook and your code repos mean everything stays in sync automatically. Out of the box, from day one.
Try zeroheight today
What is the typical makeup of a design system team?
Average design system team size by company size
Average ratio of designers to developers in the product organization
Average ratio of designers to developers in the design system team
- 1-100
- 2
- 100-1,000
- 4
- 1,000-5,000
- 5
- 5,000+
- 11
- 1-100 employees
- 1:3
- 100-1,000 employees
- 1:11
- 1,000-5,000 employees
- 1:21
- 5,000+ employees
- 1:53
- 1-10 ds team members
- 1:2
- 10-20 ds team members
- 1:3
- 20+ ds team members
- 1:4
Most under-represented roles
Even though we're seeing more specialist roles, the actual number of teams that have them is still very low. Coupled with the data on under-resourcing, this is a worrying statistic, as it suggest that the design system team are having to split their time to cover as many functional areas as possible.
- Of centralized teams feel they don't have enough people
- Of hybrid teams feel they don't have enough people
- Of federated teams feel they don't have enough people
What makes you feel like you have enough or not enough people?
Understaffed teams
-
Layoffs
“The team of 10+ was all laid off but me – 'the design system is done, why do we need all these people?'”
-
Solo maintainers
“There's only one person working on a design system that supports multiple brands...”
-
Priorities shifting
“It was before, but the design system is not a company priority right now”
-
Competing priorities
“Tasks are split between managing the design system and product design, but ultimately it's technically not part of our day job to work on the system.”
-
Scope exceeds capacity
“It's a team of 8 designers supporting 5 different design systems and ~20-30 enterprise products”
Well-staffed teams
-
Managing scope
“There's always more work, on into infinity; we prioritize the most important things”
-
Focused mandate
“The design system isn't a primary focus at the moment so having a larger team isn't required”
-
AI efficiency gains
“Being augmented with AI tooling, our team of 4 is enough to get the job done”
-
Flexible team scaling
“As new projects arrive, we bring in additional people when needed”
Your tools
How satisfied are you with your design tools?
Not only do Figma have market dominance, but satisfaction with the tooling is very high. It feels like this might be a ‘solved problem’, but it will be interesting to see how new players like Penpot, as well as the rise in designing in code will play out over the next few years.
How satisfied are you with your documentation tools?
The satisfaction with documentation tooling is lower than design tools, which suggests that the design system documentation space is still maturing. However, satisfaction is still relatively high. Interestingly, those who use zeroheight report a 79% satisfaction rate, the highest of all the documentation tools.
Did you change tools in the last 12 months?
Tools seem to be relatively stable, with under half the teams reporting adding, dropping or switching tools. It suggests that the tooling space for design systems is on the road to maturation. Interestingly, the number of people who dropped tools were very low, suggesting that we’re not at a point where tooling budgets are being tightened?
AI tool adoption
Documentation platform changes
Moving to and away from Figma
A lot of the teams who reported adding tools talked about AI tooling, including Cursor, Figma make, Claude code and v0, with designers getting involved in code generation via vibe coding.
A similar amount of teams reported consolidating their documentation tools, often going to design system management tools like zeroheight and Supernova to manage their documentation going forward.
There are some teams who are still on the Sketch to Figma journey, finally making the switch this year. however, there were also a handful of teams who talked about moving from Figma to ‘non-artefact’ based tools like Cursor, Claude code and Dessign.
What are the biggest gaps in tooling?
-
Design-to-code parity and handoff
“The fact that design and dev still use different tools. they're getting closer to being connected but there's still a gap”
-
Documentation burden
“Documenting the design system is very time-consuming. we ended up doing the majority of our documentation in Figma because it's faster for us to do it there than trying to fight with documentation tools”
-
AI & LLM readiness
“AI hallucination. none of these AIs support a design system out of the box without hallucinating”
-
Figma frustrations
“Figma is a pain for design systems teams. it’s impossible to support the scale we need and the features they release are late and feel half baked”
-
Token management and syncing
“Our design tokens are not sync, and our design token architecture is not following best practice”
-
Automation gaps
“There are so many tools available... component updates often require making updates in multiple tools like Figma, Storybook, code, and doc site”
-
Metrics & adoption tracking
“I would like better tooling around metrics to accurately provide me data on how our DS is used”
Unsatisfied with your tools?
You're in good company — but it doesn't have to stay that way. zeroheight ranked highest for satisfaction of any tool in this year's report, with 79% of users rating it positively. Not only that, but zeroheight users also saw higher adoption and trust in their design systems.
Try zeroheight today
What's in your design system
Your token architecture
Despite parent/child and multi-brand design systems being a large part of the discourse over the last 12 months, only 21% of teams currently have cross-library aliasing set up within their system. It’s worth noting that just because the bleeding edge are a vocal minority, it doesn’t mean that adoption will be quick for new models of working.
How do you structure your tokens?
The standard setup of primitive + semantic layers in token architecture has become commonplace (only 10% operate with a single layer). However, a full three-tier system is only seen in just over half of the teams surveyed.
How stable is your design system?
Even though this chart has a positive edge to it, that over half systems are stable, only 8% describe their system as 'very stable', 34% say 'unstable', and another 10% say 'very unstable.' So nearly half the industry is working on shaky foundations. So, the systems are aging — but age alone isn't making them better.
Adoption, trust and communication in your design system
Why is your design system well adopted?
Why is your design system not well adopted?
| Reason | % |
|---|---|
| Component completeness | 79% |
| Communication and community | 59% |
| Company mandate | 55% |
| Documentation completeness | 45% |
| Automation workflows | 25% |
| Strong governance process | 24% |
| Reason | % |
|---|---|
| Lack of company mandate | 73% |
| Weak governance process | 55% |
| Component completeness | 45% |
| Lack of communication and community | 36% |
| Documentation completeness | 27% |
| Lack of automation | 24% |
The most interesting thing here when people self report why they do or don’t have good adoption is the disparity between these two lists. While weak governance is cited as a strong reason for lack of adoption, 3 out of 4 teams with good adoption didn’t mention it at all. The perceived importance of communication and documentation completeness also doesn’t quite add up.
How has the design system impacted collaboration between design and development teams?
Here is the chart you need if you are trying to prove the impact of your design system. You’re welcome.
How trusted is your design system within the wider product organization?
You might assume adoption is low because people don't trust the system. But trust is actually pretty healthy. 49% report moderate trust, 42% report high trust. Only 8% say trust is low or very low. So, people trust the system. They just don't use it. Trust isn't the bottleneck. Something else is.
What are the markers for a highly trusted system?
Interestingly, the things that seem to have no impact on trust are staffing numbers, team models or company size. It seems this is one of the areas where you can’t flat out blame resourcing (even if communication and system completeness are dependent on them).
Communication and community
Documentation and design completeness
Automation
Satisfaction with communication and community have high correlations with high trust in the system. this makes sense, as a strong community and consistent communication lead to greater understanding in not only the benefits of the design system, but also expectations around the design system
Another marker of high trust is completeness of documentation and design, which both being 20% more likely to foster high trust. if a system has what people are looking for and expect, they’re more likely to trust the use of the system.
Perhaps one of the more surprising correlations was token automation and trust. systems that have full token automation are 11% more likely to have high trust, suggesting that systems that seamlessly ‘work’ are more likely to have the trust of their consumers.
Maturity and adoption
System stability
One point to note is that the more mature and adopted a system is, the more likely it is to have high trust. systems that are older than 3 years have a tendency to have 12% higher trust, which makes sense, as they’ve had time to build trust. similarly, adoption is almost a direct correlation of trust. if you’re system is well adopted, it’s likely be trusted.
Another unsurprising marker is that the more stable a system is, the higher the likelihood of high trust.
How satisfied are you with how design system changes are communicated?
Considering the general feeling of satisfaction with communication in our design systems, it’s surprising to see the lack of forms of communication in the last question, especially considering how high communication and community ranks as a trust marker. Does design system have a ‘heads down and do the work’ problem?
Contribution and governance in your design system
Who can contribute to your design system?
While the good news is that 69% of teams are encouraging open and active contribution, it still means that over 2 in 5 teams are gatekeeping contributions to their design system. While trust might not be an issue on the consumption side, it suggests there might be a trust issue from the design system teams to the wider product org.
How many people contribute to your design system?
| Label | developers | designers |
|---|---|---|
| 1-10 | 69% | 82% |
| 11-20 | 15% | 11% |
| 21-50 | 6% | 4% |
| 50+ | 10% | 3% |
Overall, external contributions primarily come from developers more than designers. The number of external contributors is extremely low in most teams, and doesn’t scale with company size. Even at companies with 5,000+ employees, only 37% have more than 10 designers contributing to their design system.
How satisfied are you with your contribution process?
Satisfaction with contribution process is a mixed bag across the board. Those who are satisfied highlight the simplicity and scrappiness of their process, which suggests it isn’t particularly robust. Whereas those who are dissatisfied highlight that contributors are bogged down with daily product work, or that the quality of the contributions are poor.
How satisfied are you with your community building efforts?
Without resource, you’ll never have satisfaction. This shows with the highest rate of dissatisfaction across the survey being for communication and community building. And let’s not mince words, if you’re ‘neutral’ about community building, it probably means it isn’t being done well.
Measuring your design system
How satisfied are you with your ability to get buy-in for your design system?
| Label | 2026 | 2025 |
|---|---|---|
| Satisfied | 32% | 42% |
| Neutral | 28% | 35% |
| Dissatisfied | 40% | 23% |
It seems that our ability to get buy-in from leadership is getting harder, not easier, with dissatisfaction almost doubling.
Why is your ability to get buy-in for your design system?
Why are you unsatisfied with your ability to get buy-in for your design system?
-
Lack of leadership understanding
“Leadership has no background in design so they don't understand what 'buy-in' means for a design system”
-
Product team resistance
“Buy-in is mostly limited to developers, but designers are often not willing to use components as provided”
-
Lack of mandate
“We lack mandate from management - the use of our design system is encouraged but not enforced. it’s hard to convince developers to use it, because it’s not mandated.”
-
Can't prove the roi
“We have huge gaps in adoption, and have no metrics for tracking adoption so we're in a vicious cycle.”
-
Resource constraints
“We have a sizeable team, but we are unable to convince leadership that we are understaffed and need more resources”
Struggling to get leadership on board?
Buy-in satisfaction dropped from 42% to 32% this year — and it's not because design systems got worse. It's because proving their value is still painfully hard. zeroheight gives you the adoption data, documentation coverage and team analytics you need to make the case to people who need to see numbers, not vibes.
Try zeroheight todayAutomating your design system
Do you have any automation set up for your design system?
The lack of teams who automate their design system is at an all time low (down 8% from 2025). Why aren’t people wanting to speed up their design system delivery by automating the bits that can be automated?
What do you have automated in your design system?
Of the 37% who automate their design system, what do you automate?
Automate delivery
What in your Delivery is automated?
- Variable and token pipelines
- NPM bundling and releases
- Component code scaffolding
- Storybook publishing
- AI-powered testing and review
Automate documentation
What in your Documentation is automated?
- Code and prop definitions autogenerated
- Icon and token references dynamically generated
- Storybook story generation via AI
Automate communication
What in your Communication is automated?
- Autogenerated release notes
- Slack/Teams automation for messaging and release notes
Of these teams are satisfied with their automation
Satisfied teams
-
Time saving
“Automation has massively increased our speed of delivery, and frees up time for more important things.”
-
No more boring tasks
“The most mundane jobs are handled – it bypasses office politics and handles most things automatically”
-
Reliability
“One of our biggest concerns was reliability. having run our automations for almost a year, it’s been proven that the reliability meets our needs.”
Dissatisfied teams
-
Lack of resource
“Even thought we want to, we don’t have enough resource to build anything useful.”
-
Lack of speed
“Our lack of automation means it takes over a month to ship any changes to production.”
-
Repetitive, manual tasks
“We’re manually running scripts for tokens, manually deploying to NPM, and all our internal tools still need manual updating. there’s a lot of unfulfilled opportunity.”
What do you wish you could automate in your design system?
- Figma Variables to Design Token automation
- NPM bundling and deployment automations
- Visual regression testing
- Design token creation and naming
- Version control for Figma components
- Accessibility compliance testing
- LLM context generation
- Release note generation
- Design to code parity checks
- Autogenerating component specs
- Documentation creation
- Figma Code Connect automation
- Icon generation
- Documentation delivery (via plugins and chatbots)
- Code to design sync automation
- Automated asset generation
What would you do with all that time back?
The teams who automate their design systems are unanimous — it speeds up delivery and kills the tasks nobody wants to do. zeroheight connects directly to Figma, Storybook and your code repos, automates your token pipelines, and even helps you auto-generate documentation.
Try zeroheight today
AI and your design system
Are you using AI with your design system?
| Label | 2026 | 2025 |
|---|---|---|
| Yes, AI is built into our processes | 10% | 10% |
| Yes, we're currently experimenting with AI | 46% | 36% |
| No | 44% | 54% |
Compared to other industries, it still feels like AI usage in design systems still relatively nascent. However, since last year more teams are experimenting with AI in their design systems, which shows progress. Interestingly, the amount of teams baking AI into their processes has remained at the same level.
How well is AI living up to the potential?
Most teams are still on the fence about AI’s impact when it comes to design systems. However, of those who have decided either way, it seems that the positive is slightly outweighing the negative.
The positives and negatives of AI with design systems?
The good
-
AI as a resource multiplier
“The company refuses to hire more designers. AI is the first hope we've had at keeping up with the pace of work.”
-
Automating repetitive tasks
“It's a time-saver for first drafts, ideating, summaries, filler content generation, and automating predictable communications.”
-
Code generation
“Moving away from design-to-code and static mocks! i think code generation (esp of components) is not very useful but using the actual code components as the design medium is a paradigm shift”
The bad
-
The quality isn't there yet
“It's not good enough, to be frank... i spend more time cleaning up after AI than i would ever save using it.”
-
The ethics of AI
“Personally, i don't really like AI because of the environmental issues, the issues with copyright and the general slop it produces.”
-
The ic vs stakeholder expectation mismatch
“There are of course some advantages, but a lot of hype that doesn't always feel worth it... individual contributors and stakeholders seem to be on very different wavelengths due to the marketing and influencer output around vibe coding and AI tools generally.”
Your design system should be AI-ready. is it?
Only 12% of teams are using AI for documentation delivery — but 57% wish they were. zeroheight's AI suite is built for exactly this: Write with AI, Build with AI, and an AI Assistant that audits your existing docs. Plus a native MCP so your design system works directly inside the AI tools your team already uses. No setup required.
Try zeroheight today
Until next time...
Thank you for taking the time to dive into this year’s Design Systems Report. It was put together with care by the team at zeroheight — a design systems management platform that acts as a single source of truth, helping teams tackle many of the challenges uncovered in this year’s report.
Have you tried zeroheight recently?
zeroheight is AI-ready, with a zeroheight MCP that hooks your documentation into AI tooling, in-built assistants for both viewers and editors, and integrations with Slack, Teams and Figma.
Measure analytics and adoption on both the documentation, and directly in your codebase, so you can show the execs how successful your design system is.
zeroheight does design token automation out of the box, so you can have your variables smoothly transforming into tokens directly in your code repo
