Introduction
A product can look perfectly organised when it has five screens.
Add another twenty screens, two more designers, a few developers, and a mobile version—and things can start to change quickly.
The same button may appear in slightly different styles. Spacing can vary from one screen to another. A component updated in one place may remain unchanged elsewhere. Designers begin recreating elements that already exist, while developers spend valuable time maintaining multiple versions of what should be the same UI.
Individually, these issues may seem minor.
Together, they can become a significant product-development cost.
This is where the choice between one-off UI design and a design system becomes important.
One-off design is often the fastest way to get a new product or feature into users' hands. Teams design what they need, when they need it, without first investing time in creating a reusable foundation. For an MVP, campaign page, or early-stage product that is still evolving, this flexibility can be exactly what the team needs.
A design system takes a different approach. Instead of repeatedly designing buttons, forms, cards, navigation patterns, and other interface elements from scratch, teams build a shared foundation of reusable components, design tokens, guidelines, and standards. These can then be applied consistently across products, platforms, and teams.
But the real question isn't:
Which approach is better?
It's:
At what point does designing for reuse become more valuable than designing for speed?
That question is becoming increasingly relevant as products grow more complex, teams work across multiple platforms, and AI-assisted tools become part of everyday design and development workflows. Research is also beginning to explore how combining AI with design-system context can accelerate development while helping teams maintain greater consistency.
The answer, therefore, isn't that every product needs a design system from day one.
Instead, the better approach is to understand when the investment in a design system starts paying for itself and when a one-off approach is still the smarter choice.
This article explores that trade-off, looking at the cost, scalability, consistency, development efficiency, and long-term value of one-off UI design versus design systems.
One-Off UI Design: Fast at First, Expensive to Repeat
One-off UI design is straightforward: build the interface you need for the project in front of you. There is no large component library to establish first, no extensive documentation to maintain, and no need to define every possible button variant before the first release.
For a small team validating an idea, this flexibility can be a major advantage. Teams can experiment quickly, change direction easily, and focus on getting the product in front of users without spending time building infrastructure they may not need yet.
The problem begins when we'll build it as we need it becomes the permanent way of working. A button designed for one screen gets recreated for another, a developer builds a slightly different version, and a new designer creates another variation because there is no clear source of truth.
The product may still work, but the team gradually starts paying for the same decisions repeatedly.
This can lead to:
Duplicated design and development work
Inconsistent UI patterns
Longer design review and QA cycles
More difficult maintenance
Greater collaboration friction between design and engineering
Higher effort when making product-wide changes
One-off design, therefore, isn't inherently bad design. It is mainly a question of scale. If you're building something once, recreating it may not matter much. But when the same patterns are being recreated across dozens of screens, the economics begin to change.
Design Systems: An Investment in Reuse
A design system takes a different approach. Instead of solving the same interface problem repeatedly, it turns common design decisions into reusable infrastructure.
A typical system can include:
Reusable UI components
Design tokens for colour, spacing and typography
Interaction and accessibility guidelines
Common design patterns
Documentation and usage rules
But a design system is more than a component library. A mature system creates a shared language between design and development, giving both teams a common reference for how interfaces should look, behave, and be implemented.
Instead of repeatedly moving through Design → Explain → Build → Review → Fix, teams can often work through a simpler process: Select → Adapt → Build → Reuse.
The initial investment is still significant. Teams need to design components, define their states and behaviour, document usage, and maintain the system over time. However, the purpose of that investment is not to save time on the first component.
It is to save time every time that component is reused.
Where the Efficiency Comes From
Evidence suggests that this reuse can create measurable development efficiency. In a controlled Spark box experiment using IBM's Carbon Design System, eight developers built the same contact-form page both from scratch and with Carbon. The median development time dropped from 4.2 hours to 2 hours, a reduction of approximately 47%.
The result should not be treated as a universal benchmark. Every organization will see different results depending on team size, product complexity, system maturity, adoption, and the frequency with which components are reused.
The broader lesson is more important: when a pattern is reused frequently, standardizing it can turn an upfront investment into ongoing efficiency.
This is also why the role of design systems has expanded. They are no longer simply about keeping colors, buttons, typography, and spacing consistent. They can also support:
Faster product development
Better collaboration between teams
More consistent user experiences
Easier product maintenance
Greater scalability across platforms
As AI-assisted design and development tools become more common, this foundation can become even more valuable. AI can generate interfaces and code quickly, but without clear design rules and reusable components, it can also generate unnecessary variations. A well-structured design system provides a shared framework that can help AI-assisted workflows produce more consistent and scalable results.
The question, then, isn't simply whether a design system costs more to build. The real question is whether the cost of repeatedly solving the same problems eventually becomes greater than the cost of building a reusable system.
The Cost Curve: Why Timing Changes the Answer
One way to understand the financial value of a design system is to look at the time required to complete the same task. A Sparkbox experiment compared eight developers working on the same contact-form interface, with one version built independently and another using IBM's Carbon Design System.
The difference is visible in the results below. Developers using Carbon generally completed the task in less time, with the median dropping from 4.5 hours to around 2 hours. That's roughly a 47% reduction in development time.
The individual results also show that the benefit wasn't identical for every developer. Some saw a much larger time difference than others, which is important when considering design-system ROI in real organisations. The impact will depend on factors such as familiarity with the system, task complexity, and how much existing UI can be reused.
The broader takeaway is simple: when the same interface work happens repeatedly, even small time savings per task can accumulate into meaningful efficiency across a larger team.
| Factor | One-Off UI Design | Design System |
|---|
| Upfront Cost | Low - no setup investment required | High - significant initial time/budget investment |
| Speed on First Project | Fast - nothing to build before designing | Slower - system has to be built before it can be used |
| Speed on Later Projects | Slows down - each new screen rebuilt from scratch | Faster - components reused, not rebuilt (up to 47% faster per component) |
| Consistency | Degrades over time across teams and features | Maintained by shared, governed components |
| Engineering Overhead | Higher up to 52% slower shipping, ~23% capacity lost to redundant UI logic | Lower - shared tokens turn multi-day updates into single-point changes |
| Break-Even Point | N/A - cost is roughly linear per project | Typically positive ROI by year two |
| 5-Year Cumulative ROI | Not applicable in the same way — cost compounds instead of returning | Commonly cited in the 135–170%+ range (up to 247% in Airbnb's case) |
| Best Fit | Early-stage products, MVPs, one-off landing pages | Products scaling across features, platforms, or teams |
Where the ROI Comes From, Specifically
The value of a design system isn't limited to making designers and developers work faster. Its bigger advantage comes from reducing repeated work as a product grows.
When teams repeatedly create similar components, they also repeatedly spend time designing, developing, reviewing and maintaining them. A design system turns those recurring patterns into reusable building blocks.
Where the value shows up
Faster development: Reusable components reduce the need to build common UI patterns from scratch.
Less rework: Shared standards reduce duplicated design and development efforts.
Easier maintenance: Centralised components make product-wide updates more structured and manageable.
Better collaboration: Designers and developers work from the same components, patterns and terminology.
Reusable knowledge: Documentation and established guidelines reduce dependence on individual team members.
There is also measurable evidence behind the efficiency argument. In a Sparkbox experiment, developers building the same contact-form page took a median of 4.2 hours from scratch compared with 2 hours using IBM's Carbon Design System. The experiment included time spent learning the system, showing the potential efficiency that established components can provide.
The broader business case is evolving too. Figma's 2026 research with the Design Executive Council connects design systems with areas such as efficiency, scale, revenue, customer loyalty and product strategy, suggesting that mature systems are increasingly being treated as product infrastructure rather than simply UI libraries.
The real ROI comes from solving a problem once and being able to reuse that solution many times.
When One-Off Design Is Still the Right Call
A design system isn't automatically the best choice for every project. Building and maintaining one requires time and resources, so the investment needs to match the product's expected scale and reuse.
One-off design can still be the better option when:
You're validating an MVP : The product is still changing based on user feedback.
You're building a single landing page : There is little opportunity for long-term component reuse.
You're creating a short-term campaign : The experience has a limited lifespan and scope.
Your team is very small : Basic guidelines and shared files may be enough to maintain consistency.
The product is still highly experimental : Formalizing patterns too early could slow down experimentation.
The important distinction is that one-off design isn't bad design. It can be the most efficient approach when the amount of repetition is low.
A Practical Way to Decide
Choosing between one-off design and a design system doesn't have to be an all-or-nothing decision. The best approach depends on how much reuse your product is likely to generate.
Before investing in a full design system, ask a few simple questions:
How often will this component be reused?
Will it appear across multiple features or screens?
Will different designers or developers need to use it?
Will the product eventually extend to multiple platforms?
How often do similar UI patterns need to be redesigned or rebuilt?
If the answer is “probably once,” a one-off approach may be the more efficient choice.
If the answer is “repeatedly,” standardising that pattern can start creating value through reuse, consistency and easier maintenance.
You also don't have to build the entire system at once. A practical approach is to start with the components that are already appearing repeatedly such as buttons, forms, navigation, cards and typography—and expand the system as the product grows.
A simple rule of thumb
Build once → design for speed.
Build repeatedly → design for reuse.
Build across teams and platforms → invest in a system.
The goal isn't to create the biggest design system possible. It's to create enough structure to eliminate the repetition that is already costing your team time.
Conclusion
Design systems and one-off UI design are not competing approaches; they are different ways of managing product design costs over time. One-off design can be the right choice when a product is small, experimental, or unlikely to require much reuse, allowing teams to move quickly without investing in unnecessary structure. As a product grows, however, repeatedly designing and developing the same patterns can create duplication, inconsistency, and maintenance effort. This is where a design system becomes valuable by turning recurring design decisions into reusable components, shared standards, and a common foundation for design and development. Ultimately, the right approach depends on the scale and complexity of the product not on how early a company can build a design system.
The goal is to introduce structure when the value of reuse begins to outweigh the cost of repetition.
