How to Set Up a Figma Design System: A Practical Guide

Setting up a design system in Figma is one of those projects where good structure upfront saves weeks of frustration later. Getting the file organization right, naming things consistently, and establishing a publishing workflow from the start means you're not scrambling to reorganize when your system grows.

Here's how to do it.

File structure

Don't put everything in one file. As a system grows, a single file becomes slow, hard to navigate, and difficult to maintain. Instead, split into purpose-specific files:

Foundations file. Contains your color tokens, typography styles, spacing tokens, shadow styles, and border radius values. These are the raw materials everything else builds on. No components live here — only styles and variables.

Components file. Your main component library. All main components live here, organized by category (Forms, Navigation, Feedback, Layout, etc.). This is the file you publish to your team library.

Documentation file. Usage guidelines, do/don't examples, and context for component decisions. Optional for small teams, essential for larger ones.

Product files. Your actual design work. These files consume the library from the Components file. They contain no main components — only instances.

Setting up your foundations

Before you build a single component, you need your foundations defined.

Color. Create Figma Variables for your color system. Set up your primitive color scales first (10 shades per hue). Then create a second variable group for semantic colors that reference your primitives. Use variable modes for light and dark themes.

Typography. Create Text Styles for every combination you'll use: Heading 1 through Heading 4, Body Large, Body Default, Body Small, Caption, Label, Code. Define font family, font size, font weight, line height, and letter spacing. Name them clearly: Heading/H1, Body/Default, Label/Small.

Spacing. Create Number Variables for your spacing scale: 4, 8, 12, 16, 24, 32, 40, 48, 64, 80, 96, 128. Name them spacing/1, spacing/2, etc. (or spacing/xs, spacing/sm etc — pick one and stick to it).

Shadows. Create Effect Styles for your elevation levels: Shadow/SM, Shadow/MD, Shadow/LG, Shadow/XL. Use these consistently — don't type out shadow values manually in components.

Border radius. Create Number Variables: radius/none (0), radius/sm (4px), radius/md (8px), radius/lg (16px), radius/xl (24px), radius/full (9999px).

Creating and organizing components

Build components in this order: atoms first, then molecules, then organisms. Atoms are your smallest elements (icons, badges, avatars). Molecules are combinations (button, input, tag). Organisms are complex compositions (navigation bar, card, modal).

Use a consistent naming convention across every component. The most common pattern: Category/ComponentName. Examples: Forms/Input, Forms/Select, Navigation/TabBar, Feedback/Toast, Overlay/Modal.

Every component should have:

• All relevant states (default, hover, focus, active, disabled, loading, error)
• All relevant variants (sizes, types)
• Component properties exposed for common overrides (label text, icon visibility, icon swap)

Keep a _Working page in your components file where you build and iterate on new components before they're ready for the library. Only finished, reviewed components move to the published pages.

Publishing to team library

When components are ready, publish your file to your Figma team library. Go to Assets → Team Library → Publish. Write a clear publish note — what was added, changed, or fixed. This becomes your changelog.

Consumers of your library (product designers working in product files) will see an "Update available" banner when you publish changes. They can review what changed before updating.

Only one person or a small group should have the ability to publish library updates. Open publishing creates chaos.

Version control in Figma

Figma doesn't have Git-style branching in all plans, but you have options:

Figma branching (available on Organization plan) lets you create branches from your main file, make changes, and merge back. This is the cleanest workflow for significant changes to the system.

Manual versioning (free plan compatible) means using named versions. Before making changes, save a named version: File → Save to Version History → "v1.4.0 — before button redesign". If you need to revert, you have that checkpoint.

Duplicate and archive. Before a major overhaul, duplicate your component file to create a snapshot: "Components — Archive 2026-03." Keep it read-only.

Governance: how new components get added

Without a process for evaluating and adding new components, your design system becomes a dumping ground. Establish a simple governance model:

1. Designer identifies a need for a new component
2. They check if an existing component can be extended to cover the case
3. If a new component is genuinely needed, they propose it in a shared document or Notion page: use cases, proposed design, proposed API
4. A review happens (async is fine for small teams)
5. Approved components get built, reviewed, and published

The key question for every proposed component: does this appear in at least three places in the product? One-off UI rarely belongs in a shared library. It adds maintenance burden for limited reuse.

Try Figma Free

The code side: Storybook

Your Figma design system needs a code counterpart. Storybook is the standard tool for this — it's a development environment that documents and visually tests your component library.

Try Storybook Free

Keep your Figma component names and your Storybook component names aligned. If your Figma component is called Forms/Input, the Storybook story should be Forms/Input. When names match, handoffs are faster and there's less "which one is the right input?" confusion.