Large organisations often run more than one digital product or platform: a public website, a mobile app or a customer portal, etc. Paying for the same design and build work more than once is common, and very few brands know what it is costing. Government agencies, banks, insurers, retailers and utilities are all in this position. Each digital product or platform usually has its own team of designers and developers, and each team designs and builds the pages and features that product or platform needs.
The way that work gets done is the same across the organisation, but the cost impact is when there's duplication of work across different product teams. Designers create the visual designs in a design tool like Figma, which 97% of design system teams use (zeroheight Design Systems Report, 2026). Developers then build working versions in code on platforms like Storybook, using the visual designs and tokens in Figma as the guide.
A design system is a shared set of finished components that all of those teams 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. Every page and feature is assembled from components, and the same components appear across every digital product or platform the organisation runs. In a design system, each component is:
designed once in Figma
built once in code, for the website and once for the app
checked once for accessibility
written up so a team can find it and use it without asking anyone
As a design system grows, it typically needs a small but dedicated team responsible for looking after it. That team decides what gets added to the design system, what gets changed and how the wider product teams should use it.
When several teams build for one organisation, the same component often gets built more than once
Picture a bank with a website team and a mobile app team. Both teams need the same component: the settings panel where a customer chooses which alerts to receive, such as a payment has arrived or a card has been used overseas. The website team designs and builds that component first. Three months later the app team needs the same one. Nothing in the bank tells the app team that the website team has already done this work, so the app team designs and builds its own. The bank now has two versions of one component, paid for twice, and every time either team changes theirs the two drift a little further apart.
It happens even when the teams try to share. A designer on the app team might copy the website team's visual design in Figma to save designing it again, which saves the design time but not the build time. The app developers still have to build the component in code from the visual design, because nothing tells them that working code for that component already exists on the website side. The saving at the design stage never reaches the build, and the build is where most of the cost sits. Each team is usually judged on delivering its own digital product or platform on time, and in most organisations there is no shared place that shows what the other teams have already built.
Building a component a second time costs more than the design & build hours
A finished component is more than a visual design and some code. For it to be safe for every team to use, it also needs:
a written note telling developers how to use it
a written note telling designers when to use it
a check that it works for people using a screen reader or a keyboard
testing
a version of every state it can be in
The states are how the component looks normally, when something has gone wrong, when it has nothing to show yet and while it is loading. A team building its own version under a deadline usually does the normal state and leaves the rest for a later phase, and that later phase rarely comes. The shared version is done in full, once. The pieces left out of the rushed versions come back later, as bugs and as accessibility problems fixed under pressure.
The time a design system saves can be measured, and almost nobody measures it
Sparkbox (an American consultancy that builds design systems) ran a super interesting test. Eight developers each built the same contact form twice: once from scratch, and once using components from an existing design system. Using the shared components, the form took a median of two hours. From scratch, it took four hours and twelve minutes (Sparkbox, The Value of Design Systems Study, 2021). The sample was eight developers building one form, so the result is useful for understanding where development time went rather than as an industry benchmark. About half of the time spent building from scratch went on layout, spacing, colour and accessibility decisions that the shared components had already made.
Most organisations could not run that comparison on their own digital products and platforms, because they do not track how much of what they build is reused. Only 9% of design system teams measure how much of what they build comes from the shared components rather than being built again (zeroheight Design Systems Report, 2026). One in five measure nothing about their design system at all, and 5% measure what it returns. Without those measures, the team asking for continued investment has little evidence of the cost the design system has removed.
How to work out what design & development duplication costs your organisation
There are three questions that help you identify what design system duplication costs across your organisation:
How many teams design and build digital products and platforms for your organisation?
In the last year, how many times did one of those teams build a component that another of your teams had already built?
What did one of those second component builds cost, counting the designer's time, the developer's time, testing and the accessibility fixes that followed?
An audit shows what is working in a design system and what is not
The next step is to fix the duplication and keep it fixed, and that starts with an audit of what already exists. A useful audit records which components exist, which digital products and platforms use each one, whether each has been checked for accessibility and when it was last updated. It also asks the developers and designers who use the components, as well as the people who built them, because whether teams even know the components exist is the finding that predicts everything else. In Adrenalin's design system work, this is where every engagement starts.
Only after the audit does anyone assess how mature the design system is. Keeping the two apart means every finding points at something specific, such as documentation last updated fourteen months ago, rather than a verdict such as "your documentation is poor", which people argue with. Every finding is written as a gap between where the design system is and where the organisation wants it to be, never as a judgement on the team. The audit becomes the starting point. Targets are set against it, and the same audit is repeated a year later, so improvement is measured rather than assumed.
A design system keeps saving money only while the organisation's own team keeps looking after it
Shared components remove the need to build something a second time. The saving only arrives when teams actually use them, and that depends on how the design system is looked after once it is built.
The most common failure is funding. A design system built as part of one project loses its team when that project ends, and within a year the product teams are building their own components again because the shared ones fell behind. Of the teams whose design system goes unused, nearly three-quarters say the reason is that nobody in leadership required its use (zeroheight Design Systems Report, 2026). At the same time, 91% of teams say they trust their design system. So teams trust the shared components and still build their own, because nobody is keeping the shared components current and nobody has asked them to use them.
Two-thirds of the work of running a design system is not designing, building or testing components. It is telling teams what exists, showing new starters how to use it and listening to what teams need so the design system keeps up. A design system that is not maintained or taught to new teams gradually loses adoption. Its commercial value also needs to be measured and reported so leadership can see whether continued investment is reducing duplicated work.
Leadership decides whether the savings from a design system are realised
A scalable design system makes the saving possible. Leadership determines whether the organisation actually captures it. That comes down to four decisions:
fund the upkeep so shared components stay current
make shared components the expected starting point for every team
give the design system team time to maintain them
measure the duplicated work the design system removes
When those conditions are in place, money that previously went into rebuilding existing components can go into improving and extending the organisation's digital products and platforms.
Learn from us
Join thousands of other Product Design experts who depend on Adrenalin for insights
