As a product grows, screens multiply, designers invent slightly different buttons and developers end up coding the same component three times. A design system is the cure. This guide walks through how to build a design system in Figma, from variables and components to documentation and matching the code side.
What is a design system?
A design system is a shared language: foundational decisions such as color, typography and spacing, the components built from them, and the rules for using them. It is more than a UI kit. A UI kit is a file of ready-made parts; a design system also explains why and when to use them, and stays in sync with code.
| Layer | Contents | Example |
|---|---|---|
| Foundations | Color, type, spacing, radius, elevation | color/primary, space/16, radius/md |
| Components | Reusable interface parts | Button, Input, Card, Modal |
| Patterns | Common combinations of components | Form validation, empty states |
| Guidelines | Usage rules, do and don't examples | One primary button per screen |
When do you need one?
- Several products or platforms (web, iOS, Android) share one brand.
- Multiple designers and developers work on the same product.
- The same component keeps reappearing with small differences.
- Dark mode, theming or a rebrand is on the roadmap.
Step 1: Define foundations with Figma variables
Figma variables bring design tokens straight into your file. We recommend two layers:
- Primitive variables: the full palette, such as blue/500 or gray/100. Never applied directly to screens.
- Semantic variables: purpose-based names such as text/primary, surface/default, border/subtle, referencing primitives.
With this split, adding a dark mode means adding a mode and remapping the semantic layer; screens update automatically. Define number variables for spacing and radius too, and create text styles named by role (heading, body, label).
Step 2: Build components with auto layout and variants
- Auto layout everywhere so components resize correctly with content.
- Variants on meaningful axes: for a Button, size (sm, md, lg), variant (primary, secondary, ghost) and state (default, hover, pressed, disabled).
- Component properties for text, boolean icon toggles and instance swaps, which keeps variant counts manageable.
- Variables only: no hard-coded colors or hand-typed spacing inside components.
Start with small pieces (icons, badges, avatars) and work up to larger ones (cards, list rows, modals) so nesting stays consistent.
Take an Input component as an example. Drawing the default look is not enough: you need label, helper text, error message, leading and trailing icons, disabled, read-only and focused states, plus sizes. Instead of separate frames, combine them in one component using boolean properties and a state axis. Designers pick what they need from the properties panel, and developers see at a glance which states must be coded.
Step 3: File structure and naming
Publish the system as a separate Figma library so updates roll out in a controlled way. A simple page layout: cover and changelog, foundations, one page per component group, then patterns and example screens. Aim for names that match the code exactly. If Figma says "Primary Button" and code says "ButtonPrimary", your teams translate all day.
Versioning matters as much as naming. Every library publish pushes update notices to the files that use it. Try breaking changes, such as restructuring a component's variants, on a branch first and publish them with a short changelog so working screens do not break unexpectedly. Noting which code release matches each library version keeps design and software from drifting apart.
Step 4: Documentation and developer handoff
For each component, document when to use it and when not to, its states (loading, error, empty), accessibility notes such as contrast, tap target and screen reader label, and the name of its code counterpart. Dev Mode lets developers inspect variable names and measurements directly. On the web those variables map to CSS custom properties or a Tailwind theme; on mobile, to SwiftUI or Jetpack Compose theme files. We plan this mapping from day one in our web development and mobile app development projects.
Common mistakes
- Starting too big, too early: designing hundreds of components before the product is clear. Grow from real screens.
- No owner: someone must maintain the system and approve changes.
- Habitual detaching: when designers detach instances, the system is missing something; feed that back into the library.
- Drifting from code: once Figma and code diverge, the system stops being a source of truth.
Building a design system in Figma comes down to solid variables, flexible components and documentation that speaks the same language as your code. At BernSoftware, our UI/UX design team grows the system alongside the product and maps it to web and mobile codebases. If you want to set one up or tidy a messy UI kit, contact us.
Frequently asked questions
What is the difference between a UI kit and a design system?
A UI kit is a collection of ready-made components. A design system adds foundations, usage rules, documentation and alignment with production code.
Does a small project need a design system?
Not a comprehensive one, but defining variables for color, type and spacing plus a few core components early saves time even on small projects.
How do Figma variables get into code?
They can be exported as JSON via plugins or the Figma API and transformed into CSS variables, a Tailwind theme or mobile theme files. On simple projects, matching names and copying values by hand also works.
Planning a project like this?
Plan it in 10 steps