Part 01 of 14 · · 3 min read
What a design system is, and why teams build one
A design system is more than a component library. The five layers, the Atomic Design model, what it saves a team, and the public systems worth studying.
A design system is the shared language a team uses to build its product’s interface. Rules, tokens, components, patterns and documentation live together and change together, so a button looks and behaves the same on every screen, in design files and in code.
People often use “style guide”, “component library” and “design system” as if they meant the same thing. They don’t, and the difference explains why some systems stay alive while others go stale within a year.
Style guide, component library, design system
| What it holds | Where it falls short | |
|---|---|---|
| Style guide | Colours, fonts and logo use, usually a PDF or a single page | Static. Nothing connects it to the code, so the two drift apart |
| Component library | Reusable parts such as Button, Input and Modal, in Figma or in code | Says what exists, not why or when to use it |
| Design system | Tokens, components, patterns, guidelines and governance, kept in sync between design and code | Needs a team and a process to stay healthy |
A style guide describes. A component library supplies. A design system does both, and adds the decisions and the process that keep the parts consistent as the product grows.
The five layers
- Foundations. Colour, typography, spacing, radius, elevation, motion, icons and the grid. They are stored as design tokens, so a decision lives in one place.
- Components. Button, Input, Select, Checkbox, Table, Modal, Toast, each with its variants, states and properties.
- Patterns. Several components that together solve a common problem: form validation, an empty state, onboarding, filtering, a data table with bulk actions.
- Guidelines. When to use something and when not to, do’s and don’ts, accessibility notes and content rules.
- Governance. Who can change the system, how a new component gets in, how versions are released and how adoption is measured.
The first two layers are what most people picture. The last three decide whether the system is still trusted two years later. Later parts of this series cover each of them.
Atomic Design: a way to think, not a rule
Brad Frost’s Atomic Design is the best-known model for breaking an interface into parts. It borrows its names from chemistry:
- Atoms: a label, an icon, an input field, a button.
- Molecules: a search bar, which is an input and a button working together.
- Organisms: a header with a logo, navigation, a search bar and an avatar.
- Templates: the layout skeleton of a page.
- Pages: a template filled with real content.
Treat it as a thinking model rather than a filing system. Many mature systems drop the chemistry names and speak of primitives, components and patterns instead. What matters is the habit it builds: start from small, single-purpose parts and compose them into larger ones.
Why companies pay for one
- Speed. Most of a new screen is assembled from parts that already exist, so design and build time goes into the part that is actually new.
- Consistency. Products look and behave alike, so users learn a pattern once and reuse it everywhere.
- Quality. Accessibility, states and edge cases are solved once inside a component, and every screen that uses it gets the fix.
- A smaller design–development gap. Design and code share the same names and the same tokens, so less gets lost in handoff.
- Scale. A theme, such as dark mode or a white-label brand, changes in one place instead of on every screen.
Public systems worth studying
You learn faster by reading how large teams solved the same problems. Each of these is public and well documented:
| System | From | Worth studying for |
|---|---|---|
| Material Design 3 | Token tiers, dynamic colour and a motion system | |
| Carbon | IBM | Data-heavy enterprise UI and documentation structure |
| Polaris | Shopify | Content guidelines and patterns |
| Atlassian Design System | Atlassian | Token naming and governance |
| Primer | GitHub | Developer-tool interfaces and primitives |
| Fluent 2 | Microsoft | Consistency across platforms |
Try this
Pick one of these systems and find its Button page. Note how it lists variants, sizes and states, and whether it explains when not to use a button. Then compare it with a second system. The differences show you what each team cares about.
Next in the series
Foundations are stored as design tokens, and tokens are where a design system starts to pay off. Part 2 covers the three tiers of tokens, how to name them and why the middle, semantic tier matters most.
Sources and further reading
See a design system in practice: the AppsCode Design System case study