Why teams ignore their design system, and what the workarounds are telling you
When a team tells me nobody uses their design system, the first thing I ask to see is the workarounds.
Picture a company that spent a year building its design system, one shared kit of buttons, colours, forms and page layouts, drawn in the design files, built in code and written up in internal guides. Six months later, a designer on the checkout team is drawing their own date picker. When leaders spot this sort of thing, the usual response is to tighten up, by making the kit compulsory, putting someone in charge of checking and running another round of presentations about why it matters.
That designer is probably right. People who rebuild something that already exists usually have a reason, and it’s usually the kit itself, which was hard to find, out of date, or didn’t quite do the job. Treat the workarounds as feedback on a product and most of them turn out to be fixable. Treat them as bad behaviour and people stop telling you about them, so you lose the feedback.
That’s how our design practice approaches design system adoption. We measure it the way we measure conversion work, looking at use, correct use and trust rather than an adoption count that rises regardless. You can read more about our design system assessments.
Where the idea that people won’t use it comes from
Sparkbox, a US design agency, has surveyed design system teams every year since 2018, and getting people to use the thing has sat near the top of the complaints list every time. In the 2020 edition, 52% of in-house teams whose system was struggling blamed adoption, second only to being short of staff.
The same survey found that only 41% of in-house teams were tracking whether anyone used their system. So the industry agreed on its biggest problem while most teams had no numbers behind it, and the gap filled with a comfortable assumption that the builders got it right and everyone else was being awkward.
The referee argument, and what makes it work
Hence the call for a referee. In February 2026, Laura Klein, a product and UX specialist best known for her book UX for Lean Startups, argued in an article for the research firm Nielsen Norman Group that every design system needs someone with the authority to say no. She has a point, because small tweaks pile up.
Her own article adds a condition, though. She describes a design system team whose components were being ignored because its enforcers were inflexible and protected the system from any change. The team kept its reviews but made them faster, set clearer yes or no criteria and became willing to evolve the system based on what teams needed. Adoption rose once teams trusted that the system would grow with them.
She also describes the opposite problem, a system so loose that teams could do almost anything, which she says was nearly as bad as having no system at all. Her story backs having a referee, as long as the referee is quick, clear and open to change.
Why isn’t anyone using our design system?
In 2022, Sparkbox asked the designers and developers expected to use these systems what got in their way. Only 31 of them answered, so it’s a small sample, but they sounded like any frustrated customer. Three of the answers were about missing help and information.
- 39% said it was badly documented.
- 35% couldn’t tell what was current, what was broken and what was about to change.
- 19% had never been shown how to use it.
None of that is a people problem. If you can’t tell whether the official button still works, building your own is the sensible choice.
In July 2026, Nielsen Norman Group published a framework by Huei-Hsin Wang for checking how healthy a design system is. One of its six areas is support, meaning training, somewhere to ask questions and clear notes when things change. Wang points out that a component can sit in the library and still be invisible, simply because nobody told people it was there.
She also describes a common lopsided pattern. The team has built lots of polished parts, the work it enjoys most, while the help and the rules around them lag behind. The result is that people can’t find or understand the parts that exist, so they build their own.
Why design system adoption numbers look healthier than they are
Most teams judge success by counting use. Figma, the design tool nearly everyone now works in, records every time a designer drops in a shared component. Those numbers rise as long as anyone is designing anything, so they look healthy by default.
Three questions, not one
Wang splits being used into three separate questions. Are people using it? Are they using it properly? Do they trust it? A team can score well on the first while the other two slide.
The detach signal
The clearest early warning is something Figma calls a detach. A designer takes a shared component and cuts its link to the master version so they can change it, and from then on it stops getting updates.
On Figma’s own blog (so this is the vendor talking about its product), Veronica Agne, who runs the design system at US health technology firm athenahealth, says a detach usually means a bug, a missing feature, or someone using the parts in a way her team didn’t expect. When detaches piled up on one layout component, her team found a spacing fault and fixed it before anyone complained.
Then there’s how current people are. Nathan Curtis of the consultancy EightShapes suggested in 2017 tracking how far behind the latest version each product runs. A product can technically use a system while running a version that is years old.
Our article on design investment metrics covers the same trap more broadly, reporting numbers that rise whether or not anything got better.
The design system tooling gap is in the handoffs
zeroheight, which sells design system software, heard from 147 design system practitioners for its 2026 report, and 97% of those who answered a question about design tools use Figma to create their design assets. Most also keep a coded version of the kit and internal guides explaining it, and the trouble is the joins between the three.
In Sparkbox’s 2022 survey, 37% of system teams said keeping the design files and the code in step was one of their biggest headaches. Imagine the brand blue getting a touch darker. A designer updates Figma, the code keeps the old shade and the internal guides show a third. Every tool works fine, and the system comes apart in the gaps.
Design tokens were supposed to fix this. They are named values, like brand blue, that every tool reads from one place, but for years each tool stored them its own way. That changed on 28th October 2025, when the Design Tokens Community Group published the first stable version of a shared format, and the major design tools already support it.
A shared format helps, but someone still has to own the joins, and in zeroheight’s survey 3 in 5 teams said they didn’t have enough people to meet their goals.
How to increase design system adoption
Most of the fixes are small, and enforcing the rules comes last:
- Treat every detach as a message: find the most broken-off components and ask the people doing it why.
- Measure three things separately: track use, proper use and trust. Only the first comes from a dashboard.
- Score it with the people who use it: get four to eight people, product designers included, to rate it separately. Where builders and users disagree, you’ve found your problem, and it’s a small piece of user research in its own right.
- Label everything: mark each component as ready to use, on its way out, or being worked on. That alone answers the 35% who couldn’t tell.
- Have a simple rule for new additions: Klein’s version is that if a change would help three or more teams, it probably belongs in the system.
- Give the joins an owner: one named person makes sure design files, code and documentation agree at every release.
- Enforce last: making it compulsory works once it’s worth using.
How to tell whether the fixes worked
Whatever you change, it’s worth knowing whether it helped. In our design work we measure a design system change the same way we measure any other design work, and five steps do most of the job.
It starts with the outcome. Decide which number the change should move before you make it, whether that’s the detach rate on a problem component, how far behind the latest version each product runs, or how long new pages take to ship. Then record a baseline of where those numbers sit across the teams and products that matter, because without one a lower detach count next quarter tells you very little. In my experience the baseline is the step that gets skipped, because the system team is keen to get on with the fix.
Before the fix goes in, write down the hypothesis, in the form “We believe [change] will change [behaviour] because [evidence or insight], resulting in [outcome].” A hypothetical example, built on the Sparkbox finding, would be “We believe labelling every component as ready, on its way out or in progress will reduce detaches, because 35% of users couldn’t tell what was current, resulting in fewer one-off components and faster delivery.” If detaches fall, you know why, and if they don’t, you know which assumption to question.
Validation means tracking the same numbers afterwards and talking to the people who were detaching before you decide. A usability session with a handful of product designers will tell you whether the change landed far sooner than the dashboard will.
Attribution is where honesty matters most. Other changes ship in the same release, teams change and projects end, so a drop in detaches after a fix is an indication rather than proof. Saying so plainly is what makes the next report believable.
So what are the workarounds telling you?
Pull out last quarter’s list of broken-off components, find the five people responsible for most of them, and buy each one a coffee. Most teams can name their most popular component in seconds, but very few can name the one their colleagues trust least.
Which component would you least like to hear about? If an outside read on where your own system’s workarounds are pointing would help, get in touch with our design team.
Frequently asked questions
Why isn’t anyone using our design system?
Usually because the design system is hard to use. In Sparkbox’s 2022 Design Systems Survey, of the 31 designers and developers expected to use one who answered, 39% said it was poorly documented, and 35% couldn’t tell which parts were current, broken or about to change. Fix those before making it compulsory.
How do you measure design system adoption?
Measure design system adoption as three separate questions, as Nielsen Norman Group’s 2026 maturity framework suggests. Are teams using it, are they using it correctly, and do they trust it? Figma’s usage counts answer the first, broken-off components the second, and conversations the third.
What does detaching a component in Figma mean?
Detaching a component in Figma cuts its link to the shared master version. The designer can then edit it freely, but it stops receiving updates. Figma logs every detach, and lots of detaches on one component usually mean it has fallen out of date or is missing something designers need, such as a size, state or variation.
Should a design system be mandatory?
Making a design system mandatory works once it is easy to use, up to date and open to change requests. Before that, it mostly hides the workarounds. Nielsen Norman Group’s Laura Klein argues that every system needs someone to enforce it, and describes a team whose enforcement only worked once its reviews became faster, its criteria clearer and the system open to change.
Are design tokens a W3C standard?
Design tokens have a stable shared format, version 2025.10, published by the Design Tokens Community Group on 28th October 2025. The group’s FAQ says the format has not been through the official standards process run by the World Wide Web Consortium (W3C), though major design tools support it.
Sources
- Sparkbox, 2020 Design Systems Survey (agency-published, in-house sample for challenge questions n=56)
- Sparkbox, 2022 Design Systems Survey (agency-published, 31 respondents to the adoption barriers question)
- Nielsen Norman Group, “Your Design System Needs an Enforcer”, Laura Klein, 6th February 2026
- Nielsen Norman Group, “Design-System Maturity, A 6-Dimension Framework”, Huei-Hsin Wang, 10th July 2026
- Figma Help Center, “View and explore library analytics” (vendor documentation)
- Figma blog, “Design system 104, Making metrics matter” (vendor content, athenahealth Forge example)
- EightShapes, “Measuring Design System Success”, Nathan Curtis, June 2017
- W3C Design Tokens Community Group, “Design Tokens specification reaches first stable version”, 28th October 2025
- Design Tokens Community Group, FAQ (specification status)
- zeroheight, Design Systems Report 2026 (vendor survey, 147 respondents)