Build a Design System in Figma
A step-by-step Figma workflow for turning a website’s repeated colors, spacing, typography, controls, and layout rules into a small working design system

Build a basic Figma design system by auditing real pages, defining primitive and semantic variables, creating responsive type and spacing rules, and turning repeated interface parts into documented components. Start with a small website scope, model meaningful states and content variation, and keep a clear mapping between Figma names and production code.
A basic design system should make a real website easier to continue, not turn Figma into a museum of immaculate components. Build it from repeated decisions in the project you have, then add structure only where it prevents drift.
The three-card reference on Refframe is a useful starting point. The cards share radius, padding, icon treatment, title role, description role, and column behavior. A component should capture that common anatomy while surviving a longer product name, missing icon, different description length, and narrow viewport.
Begin with three representative pages
Do not start by drawing a universal button. Select a small set of pages that exposes the website’s actual needs. A homepage shows marketing hierarchy. A detail or pricing page shows repeated content structures. A contact, signup, or checkout page exposes controls and states.
Audit them for:
- colors and their jobs;
- text roles rather than isolated font sizes;
- repeated spacing and container widths;
- grids, gutters, alignment lines, and breakpoints;
- buttons, links, fields, cards, navigation, and media;
- hover, focus, error, empty, loading, and disabled states;
- repeated section patterns such as feature grids, testimonials, pricing, and FAQs.
Mark near-duplicates. Two grays may perform different roles, or they may be accidental drift. Decide before turning either into a token.
Give the Figma file four clear areas
A compact file structure is enough:
- Foundations for variables, color, type, spacing, grids, radius, and effects;
- Components for reusable controls and content units;
- Patterns for page-level combinations such as hero, feature grid, and form section;
- Playground for stress tests, edge cases, and work in progress.
Keep finished product screens separate from the library. Designers should be able to inspect the system without crossing a field of current-page mockups, and they should be able to test components without publishing experiments.
Build primitives first, then semantic variables
Figma variables support color, number, string, and boolean values, plus collections and modes. Start with primitive values such as a neutral palette and a spacing scale. Then create semantic aliases that describe use: text-primary, text-muted, surface-default, surface-emphasis, border-subtle, action-primary, and focus-ring.
Semantic names keep components stable when the visual value changes. If action-primary moves from blue to green, the button does not need a new role. Modes can hold contexts such as light and dark themes or compact and comfortable spacing, but do not create modes merely because the feature exists. Each mode should represent a real product condition.
Use a small spacing scale. A sequence such as 4, 8, 12, 16, 24, 32, 48, and 64 is often enough for a website, but the correct scale is the one visible in your audit. Name the purpose when a value has a special role, such as layout-gutter or section-gap, instead of asking people to remember which number belongs where.
Define typography by role
Create roles for display, page title, section title, card title, body, label, and caption. For each role, record family, weight, size, line height, and intended use. Test long English and Russian headings if both languages matter. A heading that works only with a six-word demo is not ready.
Keep the scale small enough that hierarchy remains obvious. If two roles are visually indistinguishable, combine them or explain the functional difference.
Build components around behavior
Start with controls and units that already repeat: button, text link, input, textarea, checkbox, card, navigation item, and media block. Use variants for meaningful alternatives such as hierarchy or state, not for every cosmetic possibility. Use boolean, text, and instance-swap properties when they let an instance adapt without detaching.
A button component may need hierarchy, size, icon position, and state. It probably does not need a separate variant for every possible label. A card may need media presence, orientation, and interaction state. It should accept actual content and keep alignment without manual nudging.
Figma recommends a documented naming structure because component organization follows the file and page hierarchy. Choose names that can map to code, such as Button/Primary and Card/Feature, and keep the same vocabulary in tickets and documentation.
Use auto layout as a behavior model
Auto layout can control direction, gap, padding, alignment, wrapping, and minimum or maximum dimensions. Use it to express how a component responds when content changes.
Stress-test each component:
- replace the label with the longest plausible copy;
- remove optional media;
- switch to the other language;
- resize the container through likely breakpoints;
- increase text size;
- add and remove list items;
- check that focus and error messages have space.
A desktop frame and a mobile frame are examples. Resizing rules explain what happens between them.
Document the decision beside the component
Figma supports descriptions on styles, components, and variables, including links to external documentation. For the first version, each important component needs four notes: when to use it, when not to use it, supported states, and implementation link or status.
Add one good example and one failure case. Show a card with realistic copy, not only a polished placeholder. Show what happens when a button wraps, when a form error appears, and when an image is unavailable.
Publish only what is ready
Before publishing the library, remove detached duplicates, unresolved naming experiments, and components without a clear owner. Check that every published variable is used, every component has a purpose, and the component names match the handoff vocabulary.
Create a Refframe board for the references that informed the system. Tag each example by the decision it supports: card anatomy, type hierarchy, navigation behavior, or responsive transformation. This keeps visual evidence close to the formal rules without confusing inspiration with implementation.