Large organisations running more than one digital product or platform (a website, a mobile app, a customer portal etc) usually have a design system in place. In most of them, the design system is not yet adopted across all of those platforms, meaning not every team builds from the same shared components. The website team might build from the design system while the app team still designs and builds its own buttons, forms and menus. The same work gets done twice, and every release takes longer than it needs to. Government agencies, banks, insurers, retailers and utilities are all in this position.
Only 7% of organisations say their design system is fully adopted, and 38% say it is barely used (zeroheight Design Systems Report, 2026). So the money has been spent, the components are sitting there, and the teams who were meant to build from them are making their own instead.
Designers create the visual designs in a design tool like Figma. Developers then build working versions in code on platforms like Storybook, using the visual designs and tokens (the named colours, spacing and type values) in Figma as the guide. A design system is the shared set of finished components both of them build from. A component is a reusable part of a page or feature: a button, a form field, a date picker, a menu, an alert.
Design system teams have named the same hardest problem five years running: getting people to use it
Driving adoption (getting designers and developers across the organisation to build from the shared components) has been the most reported challenge for design system teams for five consecutive years (zeroheight Design Systems Report, 2026).
In the same survey, 22% of organisations say their design system is widely adopted and 31% say moderately. At an insurer, that can mean the website team builds its quote pages from the shared components while the mobile app team builds its own buttons and forms. When your team plans its next release, it helps to know which of the components you need already exist in the design system, and which your team will have to build.
Separate teams run the website, the app and the customer portal, and each one plans around its own deadline
In a large organisation the website, the app and the customer portal are typically run by different teams, with different managers, different backlogs and different dates to hit. That separation is what lets each digital product or platform move at its own pace.
Using the shared components means relying on the design system team, or another digital product team, to have built and finished the component you need. If it is not ready, your release date slips and your own manager has no way to fix it. Building your own version keeps the work inside your team, and with a release date close that is often the sensible call. When the website, app and portal teams each make that call, the organisation pays for three versions of the same form. The cost repeats too: the next time the form needs a new field, a compliance update or an accessibility fix, it gets designed, tested and shipped three times over.
A dedicated design system team now looks after the shared components in 83% of organisations, up from 78% the year before (zeroheight, 2026). The design system team usually has no say over the website, app or portal teams' plans, so it has to persuade them to use the shared components.
Teaching teams how to use a design system is usually the first work to be dropped
Running a design system well means doing three kinds of work at the same time:
building the components and keeping them current
teaching designers and developers joining a team where to find the components and how to use them
staying close enough to the website, app and portal teams to hear what they need next
Sparkbox (an American consultancy that builds design systems) calls these three kinds of work "evolution", "education" and "engagement".
In a struggling design system, the design system team spends its time building components for the next project and has little time left for teaching or for talking to the other teams. New designers and developers join the website, app and portal teams without anyone showing them what already exists, so they build what they need themselves.
A well-built design system goes unused when the people who should be building from it were never shown how. 61% of design system teams report being understaffed (zeroheight, 2026), and when a team is short, teaching is the work that gets dropped.
Teams rate the design side of a design system well above its code, documentation and accessibility
When design system teams rate their own design system, the visual designs in Figma score well and everything built after them scores lower. Satisfaction runs at 72% for design, 54% for code, 45% for documentation, 44% for accessibility and 20% for interaction patterns, the rules for how components behave when someone clicks, opens or submits them (zeroheight, 2026).
Those scores follow the order a release is built in. The visual designs are rated highest, then the code built from them, then the documentation that tells a developer how to use each component. Accessibility and the detail of how components behave are rated lowest, and those are the parts a team meets late in a release, when the deadline is close.
So when a team estimates a release by looking at the components in Figma, it is looking at the best-rated part of the design system. Before you agree an estimate, check the code, documentation and accessibility work for each component the release needs, as well as the visual design.
Developers build their own components when that is quicker than finding the shared one
A developer who cannot quickly find the component they need will often build one. More and more, the quick route is an AI assistant that generates a component from the visual design in Figma. It takes minutes and it looks right, but it is one more version of a component the organisation already has.
The colours, spacing and type sizes in the visual designs have to match the same values in code. 60% of teams keep them matched by hand, with no automation, and another 29% automate it in one direction only (zeroheight, 2026). Where the matching is done by hand, someone spends time on it every release. That makes building from the shared components slower, and the AI-generated version stays the quicker option.
Making the shared components the fastest way to build is worth more than a rule telling teams to use them. That starts with a designer or developer being able to find quickly whether the component they need already exists.
What your team can find out before it plans its next release
Your team can answer these four questions in an afternoon:
Of the work your team shipped last quarter, roughly how much came from the shared components and how much did your own team build? The answer tells you how much of your next estimate can rely on the design system.
Which other teams in the organisation build the same kinds of things you do, and when did you last talk to them about what they have already built?
For the components your next release depends on, is only the visual design done, or are the documentation, the accessibility work and the error and empty states done too? Error and empty states are what a component shows when something goes wrong or when there is nothing to show yet.
Who would you ask if a shared component did not do what you needed, and how long would an answer take?
A component one team builds for its own release can be added to the design system later
Sometimes a team under pressure has to build its own component to hit a date. When that happens, build it properly, with tests, and bring it back to the design system team afterwards. Brad Frost (the web designer who wrote Atomic Design) describes what happens next. The two teams decide together whether the component stays a one-off for that digital product or becomes a shared component every team can use (Brad Frost, 2019). If the design system team has no way to take that component back, teams stop asking and build around the design system altogether.
Every team that adopts the design system makes the next release faster
A design system speeds up a release only when the team doing the work builds from it. Each team that adopts it stops rebuilding buttons, forms and menus that already exist, and the time saved grows with every website, app and portal team that joins.
Adoption grows when the components are:
easy to find
finished beyond Figma
taught to new starters
backed by someone who answers when a component doesn't fit
You can start with your own team's next release. Before you plan it, check which of the components you need already exist in the design system, and build from those first.
Learn from us
Join thousands of other Product Design experts who depend on Adrenalin for insights
