How does a design system differ from a component library, a style guide, a pattern library and a UI kit?
answer
- umbrella versus its parts
- who consumes each artefact
- code, rules, catalogue, design-file assets
- what each one leaves out
- governance is the part you cannot download
basics
~20 sA design system bundles design language, tokens, coded components, patterns, usage guidance and governance, run as a product. A component library is its coded parts; a style guide documents rules; a pattern library catalogues reusable solutions; a UI kit is design-file assets.
solid answer
~50 sA **design system** is the umbrella: the shared design language, the design tokens that encode it, components in both design files and code, patterns, usage guidelines, and the governance that decides how all of it changes, maintained as a product with consuming teams. A **component library** is the implemented components for one or more platforms: essential, but on its own it does not say when to use which part or who may change it. A **style guide** is a set of written rules, visual or editorial. A **pattern library** is a catalogue of reusable solutions with examples; some authors use it for every UI component. A **UI kit** is ready-made assets in a design editor, with no code and no behaviour. Each of the four is a slice of the system, not a synonym for it.
go deeper
Recall the umbrella and its six parts, then define each narrower term as one of those parts. Naming who uses each artefact makes the definitions stick.
Explain what each artefact leaves out and why that gap causes drift between design files, web and native code. Mention tokens as the shared source beneath UI kit and code.
Show that you can diagnose a team that has only one slice, and describe the symptoms of the missing parts in a multi-platform product without blaming the component library itself.
Frame the vocabulary as a scoping tool: which parts an organisation funds and staffs follows from what it believes a design system is, so align the definition before the plan.
## Why the vocabulary matters Teams use these five terms loosely, and the looseness causes planning mistakes. A team that believes it “has a design system” because it shipped a package of coded buttons will staff and fund it as a code package, then wonder why its designs, its web app and its native apps still drift apart. Interviewers ask this question to see whether a candidate can say what each artefact is, **who consumes it**, and **what it leaves out**. ## The five terms side by side | Term | What it is | Main audience | What it leaves out | |---|---|---|---| | **Design system** | The maintained set of shared decisions and assets for a family of products: design language, tokens, components, patterns, guidelines, documentation and governance, run as a product | Designers, engineers on every platform, writers, product managers | Nothing by definition; it is the umbrella | | **Component library** | Implemented, reusable UI components with an API, states and tests, per platform | Engineers | The rules beneath the components, when to use which, how changes are decided | | **Style guide** | Written rules: visual (colour, type, logo use) or editorial (voice, grammar) | Designers, writers, marketing | Working code and interaction behaviour | | **Pattern library** | A catalogue of reusable solutions, each with an example and guidance | Designers and engineers | Often tokens and governance | | **UI kit** | Ready-made components and screens as assets in a design editor | Designers | Code, behaviour and rules for use | ## The parts of a design system A useful checklist of what the umbrella contains: 1. **Design language**: principles, visual foundations (colour, typography, spacing, iconography, motion, elevation) and voice. 2. **Design tokens**: the design decisions stored as named data. The Design Tokens Community Group format draft defines a token as information associated with a human-readable name, at minimum a name/value pair, and describes tokens as a way to express design decisions in a platform-agnostic way. 3. **Components**: reusable UI units, both as design-editor assets and as code on each platform. 4. **Patterns**: recurring solutions to user problems that combine components with layout, content and behaviour rules. 5. **Guidelines and documentation**: when to use a part, when not to, accessibility notes, content guidance. 6. **Governance**: who owns the system and how changes are proposed, versioned, released and retired. Mapped onto that list, a component library is item 3 on the code side, a UI kit is item 3 on the design side, a style guide covers item 1 and some of item 5, and a pattern library covers item 4 and, depending on the author, item 3 as well. ## Where the words blur - **“Pattern library”** means different things to different authors. Brad Frost, who described atomic design, uses it for the catalogue of all interface parts: in his account, even the smallest atoms are shown “in the context of a pattern library”. Other teams keep “pattern” for multi-component solutions such as a flow. Neither is wrong; a system should define the term in its own glossary. - **“Style guide”** once meant a printed brand manual. Later, a “living style guide” meant a generated page showing coded components, which overlaps with component-library documentation. - **Downloadable “design systems”** are often a component library plus a UI kit plus documentation. The governance part cannot be downloaded: it is people and process inside the adopting organisation. - The whole vocabulary is **technology-agnostic**. Atomic design’s author stresses that it has nothing to do with any particular web technology, and the same holds for the rest: a native mobile team has a component library, tokens and guidelines just as a web team does. ## A worked example A retail bank ships a mobile app on two native platforms and a web banking site. It has a component library on each platform: a transaction row, an amount field, a button. Without the rest of the system: - each platform team types the brand’s colour for positive amounts slightly differently, because no token holds the decision; - the design editor’s UI kit shows a compact transaction row that no platform built; - two teams show a failed transfer in two different ways, because no guideline or pattern says how; - nobody knows who approves a new variant, so each team forks the component. None of those problems is a bug in the component library. They are the parts of a design system that the bank does not yet have. ## How to answer in an interview - Start with the umbrella and its parts, then place each narrower term inside it. - Name the audience of each artefact; it explains why each one exists. - Say what each leaves out, especially usage guidance and governance. - Acknowledge that “pattern” is used inconsistently and that a team should fix its own definitions.
- Can a team have a design system without a coded component library?Yes, at an early stage. A team can publish a design language, tokens, a UI kit and usage guidelines before any shared code exists, and product teams implement from them. It is a weaker system, because every team re-implements components and drift is likely, but it is still a system: shared decisions plus a way to maintain them. Most mature systems add coded components once the same parts are rebuilt repeatedly.
- Where do design tokens sit relative to the component library and the UI kit?Beneath both. Tokens hold the named design decisions, such as a colour, a spacing step or a type size, as platform-agnostic data. The UI kit in the design editor and the coded components on each platform both consume those values, so a decision changed in one place reaches designers and every platform. That shared source is what keeps the design side and the code side describing the same thing.
A design system is to a component library what a city’s building code, zoning plan and planning office are to a warehouse of standard bricks and windows: the warehouse is essential, but it does not say what may be built where or who approves a change.
saying these in an interview costs you the question
- Calls any shared package of coded components a complete design system.
- Treats style guide, pattern library and design system as exact synonyms.
- Thinks a UI kit in a design editor includes working code and behaviour.
- Leaves governance out of the parts because it is not an artefact.
- Assumes design systems are a web-only concept that native apps do not need.