What value does a design system promise an organisation, and what costs must that value outweigh?
answer
- build once, reuse many times
- consistency, speed, accessibility at scale
- a standing team, not a project
- migration and support are costs too
- value grows with the number of consumers
basics
~20 sA design system promises consistency, faster delivery through reuse, and accessibility and quality fixed once for every consumer. It costs a standing team, ongoing upkeep, migrating existing products, documentation and support, so it pays off only when many teams reuse it.
solid answer
~40 sThe value claims are **consistency** across products and platforms, **delivery speed** because teams assemble from finished, tested parts instead of rebuilding them, **accessibility and quality at scale** because a fix made once reaches every consumer, and **cheaper cross-cutting change** such as a brand refresh. The costs are a **standing team** to build and maintain it, **migration** of existing products, **documentation and support**, coordination overhead when teams must wait for the system, and the constraint cost when a product needs something the system does not offer. The balance depends on scale: the value multiplies with the number of teams and platforms reusing each part, while most costs are fixed, so a system pays off in a large, multi-team, multi-platform organisation and may not in a small one.
go deeper
Recall the main value claims, consistency, speed, accessibility and quality at scale, and the main costs: a team, upkeep, migration, documentation and support.
Explain why value multiplies with the number of consuming teams and platforms while most costs stay fixed, and why early adopters may slow down before speeding up.
Show where each claim stops, such as accessible components still misused, and how you would present costs honestly to product teams who pay for migration.
Frame the investment against the organisation's scale and roadmap, and decide which value claim leadership will actually fund: speed, brand, risk or cost of change.
## Why this question is asked A design system is an investment that competes with product features for the same people and budget. Interviewers ask about its value and cost to see whether a candidate can argue for one honestly: naming real benefits, naming real costs, and explaining the conditions under which the first outweighs the second. ## The value claims - **Consistency.** Users meet the same controls, behaviour and visual language across screens, products and platforms, which lowers the effort of learning each new surface and strengthens the brand. - **Delivery speed.** A team assembling a screen from finished, documented, tested components spends less time on layout, states and edge cases, and more on the product problem. The saving is largest on the second and later uses of a part. - **Accessibility at scale.** Focus handling, contrast, accessible names and keyboard or remote-control operation are solved once in a shared component; every consumer inherits the fix. An accessibility defect fixed in the system is fixed everywhere that uses it after upgrading. - **Quality at scale.** The same holds for bugs, performance work and internationalisation: one fix, many beneficiaries. - **Cheaper cross-cutting change.** A brand refresh or a new platform becomes an update to shared decisions and components rather than a hunt through every product. - **Shared vocabulary.** Designers and engineers name the same parts the same way, which shortens reviews and handoffs, and new staff become productive faster. ## The costs | Cost | When it hits | Notes | |---|---|---| | Initial build | Up front | Tokens, first components, documentation, tooling | | Ongoing maintenance | Forever | Bugs, new platform versions, new needs; a system is a product, not a project | | Migration | Per consuming product | Replacing existing bespoke UI costs product teams real time | | Documentation and support | Ongoing | Guidance, examples, answering questions | | Coordination overhead | When a team needs a change | Waiting for the system or negotiating a variant slows that team | | Constraint cost | When a product needs something new | A strict system can push teams toward the familiar rather than the right design | ## Why the balance depends on scale Most costs are roughly fixed: one team, one set of components, one documentation site. Most value multiplies: 1. Every additional consuming team saves the effort of building and maintaining its own copies. 2. Every additional platform shares the same decisions instead of re-deriving them. 3. Every accessibility or quality fix reaches more users. So the same system that clearly pays off for twenty teams shipping on five platforms can be a net loss for one team shipping one app. That is also why an honest business case names the number of consumers it expects. ## A worked example: a streaming service A video-streaming service ships a web player and apps for several television platforms. Without a system, each platform team builds its own media tile, its own player controls and its own on-screen keyboard for search. With one: - the media tile, its focus state and its loading placeholder are designed and built once per platform family and reused across home, search and profile screens; - the focus behaviour that remote-control navigation depends on is specified once and tested once; - a brand refresh changes shared colour, type and imagery decisions instead of dozens of screens. The costs are also visible: a team that owns those components, the effort of moving each existing app onto them, and the negotiation when one platform needs a tile the others do not. ## Claims to state carefully - Speed gains appear **after** reuse starts; the first product to adopt often goes slower because it pays for migration and feedback. - Consistency is a means, not the goal. The goal is lower user effort and lower cost of change. - A system does not make a product accessible by itself; teams can still misuse accessible components or build inaccessible screens around them. - Avoid quoting industry-wide percentages you cannot source; your own organisation's numbers are more convincing and more honest. ## Putting the two sides together A credible answer does not stop at two lists. It says which value claim matters most for this organisation and which cost is most likely to be underestimated. For a streaming service expanding to more television platforms, the strongest claim is usually the cost of building every feature again per platform; the most underestimated cost is usually the migration effort existing apps must spend. Naming both, and the scale at which the first overtakes the second, is what separates an argument from a slogan.
- Why do speed benefits often lag behind the investment?The first consumers pay for migration, report gaps and wait for fixes, so they can move slower than before. Savings arrive once parts are stable and reused repeatedly, and they compound as more teams adopt. Presenting the business case with this lag stated up front prevents leadership from judging the system on its first quarter, when costs are highest and returns lowest.
- How does a design system deliver accessibility at scale, and where does that claim stop?Shared components carry the accessible behaviour, such as focus handling, accessible names and contrast-safe colours, so every consumer inherits it and a fix propagates on upgrade. The claim stops at composition: teams can still build inaccessible layouts, write poor labels or misuse a component. The system raises the floor; it does not guarantee that every screen built from it conforms.
A design system is like a shared kitchen in a food hall: every stall saves on equipment and cleaning, but someone must staff and maintain it, and it only pays off once enough stalls cook there.
saying these in an interview costs you the question
- Claims a design system makes every product accessible automatically.
- Treats the system as a one-off project with no upkeep cost.
- Ignores the migration cost product teams pay to adopt it.
- Promises speed gains from the first sprint of adoption.
- Assumes a system pays off at any organisation size.