Open any product that has grown over a few years without a plan and you will usually find five shades of blue, four button styles and three different date pickers. Each was made by a different person on a different day, and each made sense at the time. The result is a product that feels inconsistent to users and slow to change for the team.
This is the problem design systems solve. A design system is a shared set of decisions (colours, spacing, typography), reusable building blocks (components) and guidelines for using them, kept in sync between design and code. This article explains the parts of a design system in simple terms and shows how to start a small one in Figma.
Design system, style guide, component library: what is the difference?
| Term | What it contains | Scope |
|---|---|---|
| Style guide | Colours, typography, logo usage, tone of voice | Mostly visual and brand rules |
| Component library | Reusable UI pieces such as buttons, inputs and cards, in design and/or code | The building blocks |
| Design system | Foundations (tokens), components, patterns, guidelines, code and the process to maintain them | Everything, plus how the team works together |
In other words, a component library is part of a design system, and a style guide is usually the starting point.
The main parts of a design system
1. Foundations and design tokens
Foundations are the basic visual decisions. Design tokens are those decisions stored as named values so they can be reused in design tools and code. For example, instead of writing #1D4ED8 everywhere, you name it color/brand/primary.
- Colour: brand, neutrals, success, warning, error, plus text and background roles. See colour theory for UI designers.
- Typography: font families, a type scale, line heights and weights. See typography rules for UI.
- Spacing: a scale such as 4, 8, 12, 16, 24, 32, 48.
- Radius, borders and elevation: corner radius values, border widths and shadow levels.
- Breakpoints and grids: how layouts change across screen sizes.
Tokens are often arranged in two layers. Primitive tokens hold raw values (blue-700 = #1D4ED8). Semantic tokens describe purpose (button-background = blue-700). Components use semantic tokens. When the brand colour changes, or when you add dark mode, you only change the mapping.
2. Components
Components are reusable interface pieces: buttons, inputs, checkboxes, tabs, cards, modals, toasts. Each component should cover all its states (default, hover, focus, pressed, disabled, error, loading) and sizes.
3. Patterns
Patterns combine components to solve common problems: a sign-in form, a search with filters, an empty state, an error page. They capture “how we usually do this here”.
4. Guidelines and documentation
Documentation explains when to use each component, when not to, and how to write content for it. Without it, people use the right components in the wrong way.
5. Code and governance
For a mature system, every component also exists in code, with matching names and props. Governance means agreeing who can change the system, how requests are made and how updates are announced.
Why bother? The benefits of design systems
- Consistency: users learn patterns once and reuse that knowledge everywhere (Nielsen’s “consistency and standards” heuristic).
- Speed: designers assemble screens from tested parts instead of drawing from scratch.
- Better handoff: developers recognise the same components and tokens in Dev Mode and in their codebase.
- Accessibility built in: fix contrast or focus styles once in the component and every screen benefits.
- Easier theming: switching brands or adding dark mode becomes a matter of changing tokens.
How Figma supports design systems today
| Figma feature | What it is for |
|---|---|
| Variables | Store reusable values. The main types are colour, number, string and boolean (newer timing and easing types support animation). Organise them into collections, and use modes for themes such as light and dark. A variable can reference (alias) another variable, which is how semantic tokens point to primitives. |
| Styles | Reusable text, colour, effect and layout grid styles. Text styles remain the usual way to package a full typography setting. |
| Components and instances | The main component defines the design; instances are linked copies that receive updates. |
| Variants | Group related components (for example size and state of a button) into one component set. |
| Component properties | Expose simple controls on instances: boolean (show/hide icon), text (label), instance swap (change icon) and variant. |
| Auto layout | Makes components resize correctly with content. See our Auto layout guide. |
| Libraries | Publish components, styles and variables so other files in your team can use them, and push updates. |
| Dev Mode | Lets developers inspect components, tokens and spacing, and see code snippets. |
Tip: Plan limits matter here. At the time of writing, Figma’s free Starter plan does not include team libraries or multiple variable modes per collection; these come with paid and education plans. On the free plan you can still build variables, styles and components inside a file, which is enough for learning.
Build a tiny design system in Figma: step by step
You do not need to build a big system to learn. Start with a mini system for a practice project, for example a small online bookshop.
- Create a primitives collection. Add colour variables for a few brand shades and neutrals (for example
blue/700,gray/900,gray/100,white) and number variables for spacing (space/4tospace/48) and radius. - Create a semantic collection with two modes, Light and Dark. Add variables such as
bg/default,text/primary,text/secondary,border/defaultandaction/primary, each aliasing a primitive. Give each mode different aliases. (If your plan allows only one mode, build the Light set first; the structure is what matters.) - Set up text styles for a simple scale: Display, Heading, Body, Body small, Caption.
- Build a button component with Auto layout. Bind its fill, text colour, padding and radius to variables.
- Add variants: Type (Primary, Secondary, Ghost), Size (Small, Medium) and State (Default, Hover, Disabled). Add a boolean property to show or hide an icon and a text property for the label.
- Build two or three more components: a text input with label, help text and error state; a card; a tag.
- Assemble a screen (a book listing and a book details page) using only your components.
- Switch the frame’s mode from Light to Dark and check that everything still reads well.
- Document each component on its own page: what it is for, do and don’t examples, and states.
Watch out: Avoid building dozens of components before you have real screens that need them. Systems grow best from repeated real needs, not from guessing.
Naming conventions that help
- Use slashes to group:
Button/Primary/Mediumor variables likecolor/text/primary. - Name tokens by purpose, not appearance:
text/errorrather thanred-text. - Agree names with developers so the same word means the same thing in Figma and in code.
- Keep variant property names short and predictable: Type, Size, State.
Connecting the system to code
Design tokens become most useful when developers use the same values. On the web, the most direct way is CSS custom properties:
:root {
--color-bg-default: #ffffff;
--color-text-primary: #111827;
--color-action-primary: #1d4ed8;
--space-2: 8px;
--space-4: 16px;
--radius-md: 8px;
}
.btn-primary {
background: var(--color-action-primary);
color: var(--color-bg-default);
padding: var(--space-2) var(--space-4);
border-radius: var(--radius-md);
}With matching names in Figma and CSS, a developer inspecting a button in Dev Mode can see which tokens it uses and apply them directly. For a full dark-mode setup in CSS, read dark mode design and CSS.
Common beginner mistakes with design systems
| Mistake | Better approach |
|---|---|
| Copying a famous design system wholesale | Study public systems for ideas, but build only what your product needs |
| Detaching instances to make small changes | Add a property or variant to the main component instead |
| Too many colour shades | Start with a small palette and add only when a real need appears |
| No documentation | Write a short “when to use” note for every component |
| Design and code drifting apart | Review the system regularly with developers and keep names aligned |
Starter checklist
- Colour, spacing and radius stored as variables, with semantic names.
- Semantic variables ready for light and dark modes, even if you ship only one theme for now.
- A text style scale with five to seven styles.
- Buttons, inputs, cards and tags built with Auto layout and variants.
- All interactive components have visible focus and disabled states.
- Contrast checked against WCAG (see web accessibility basics).
- A short documentation page per component.
Frequently asked questions
Do small projects need a design system?
Not a large one. Even a small project benefits from a mini system: a few colour and spacing variables, text styles and five or six core components. It keeps the work consistent and speeds up changes.
What is the difference between styles and variables in Figma?
Both store reusable values. Variables hold single values (colour, number, string, boolean), can alias other variables and support modes such as light and dark. Styles can package composite values, such as a full text style with font, size and line height.
Who owns a design system?
In larger companies a dedicated team may own it. In smaller teams, designers and front-end developers usually share ownership and agree on a simple process for proposing and reviewing changes.
Can I create a design system on Figma's free plan?
Yes, inside a file you can create variables, styles and components and use them. At the time of writing, publishing them as a shared team library and using multiple variable modes (such as light and dark) require a paid or education plan.
