What a design system is and why: single source of truth × consistency × scale × speed
Start with the definition: a design system = a reusable set of components + patterns + design guidelines + design tokens, plus the principles and documentation guiding how to use them, serving as the single source of truth for an entire product family — so designers and engineers build consistent interfaces fast, from the same parts, by the same rules.
Note: it is not just a Figma UI kit or a color palette — those are only pieces of it. A design system bundles 'what it looks like + how to use it + the code implementation + who maintains it' into a living product: a product that serves other products.
Why bother? Without a design system, every page and every team builds its own buttons and tunes its own spacing — the result is inconsistent UI, duplicated effort, and 'fix one spot, miss ten.' A design system solves three things:
- Consistency — the same element looks and behaves the same across the whole product (directly delivering usability heuristic #4, 'Consistency and standards');
- Scale and speed — reuse ready-made components instead of redoing them every time, so new features get built faster;
- Maintainability — change a token or component once and every place that uses it updates together ('fix once, apply everywhere').
The bigger the product, the more teams, and the faster the iteration, the greater the leverage of a design system.
Atomic design's five levels: atoms → molecules → organisms → templates → pages (the labels aren't the point)
Brad Frost's 'Atomic Design' (2013) borrows a chemistry metaphor to break interfaces into five progressive levels:
1. Atoms — basic elements that can't be broken down further: a button, an input, a label, a color value;
2. Molecules — simple components made of a few atoms: a search box = label + input + button;
3. Organisms — more complex, section-level blocks: a header = logo + navigation + search;
4. Templates — page skeletons that place components into a layout and define the content structure (no real content);
5. Pages — template instances filled with real content.
Its core value: it makes you think about 'the whole and the parts' at the same time — build the system (reusable parts) first, then the pages, instead of painting pages one by one.
But don't turn it into dogma. Brad Frost himself has said: 'Those specific labels (atoms, molecules, organisms, templates, pages) have never been the point — we don't really use them in our own work; but it's still useful as a mental model.'
Its value lies in offering a way of thinking that sees the whole and the parts at once and helps teams communicate; whether you use 'atoms / molecules' or your own names like 'base components / blocks / sections' is fine — whatever taxonomy helps you and your team communicate better and build a good system is the right taxonomy. Don't burn energy agonizing over whether a component counts as 'a molecule or an organism.'
Design tokens, governance and adoption — and busting the 'kills creativity' myth
Design tokens: name your lowest-level design decisions and store them as reusable variables — like color-brand-blue, spacing-md, font-size-lg. Components don't hard-code '#1677ff'; they reference color-brand-blue — so change one token, and every place referencing it changes together.
Three benefits: (1) consistency — the whole product shares one set of values; (2) easy change — switching the brand color only touches the token; (3) multi-theme / multi-brand support — the same set of components, swapped onto another set of tokens, yields dark mode or another brand's skin. Tokens are the bridge between 'design decisions' and 'code implementation' (the W3C Design Tokens Community Group is still pushing a standard format for them).
For first-hand samples, study the mature exemplars: Google's Material Design, Apple's HIG (Human Interface Guidelines), Salesforce's Lightning; and first-hand Chinese ones: Alibaba's Ant Design and Tencent's TDesign — they publish their components, tokens, principles, and usage, making them excellent study material.
Finally, one common myth to bust: 'with a design system, designers can only snap blocks together — creativity gets killed.' Quite the opposite — the system locks down repetitive low-level decisions like 'how big should this button be, which spacing value to use,' freeing designers to spend their energy on genuinely novel problems (new flows, new experiences) while keeping the base experience consistent and reliable. A design system constrains arbitrary inconsistency and liberates valuable creativity.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
What is a design system? Which statement is the most accurate?
答案：A reusable set of components + patterns + design guidelines + design tokens, plus usage principles and documentation, serving as the 'single source of truth' for an entire product family
A design system is a reusable set of components + patterns + design guidelines + design tokens, plus the principles and documentation guiding their use, serving as the single source of truth for an entire product family — so designers and engineers build consistent interfaces fast, from the same parts, by the same rules. It is not just a Figma UI kit or a color palette — those are only pieces of it; it bundles 'what it looks like + how to use it + the code implementation + who maintains it' into a living product that serves other products. (Source: Nielsen Norman Group, 'Design Systems 101'; Brad Frost, Atomic Design)
Without a design system, every page and every team builds its own buttons and tunes its own spacing. Which three things does a design system mainly solve?
答案：Consistency (the same element looks and behaves the same product-wide) × scale and speed (reuse ready-made components to build faster) × maintainability (change a token/component once and it applies everywhere)
A design system solves three things: (1) consistency — the same element looks and behaves the same across the whole product, directly delivering usability heuristic #4, 'Consistency and standards'; (2) scale and speed — reuse ready-made components instead of redoing them every time, so new features get built faster; (3) maintainability — change a token or component once and every place using it updates together ('fix once, apply everywhere'). The bigger the product, the more teams, and the faster the iteration, the greater its leverage. It isn't about fancier mockups, and it replaces no one. (Source: Nielsen Norman Group, 'Design Systems 101'; Nielsen's ten usability heuristics, #4)
Brad Frost's 'Atomic Design' breaks interfaces into five progressive levels. Which is the correct order?
答案：Atoms → molecules → organisms → templates → pages
Atomic design uses a chemistry metaphor with five progressive levels: (1) atoms (basic elements that can't be broken down further: a button, an input, a label, a color value) → (2) molecules (simple components made of a few atoms: search box = label + input + button) → (3) organisms (more complex section-level blocks: header = logo + navigation + search) → (4) templates (page skeletons placing components into a layout, with no real content) → (5) pages (template instances filled with real content). Its core value is making you think about 'the whole and the parts' at the same time — build the system (reusable parts) first, then the pages. (Source: Brad Frost, Atomic Design, Chapter 2, atomicdesign.bradfrost.com)
True or False: Atomic design is a rigid framework that must be copied verbatim — teams must strictly use the labels 'atoms / molecules / organisms' and argue every component's classification ('molecule or organism?') to a firm conclusion, otherwise they're doing it wrong.
答案：False
False. Brad Frost himself has said: 'Those specific labels (atoms, molecules, organisms, templates, pages) have never been the point — we don't really use them in our own work; but it's still useful as a mental model.' Its value lies in offering a way of thinking that sees the whole and the parts at once and helps teams communicate; whether you use 'atoms/molecules' or your own names like 'base components / blocks / sections' is fine — whatever taxonomy helps you and your team communicate better and build a good system is the right taxonomy. Don't burn energy agonizing over classification. (Source: Brad Frost, 'Extending Atomic Design,' bradfrost.com)
What is a design token?
答案：A lowest-level design decision that is named and stored as a reusable variable (like color-brand-blue, spacing-md), which components reference instead of hard-coding the value
A design token names a lowest-level design decision and stores it as a reusable variable — like color-brand-blue, spacing-md, font-size-lg. It is the single source of truth for visual style: components don't hard-code '#1677ff' but reference color-brand-blue, so changing one token changes every place that references it. Tokens are the bridge between 'design decisions' and 'code implementation,' and the W3C Design Tokens Community Group is pushing a standard format for them. Nothing to do with login tokens or cryptocurrencies. (Source: W3C Design Tokens Community Group; Salesforce Lightning Design Tokens as early practice)
True or False: When components reference a design token like color-brand-blue instead of hard-coding a value like '#1677ff', changing one token changes every place referencing it — so the same set of components, swapped onto another set of tokens, can switch to dark mode or another brand's skin.
答案：True
True. These are exactly the three benefits of design tokens: (1) consistency — the whole product shares one set of values; (2) easy change — switching the brand color only touches the token; (3) multi-theme / multi-brand support — the same set of components on another set of tokens yields dark mode or another brand's skin. Tokens bridge design decisions and code implementation; 'change one token and every place referencing it changes together' is their core mechanism. (Source: W3C Design Tokens Community Group; Salesforce Lightning Design Tokens as early practice)
Which statement about the relationship among a style guide, a component library, and a design system is correct?
答案：The design system has the largest scope: the style guide and component library are parts of it, and it also integrates design principles, design tokens, documentation, and the people and processes maintaining it
From smallest to largest scope: (1) style guide — a document of visual rules for color/typography/spacing/tone; (2) pattern library — a set of reusable UI patterns/solutions; (3) component library — a collection of coded, ready-to-use components (the code layer); (4) design system — the biggest one, integrating all three plus design principles, design tokens, documentation, and the people and processes maintaining it into one organic whole. So a style guide or component library is a part of a design system, not the design system itself. (Source: Nielsen Norman Group, 'Design Systems 101'; Brad Frost, Atomic Design)
Where does the real difficulty of building a design system lie?
答案：Long-term governance and adoption: who can add/change components, the contribution process, version management, documentation quality, and whether teams actually use it — without governance the system rots or gets forked
The real difficulty of a design system is not drawing a few components but long-term governance and adoption. It is a 'product serving other products' that needs ongoing operation: who has the authority to add or change components, what the contribution process is, how versions are managed, whether the documentation is clear and usable, and whether teams actually use it instead of rolling their own. Without governance, the system quickly rots or gets forked (people copy-paste and tweak because contributing feels like a hassle), and the consistency advantage is gone. Mature design systems all have a dedicated team + contribution model + clear documentation + version management — a continuously maintained product, not a one-off deliverable. (Source: Nielsen Norman Group, 'Design Systems 101')
True or False: With a design system in place, designers can only snap building blocks together, and creativity gets killed.
答案：False
False. Quite the opposite: the system locks down repetitive low-level decisions like 'how big should a button be, which spacing to use,' freeing designers to spend their energy on genuinely novel problems (new flows, new experiences) while keeping the base experience consistent and reliable. A design system constrains arbitrary inconsistency and liberates valuable creativity. Google's Material Design, Apple's HIG, Salesforce's Lightning, Alibaba's Ant Design, and Tencent's TDesign publish their components, tokens, principles, and usage — excellent study samples, and the products behind them have hardly lost their creativity. (Source: Material Design / Ant Design / Apple HIG official design systems)
True or False: A design system is essentially just a Figma UI kit plus a color palette — deliver it once and the job is done.
答案：False
False. A Figma UI kit or a color palette is only a part of a design system. A design system is the single source of truth for an entire product family: reusable components + patterns + design guidelines + design tokens, plus usage principles and documentation, bundling 'what it looks like + how to use it + the code implementation + who maintains it' into a living product that serves other products. And it must be run as a continuously maintained product — with a dedicated team, a contribution model, clear documentation, and version management — not a one-off deliverable; without governance it quickly rots or gets forked. (Source: Nielsen Norman Group, 'Design Systems 101'; Brad Frost, Atomic Design)