Design Systems

What is a Design System?

Imagine you have a team of 5 designers working on the same product. Each one designs buttons differently — one makes rounded corners, another makes them square, one uses a shadow and another does not, each chooses a different shade of blue. The result? A product that looks like 5 different applications.

A design system is the single source of truth that solves this problem. It is a collection of rules, components, and standards that ensure everyone on the team designs and builds in the same way.

Design System = Reusable components + Usage rules + Documentation

Popular Design Systems

Material Design (Google): The most famous design system — used in all Google products
Human Interface Guidelines (Apple): Apple's design standards for iOS and macOS
Carbon (IBM): An open-source design system
Ant Design: A very popular design system in enterprise applications
Atlassian Design System: The system behind Jira, Confluence, and Trello
Chakra UI / shadcn/ui: Popular systems in the React world

Why Do You Need a Design System?

1. Consistency

Every button, every card, every form in the product looks and behaves the same way. The user does not need to learn new patterns on every page.

2. Speed

Instead of designing every component from scratch, you pull ready-made, tested components. A design that used to take a week can be done in a day.

3. Quality

Components in a design system are tested and reviewed. They have accessibility built in, different states (hover, focus, disabled), and comply with performance standards.

4. Scalability

When the product grows and new designers and developers join, the design system makes them productive from day one without a long training period.

5. Communication Between Designers and Developers

Components with the same names and properties in both design and code. The designer says "use Button/Primary/Large" and the developer understands exactly what that means.

Design Tokens

Tokens are the atoms upon which the design system is built. They are named values that express visual properties.

Types of Tokens

1. Global/Primitive Tokens

The fundamental values everything is built on:

Colors: blue-500: #3B82F6, gray-100: #F3F4F6
Fonts: font-sans: "Inter", font-size-base: 16px
Spacing: space-4: 16px, space-8: 32px
Radii: radius-sm: 4px, radius-lg: 12px
Shadows: shadow-sm: 0 1px 2px rgba(0,0,0,0.05)

2. Semantic/Alias Tokens

Values with functional names that reference the global tokens:

color-primary: {blue-500} — the primary color
color-error: {red-500} — error color
color-text-primary: {gray-900} — primary text color
color-background: {white} — background color
font-size-heading: {font-size-xl} — heading size

3. Component Tokens

Values specific to a particular component:

button-padding-x: {space-6} — horizontal spacing inside the button
button-border-radius: {radius-lg} — button corner radius
card-shadow: {shadow-md} — card shadow

Why Are Tokens Important?

When you need to change the primary color of the entire product, you change the value of one token instead of changing 500 different places. And when you need to implement Dark Mode, you only change the values of the semantic tokens.

Tokens in Figma

Figma has a Variables system that performs the same function as tokens:

Create a new Collection (e.g., "Colors")
Add variables with functional names (primary, background, text)
Set different values for each Mode (Light, Dark)
Use variables in your design instead of direct values

Components

Components are the building blocks of the design system. Every reusable visual element is a component.

Component Classification

1. Atoms

The smallest elements that cannot be divided further:

Button
Input field
Icon
Label/Tag
Spinner

2. Molecules

Components built from two or more atoms:

Input field + label + error message = Form Field
Icon + text + arrow = Menu Item
Image + name + description = Avatar + Name

3. Organisms

Larger components built from molecules:

Navigation bar (Navbar)
Product card
Login form
Data table

4. Templates

Full-page layouts built from organisms:

Home page
Settings page
Dashboard

Building a Component in Figma

Let's build a complete button component:

Step 1: States

Every button needs these states as Variants:

Default: the normal state
Hover: when the mouse is over it
Pressed/Active: when it is clicked
Focused: when navigated to with the keyboard
Disabled: when unavailable
Loading: when loading

Step 2: Types

Primary: primary color — for main actions
Secondary: neutral color — for secondary actions
Outline/Ghost: no background — for less important actions
Danger/Destructive: red — for dangerous actions (delete)

Step 3: Sizes

Small: 32px height — for tight spaces
Medium: 40px height — the default size
Large: 48px height — for important actions

Step 4: Flexible Content

Text only
Icon + text
Text + icon
Icon only

Component Properties in Figma

Instead of creating a Variant for every possible combination (which can reach hundreds), use Component Properties:

Boolean Property: show/hide an element (e.g., show icon)
Instance Swap: swap one icon for another
Text Property: change text without detaching the component

Documentation

A design system without documentation is just a component library. Documentation is what turns it into a real system.

What Needs to Be Documented?

For each component:

Description: what the component is and when it is used
Types and states: all available Variants and states
Usage guidelines: when to use it and when not to
Do's and Don'ts: correct and incorrect examples
Accessibility: access standards — colors, contrast, keyboard navigation
Live examples: interactive examples from the real application

Documentation Tools

Storybook: the most common — documents code components interactively
Zeroheight: connects Figma and code
Dedicated website: some companies build their own documentation site
Figma itself: documentation pages inside the Figma file itself

Building a Design System from Scratch

Phase 1: Audit

Before building anything, study the current state:

Take screenshots of every screen in the product
Gather all buttons in one place — you will find 10 different button styles
Gather all colors — you will find 20 shades of gray instead of 5
Gather all font sizes — you will find chaos

This audit reveals the scale of the problem and defines building priorities.

Phase 2: Foundations

Start with tokens:

Color palette: primary + secondary + neutral + semantic colors (success/error/warning/info)
Type scale: size, weight, line height for each level
Spacing scale: 8-point system
Radii and shadows: unified values
Breakpoints: when the layout changes

Phase 3: Core Components

Start with the components every page needs:

Button (with all types and sizes)
Input / Text Field
Select / Dropdown
Checkbox & Radio
Toggle / Switch
Card
Avatar
Badge / Tag
Modal / Dialog
Toast / Notification

Phase 4: Composite Components

After the core components:

Navbar / Header
Sidebar
Table
Form layouts
Page templates

Phase 5: Documentation and Publishing

Document every component
Publish the library in Figma (Team Library)
Ensure code is synchronized with design
Train the team to use the system

Design System Maintenance

A design system is not a project that ends — it is a living organism that requires ongoing maintenance.

Governance

Who makes design decisions? Define a responsible team or person
How are new components added? A clear process — proposal → review → build → document → publish
How are issues reported? A clear feedback channel
How often is the system updated? A regular update schedule (weekly or monthly)

Versioning

Use Semantic Versioning: Major.Minor.Patch
Major (1.0 → 2.0): major changes that may break compatibility
Minor (1.0 → 1.1): new components or improvements
Patch (1.0.0 → 1.0.1): bug fixes

Measuring Success

How do you know if the design system is successful?

Adoption rate: how many designers and developers are actually using it
Design speed: has design become faster?
Product consistency: do the screens look more consistent?
Team satisfaction: are designers and developers happy with the system?

Common Mistakes in Design Systems

1. Building Before It's Needed

Do not build a complete design system from day one. Start small and grow as needed. A small system that is used is better than a large system that is ignored.

2. Not Involving Developers

A design system is not just for designers. Developers are essential partners — they must be part of decisions from the start.

3. Over-complexity

A component with 50 Variants cannot be used correctly. Simplicity is more important than comprehensiveness.

4. Ignoring It After Launch

A design system that is not updated will die. Dedicate weekly time to maintenance and updates.

5. No Documentation

A component without documentation will be used incorrectly or not used at all.

Practical Exercise

Build a Mini Design System for a task management application:

Foundations: define a color palette (3 colors + functional colors), type scale (5 sizes), and spacing scale
Build 5 components: Button, Input, Card, Badge, Avatar — each with its types and states
Create Variables in Figma for all tokens
Build a page using only the components — a simple task list
Document one component completely — Do's and Don'ts + usage guidelines
Create Dark Mode by changing Variables only

This exercise will make you understand that building a design system is not easy — but when it works properly, it changes the way the entire team works.