A design system can reduce repeated design, development and quality-assurance work. It can also become an expensive library that nobody trusts or uses.
The commercial result depends on the scale and rate of change in the digital estate, the quality of implementation and who maintains the system after launch. There is no defensible promise that every design system pays for itself within a year.
The useful investment question is where reusable decisions will remove enough recurring effort and inconsistency to justify the continuing service.
A component library is part of the system
A design system usually includes reusable interface components, design foundations such as colour, typography and spacing, usage guidance, coded implementations and governance.
It is more than a Figma file. A button documented in design and implemented differently across three applications is not one reliable component. A coded library with no editor or accessibility guidance does not give the wider organisation a shared way to work.
The system creates a common vocabulary between design, engineering, content, product and quality teams. “Use the primary action” should refer to agreed purpose, appearance, states, behaviour, accessibility and code.
For a small marketing site, a disciplined component library and concise guidance may be enough. Calling it a full design system does not add value.
Where the saving can arise
Less repeated production
Teams can assemble new pages and features from tested components instead of redesigning familiar interactions. That reduces effort when the existing pattern genuinely fits.
Reuse should not force a novel or high-value journey into the wrong component. The saving comes from standardising recurring decisions and protecting capacity for problems that require design.
Fewer interpretation gaps
When design specifications and code refer to the same maintained component, teams spend less time resolving spacing, state and behaviour differences. This can shorten review and reduce defects.
Measure it locally. Compare time and defect patterns for similar work before and after adoption. Do not apply a generic 25–40% development saving to the whole project.
Wider quality fixes
A component-level correction can improve every valid use. This is particularly valuable for accessibility, security and resilience defects.
It also increases the consequence of a bad release. Components need versioning, regression testing, release notes and controlled adoption. “Change it once everywhere” is a capability and a risk.
Easier onboarding and supplier change
Clear patterns and code help new people understand how the service is built. They do not replace architectural documentation, content guidance or knowledge of why exceptions exist.
The handover saving depends on documentation quality, accessible repositories, licences and the recipient's skills.
More controlled brand evolution
Tokens and shared foundations can make visual change more consistent. A rebrand still needs research, testing and migration. Changing a colour variable cannot confirm contrast, meaning or suitability in every context.
Establish the baseline before claiming a return
The source contained detailed project percentages, payback periods and cash examples without substantiation. Replace them with a model based on the actual estate.
Estimate:
- recurring components and variants already in use;
- duplicate design and code;
- rate of new page and product work;
- defect and rework connected to inconsistency;
- accessibility remediation repeated across instances;
- current agency dependence for routine changes;
- teams and products likely to adopt;
- setup, migration and continuing maintenance cost.
Some value is avoided cost and some is released capacity. Do not describe staff time as a cash saving unless expenditure will genuinely change.
A simple site with infrequent updates may never recover a large system investment. A multi-product organisation repeatedly solving the same interactions may have a strong case.
Build during delivery where sensible
A major redesign or platform programme can provide a good moment to establish shared foundations because components are already being created. It is still work.
Teams need to identify patterns, consolidate variations, design states, implement code, test accessibility, document use and set governance. Budget and plan it. Calling this “work that was happening anyway” hides the quality required for reuse.
Retrofitting later can be more expensive because teams must inventory and reconcile the estate. It may also be the safer choice when the new product is exploratory and patterns have not stabilised.
Standardise after enough learning to know what recurs, and before inconsistency multiplies.
Accessibility belongs in the definition
A component is not ready because its default state looks correct.
Specify and test keyboard operation, focus, names, roles, states, contrast, zoom, reflow, reduced motion, errors, content variation and relevant assistive technologies. Include disabled people in research and evaluation where appropriate.
Document content constraints. A card tested with one-line headings can fail when a real editor adds a long service title. A form component can be technically accessible and used with an unclear label.
Reference current WCAG 2.2 criteria where applicable, without treating component checks as proof that every assembled page conforms.
Governance determines whether reuse lasts
Every component needs an owner and lifecycle.
Define how a team proposes a new pattern, checks whether an existing one can evolve, tests the change, approves it, releases it and deprecates the old version. Show who funds maintenance and who decides when product needs conflict.
A contribution model helps distributed teams improve the system without fragmenting it. Provide support and make the approved path easier than creating a private copy.
Track adoption. If teams bypass the library, investigate whether awareness, documentation, release friction or product fit is the cause. Mandating use without addressing those conditions creates shadow components.
Avoid weaponising the agency incentive
The source suggested that agencies may avoid design systems to generate more support work. That incentive can exist and should not be presumed from absence alone.
A supplier may recommend a smaller library because the estate is simple, the budget is constrained or long-term ownership is missing. Ask for the reasoning, commercial consequences and alternatives.
The client also needs to fund the durable work. Demanding a maintained system while buying only a fixed website build makes the expected service boundary impossible.
Ownership, source access, licences and exit terms belong in the contract.
Three questions to ask the agency
1. What reusable system are you proposing, and which problem does it solve?
Ask for the intended scope: foundations, design library, code, documentation, accessibility evidence, CMS patterns and products covered. Request the baseline and expected forms of value.
A good answer can be “a small component library” if that matches the need.
2. How will our teams use and own it after launch?
Identify repositories, tools, permissions, licences, skills, training, support and decision rights. Ask the supplier to demonstrate creating a real new page or feature from the system.
Clarify what editors can assemble safely and what still needs design or development.
3. How will it change, and what happens when we disagree?
Examine contribution, versioning, testing, release, deprecation and exception processes. Ask who pays for maintenance, how product-specific needs are handled and how the client can move to another supplier.
A static handover document is not a maintenance model.
Add three delivery tests
During the programme, inspect design and code side by side. Select representative components and confirm that names, variants, states and behaviour align.
Run a real content exercise with internal editors. Let them create a plausible page, encounter constraints and request a missing pattern.
Finally, test an update. Change a component, release it through a non-production environment, inspect affected uses and roll it back. This reveals whether central reuse works as promised.
The system should make good work easier
The goal is not perfect consistency. Some differences express a meaningful user or product need. Record exceptions and learn whether they should become variants or remain local.
The goal is a maintained set of shared decisions that reduces unnecessary reinvention, protects quality and lets teams change the service with confidence.
If you want to benchmark how well your current digital foundations are set up for long-term efficiency - including how maintainable and well-documented your platform actually is - our Fragility of Digital Foundations scorecard takes about ten minutes and has a habit of surfacing things people weren't expecting.
