In a design system effort, what are the trade-offs between building the system greenfield and extracting it from a live product's UI?
answer
- proven patterns vs clean slate
- extraction inherits real debt
- greenfield APIs are guesses
- who consumes it on day one
- extract, then rationalise
basics
~20 sExtraction harvests patterns already proven in production, so the system fits real needs and has a first consumer, but it inherits inconsistency and debt. Greenfield allows a clean, coherent model but risks untested abstractions nobody adopts and a costly retrofit.
solid answer
~50 s**Extraction** starts from UI that already ships: you pull the patterns a live product relies on into shared foundations and components. Its strengths are evidence and adoption — every component has at least one real consumer and known edge cases — but it inherits the product's inconsistencies, naming and coupling, and can bake one product's quirks into everyone's system. **Greenfield** designs the system's model first, which gives coherence and a chance to get structure and accessibility right from the start, but its APIs are guesses until a product uses them, value arrives later, and every existing product still pays a retrofit. Most teams run a hybrid: extract what is proven, rationalise it against a deliberate model, and design fresh only where production has no good answer. Context tilts the choice: a rebrand or a structurally broken UI favours greenfield foundations; similar live products with shared debt favour extraction.
go deeper
Recall the two starting points: extraction pulls proven UI out of a live product, greenfield designs the system's model first. Be ready to name one strength and one risk of each.
Explain why extraction brings evidence and a first consumer but inherits inconsistency and coupling, while greenfield brings coherence but speculative APIs, delayed value and a postponed retrofit.
Show how you read the context — quality of existing UI, a coming rebrand, product similarity, funding patience — and describe the hybrid: extract the proven parts, rationalise them, and validate with a second consumer.
Frame the choice as a bet on which risk the organisation can afford: extraction buys early credibility and runway, greenfield buys long-term coherence at the price of later adoption.
## Two ways to start a design system A **design system** is the shared set of foundations (tokens for color, type, spacing and motion), components, patterns and guidance that several product teams consume instead of each building their own. Before any of it exists, a team has to decide where the first version comes from: - **Greenfield** — design the system's model first (token tiers, naming, component set, behaviour rules), then ask products to adopt it. - **Extraction** — start from UI that already ships in a live product, pull the patterns it relies on into shared foundations and components, and generalise them as further products adopt them. Neither is usually run in a pure form, but the trade-offs are real, and interviewers want to hear them reasoned rather than recited. ## What extraction gives you, and what it costs Extraction's great strength is **evidence**. Every component that comes out of production already has at least one real consumer, known edge cases (long titles, empty states, slow networks, translated strings) and a history of fixed bugs. Its adoption story is easier too: the source product consumes the system from day one, because the system started as its UI. The costs come from the same place: - **Inherited inconsistency** — the product's five slightly different button styles or ad-hoc colors come along unless someone rationalises them. - **Inherited assumptions** — options, names and layouts that only make sense on that product's screens and feel alien to the next consumer. - **Architectural coupling** — components tied to the product's data layer, navigation or state, which must be cut loose before they can be shared. - **A ceiling on ambition** — it is hard to fix a structural problem, such as having no semantic layer between raw values and components, while you are also harvesting code. ## What greenfield gives you, and what it costs Greenfield gives **coherence**. The team can design token structure, naming, accessibility behaviour and parity between web and native mobile deliberately, without negotiating with years of history. It suits moments when history is the problem: a rebrand, a new product line, or a platform rewrite. Its costs: - **Speculative abstractions** — a component's API is a guess until a product uses it, and guesses tend toward too many options or the wrong ones. - **Delayed value** — months can pass before a single user-facing screen improves, which is hard to defend to whoever funds the work. - **The retrofit is only postponed** — every existing product still has to move onto the new system, and the gap between old UI and a model not derived from it is often wider. - **Adoption risk** — a system built apart from products can be technically sound and still go unused. ## Side by side | Dimension | Extraction | Greenfield | |---|---|---| | Evidence behind each component | High — already in production | Low until a first consumer | | Coherence of the model | Needs deliberate rationalising | High by design | | Time to first shipped value | Shorter | Longer | | Characteristic risk | Bakes in one product's quirks | Builds what nobody adopts | | Retrofit for existing products | Smaller for the source product | Full for every product | ## How to choose Context decides; a few signals carry most of the weight: 1. **How good is the existing UI?** If a live product is broadly consistent and accessible, extract from it. If its structure is the problem, design the foundations fresh. 2. **Is a rebrand or platform change coming?** A new visual language tilts toward greenfield foundations. 3. **How many live products, and how alike are they?** Several similar products with shared debt make extraction pay off; very different products make any single one a weak source. 4. **How patient is the funding?** Extraction usually shows value sooner. ## The hybrid most teams actually run Take a public library catalog with a web app and a mobile app. A common path is to extract the patterns the web catalog has already proven — the search-result row, the item-availability label, the place-hold action, pagination — and then **rationalise** them against a deliberately designed model: purpose-named tokens, consistent naming, and keyboard and screen-reader behaviour checked before release. Where production has no good answer, such as the mobile app's filter sheet, the team designs fresh. The mobile app then acts as the second consumer that shows whether the extracted pieces are truly general. The point to make in an interview is not which label you pick, but that you can name what each approach risks, which signals in your context tilt the choice, and how you would contain the risk you accept.
- If several live products each have their own UI, which one should a design system extract from?Usually the product whose patterns are most mature, most accessible and most reused, and whose team will partner closely. Compare its components with the other products' equivalents before extracting: where they agree, the pattern is probably general; where they diverge, treat each divergence as a design decision to make explicitly rather than an accident to copy.
- Does building a design system greenfield avoid retrofit work on existing products?No — it postpones and usually enlarges it. Every existing product still has to move onto the new foundations and components, and because the greenfield model was not derived from their UI, the gap to close is often wider than with extraction. Budget the retrofit from the start rather than discovering it after launch.
- What signals that an extracted component is still too tied to its source product?Its options or variant names describe one product's screens, it fetches or formats that product's data itself, it depends on the product's navigation or state, or its layout only works inside one page's container. Each needs cutting loose — pass data in, rename by purpose, remove page-specific assumptions — before a second product can adopt it.
saying these in an interview costs you the question
- Extraction just means moving the product's components into a shared package unchanged.
- Greenfield is always better because it avoids all legacy debt.
- Extracted patterns need no design review because they already shipped.
- Choosing greenfield means existing products never need a retrofit.
- The choice is purely technical and can ignore who consumes the system first.