When starting a design system, why should a team use published reference systems as input rather than adopt one wholesale as a template?
answer
- someone else's brand and constraints
- decisions without their reasons
- borrow structure, not answers
- compare several, note where they agree
- copying is not build-vs-buy
basics
~20 sA published reference system encodes another organisation's brand, products, platforms and constraints. Copying it imports decisions without their reasons; studying it supplies proven structures, accessibility behaviour and naming ideas to adapt deliberately to your own users.
solid answer
~50 sPublic design systems are excellent things to study: they show how mature teams structure token tiers, document components and handle keyboard and screen-reader behaviour. But each one answers *its* organisation's questions — its brand, product types, platforms and density needs. Adopting one wholesale as your spec means inheriting choices you cannot explain, a visual identity that is not yours, and a component list shaped for products unlike your own; when your needs diverge, you either fork silently or bend your product to fit. The better practice is to compare several references, take the *patterns* they share, and record for each decision why it fits your users. That differs from a build-vs-buy decision to depend on a maintained component library and theme it — that can be sound, as long as you own the design decisions layered on top.
go deeper
Recall that a published design system reflects another organisation's brand, products and constraints, so it is something to study, not a spec to copy.
Explain what transfers well — structure, component behaviour, vocabulary, edge-case checklists — and what does not: brand, density, scope and decisions whose reasons you cannot state.
Describe a method: compare several references, treat convergence as evidence and divergence as a trade-off, decide per topic, and record rationale; distinguish this from depending on a library.
Weigh the organisational cost of borrowed decisions: a system nobody can explain is hard to govern and evolve, while a build-vs-buy dependency trades control for speed deliberately.
## What a reference system is A **reference system** here means a published design system from another organisation: its foundations (color, type, spacing and motion tokens), its component set, its documentation and its guidance. Many are public and detailed, which makes them tempting to treat as a ready-made answer when a team starts its own **design system** — the shared foundations, components and guidance that several product teams consume. The healthy stance treats them as **input**: evidence of how experienced teams solved similar problems, to be compared and adapted. The unhealthy stance treats one as a **template**: copy its tokens, component list and rules, swap the logo, and call it yours. ## Why copying one wholesale fails - **Its decisions answer someone else's questions.** A system tuned for dense professional dashboards makes different density, typography and navigation choices than one built for a consumer reading app. Those choices are right for *them*. - **You inherit decisions you cannot explain.** When a product designer asks why a component behaves a certain way, 'the reference did it' is not a reason, and nobody can tell which rules are safe to change. - **The brand is not yours.** Visual identity is part of the product; a copied look makes the product feel like someone else's. - **Divergence is inevitable and silent.** As your needs differ, the copy drifts from its source, and you get neither the source's later improvements nor a model designed for you. - **Scope is borrowed too.** A reference's component list reflects its products; building every item on it wastes effort on pieces you do not need while missing ones you do. ## What references are genuinely good for - **Structure** — how token tiers, naming and component documentation pages are organised. - **Behaviour** — keyboard and screen-reader behaviour of common components, which mature teams have exercised widely. It is a strong starting point, but your adapted versions still need testing in your own product. - **Vocabulary** — names for concepts and variants your team has not named yet. - **Completeness checks** — states and edge cases you may have forgotten: loading, empty, error, very long content. ## A working method 1. **Study several**, from different contexts — three or more is a common habit. Where independent systems converge, the pattern is probably general; where they diverge, you have found a real trade-off. 2. **Start from your own needs.** Your users, platforms and products define the questions; references supply candidate answers. 3. **Decide per topic** — token structure, one component's behaviour, a documentation layout — rather than adopting a whole system at once. 4. **Record the rationale** for each decision in your own terms, so future maintainers know what is safe to change. ## Copying a system vs depending on a library | | Copying a reference system as a template | Depending on a maintained component library | |---|---|---| | What you take | Another organisation's design decisions | Working behaviour and an upgrade path | | Who owns the design decisions | In practice, nobody | You, through your own foundations and theming | | Main risk | Decisions you cannot justify | Being bound by the library's constraints | | Verdict | A weak foundation | A legitimate build-vs-buy choice | The distinction matters in interviews: rejecting all outside code is not the lesson. Depending on a well-maintained library and theming it with your own foundations can be a sound choice; what fails is borrowing someone else's *design system* as your spec. ## Example: a public library catalog A team starting a system for a public library catalog's web and mobile apps studies three references. All three separate raw color values from purpose-named ones, and all three handle long titles in list rows by truncating while keeping the full text available — both transfer well. One reference uses very compact tables tuned for professional operators; the catalog's audience is the general public, including older readers, so the team chooses a roomier default density and writes down why. The references shaped the decisions without making them.
- How many reference systems should a team study, and why more than one?Several, from different contexts — three or more is a common habit. Where independent systems converge, such as separating raw values from purpose-named tokens, the pattern is probably general. Where they diverge, the divergence reveals a real trade-off that you must decide for your own users instead of inheriting one team's answer.
- Is basing a design system on an existing open component library the same as copying a reference system?No. Depending on a maintained component library is a build-vs-buy decision: you take on its behaviour and upgrade path and theme it with your own foundations. Copying a reference system as a template means adopting another organisation's design decisions as your spec. The first can be sound; the second leaves you owning decisions you cannot justify.
Studying other cities' building codes before writing your own: the fire-safety principles they share transfer well, but one city's snow-load rules were written for its climate, not yours.
saying these in an interview costs you the question
- A famous public design system is best practice, so copying it is safe.
- If a reference system does something, our users will expect it too.
- Reference systems are useless because every organisation is unique.
- Borrowing a reference's structure forces us to adopt its visual style.
- A reference's tested accessibility means our adapted components need no testing.