Building a Design System in Figma

A Figma design system is built in a fixed order: styles first (color, type, effects, spacing), then components built on top of those styles, then variants and auto layout to make components flexible, and finally a naming and file structure that keeps the whole thing navigable as it grows. Skip the order and you end up with a component library that looks consistent today and drifts within a month. Our Figma e-commerce theme bundle is built exactly this way, which is a useful reference point if you want to see the end state before building your own.

This guide walks through building a design system in Figma from a blank file, in the order that actually holds up over time — not the order most tutorials present it in. It is written for merchants and designers who are either customizing a Figma-based ecommerce theme or starting a storefront design from scratch and want it to stay maintainable past the first few screens.

Why Order Matters More Than Tooling

Figma gives you styles, components, variants, and auto layout as separate features, and it is entirely possible to use all four without ever building something you would call a design system. The difference between a folder of reusable pieces and an actual system is dependency order: every component should reference a style, never a hardcoded value, so that changing one color or type size ripples through every screen that uses it. Get this backwards — build components first, apply colors as you go — and you end up manually hunting down every button, badge, and card the next time a brand color changes.

Treat the system as four layers, built bottom-up: foundations (color, type, spacing, effects), primitives (buttons, inputs, badges, tags), patterns (product cards, nav bars, filter panels), and templates (full page layouts assembled from patterns). Each layer should only depend on the layer below it.

Step 1: Define Color Styles

Start with color, because everything else references it. Create local styles (or variables, if you are on a plan that supports Figma variables) for a small, deliberate palette rather than every hex value that appears in your mockups. A workable starting set for an ecommerce storefront looks like this:

• Brand: primary and a secondary accent, used sparingly for calls to action and highlights.
• Neutral scale: five to seven steps from near-white to near-black, used for text, borders, and backgrounds.
• Semantic colors: success, warning, and error/destructive, used for stock status, form validation, and sale badges.
• Surface colors: background, card, and overlay, so light and dark contexts stay distinct from raw neutral steps.

Name styles by role, not by appearance — text/primary rather than dark-gray-1. Role-based names survive a rebrand; appearance-based names lie the moment you change the underlying value. If you are using Figma variables rather than plain styles, this is also where you would set up a light and dark mode pair, since variables let a single semantic token resolve to different raw values per mode.

Step 2: Define Type Styles

Type styles should be similarly small and role-based: a handful of heading sizes (H1 through H4 is usually enough for a storefront), body text in one or two sizes, and a caption or label style for meta text like SKU numbers or shipping notes. Resist the temptation to create a new type style for every screen — if you find yourself wanting a size that does not exist, that is a signal to reconsider the layout, not to add a ninth heading style.

Lock in a type scale early (a 1.25 or 1.333 ratio between steps is a reasonable, well-worn default) so that headings feel proportioned rather than arbitrary. Set line-height and letter-spacing inside the style itself, not as manual overrides on individual text layers — overrides are exactly the drift a design system exists to prevent.

Step 3: Build Primitive Components

With foundations in place, build the smallest reusable pieces: buttons, inputs, checkboxes, badges, tags, and icons. Every layer inside these components should reference a color or type style — never a raw hex value or a manually typed font size. This is the step where the discipline from steps 1 and 2 either pays off or gets undone.

Use auto layout on every primitive that can contain variable-length content — a button whose label might be "Add to Cart" or the longer "Add to Cart — Out of Stock" needs to resize predictably rather than clip or overflow. Auto layout with defined padding, gap, and resizing behavior (hug vs. fill) is what makes a component actually reusable across contexts instead of only working in the one frame it was designed in.

Use variants instead of duplicate components

A button needs a primary, secondary, and destructive state, plus default, hover, and disabled states, plus maybe small and large sizes. That is a lot of combinations — and the wrong way to handle it is a separate component for each one. Use Figma's variants feature to combine them into a single component with properties (type, state, size), so instances in your designs can be swapped between variants from one properties panel instead of being deleted and re-placed.

Keep variant property names consistent across components — if buttons use a property called State with values default/hover/disabled, badges and inputs should use the same property name and the same value set where it applies. Consistency here makes the system predictable to anyone else who opens the file, including a future version of you six months later.

Step 4: Build Patterns From Primitives

Patterns are the ecommerce-specific building blocks: a product card, a cart line item, a filter sidebar, a review summary block. Build these by nesting primitive components rather than redrawing rectangles and text layers from scratch. A product card, for example, should nest the actual badge component for a sale tag and the actual button component for "Add to Cart" — not a copy of one that has since drifted from the source.

This is also where auto layout compounds in value: a product card built with nested auto-layout frames will reflow correctly when a product title wraps to two lines, or when a badge is added or removed, instead of requiring manual repositioning of every element below it.

Step 5: Assemble Templates

Templates are full pages — a product listing page, a product detail page, a cart drawer — built entirely from patterns and primitives. If you find yourself drawing something net-new at the template stage, that is usually a sign a pattern is missing one layer down, and it is worth pausing to build it properly rather than solving it as a one-off inside the template.

This is the stage where a well-built theme file is genuinely useful as a reference or starting point. Our Wosa Figma theme and Electronix Figma theme both ship with templates assembled this way — foundations, primitives, and patterns all wired together — so you can see a finished four-layer system before committing to your own naming and structure decisions, or customize the templates directly if the visual direction already fits.

Naming and File Organization

A design system that works alone in your head but confuses a collaborator is not really a system yet. A few conventions make a large file navigable:

• Slash-separated names for styles and components (color/text/primary, button/primary/default) so Figma's built-in grouping in style and asset pickers organizes itself automatically.
• Page structure by layer: separate Figma pages for Foundations, Primitives, Patterns, and Templates, so a new collaborator can find the right layer without scrolling through a flat list of frames.
• A cover page listing what the file contains and a short changelog of major updates — useful the moment more than one person touches the file.
• Component descriptions (Figma lets you attach a description to any component) explaining intended usage, especially for anything with non-obvious variants.

Maintaining the System Over Time

A design system's real test is not the first week, it is month six, after a dozen new pages have been designed. A few habits keep it from decaying:

• Publish the file as a Figma library (available on Professional plans and above) so other files consume components by reference instead of by copy-paste, and updates propagate automatically.
• Review new components before they are added to the system — a one-off button variant made for a single promotional banner does not belong in the shared library.
• Periodically audit for detached instances — components that were disconnected from the library and edited locally, which is how drift creeps back in even with a solid system in place.
• Version deliberately. A visible changelog on the cover page, even a short one, saves confusion when a component's appearance changes and someone wants to know why.

Where a Theme Bundle Fits In

Building a system from a blank file is the right call when your brand or product needs genuinely custom patterns. But for a lot of ecommerce projects, the four-layer structure above is largely the same regardless of niche — product cards, filter panels, and cart drawers do not vary that much in structure from one storefront to the next. In that case, starting from a theme file that already has foundations, primitives, and patterns wired together correctly can save weeks of setup, leaving your own design time for the parts that are actually specific to your brand: color, imagery, and copy. Browsing our Figma themes is a reasonable way to see what a fully wired four-layer system looks like across a few different niches before deciding whether to build from scratch or adapt one.

Frequently Asked Questions

Should I use Figma variables or plain styles for my design system?

Variables add real value if you need light/dark mode, multiple brand themes, or responsive value swaps, since a single variable can resolve differently per mode or breakpoint. If you only need one consistent look, plain styles are simpler to set up and perfectly sufficient — you can migrate to variables later without redoing your components, since both approaches attach to the same layers.

How many components does a design system actually need to start?

Fewer than most people expect. A workable starting set is: buttons, inputs, badges, one or two card patterns, and a navigation bar. Add components as real screens demand them rather than front-loading dozens of components you have not yet needed — an unused component is also unmaintained the first time its underlying style changes.

Can I turn an existing set of mockups into a design system after the fact?

Yes, though it takes more discipline than starting clean. Audit existing screens for repeated colors and type sizes, consolidate them into styles, then rebuild the most-used UI pieces as components referencing those styles, replacing instances screen by screen. It is slower than building foundations-first, but far faster than continuing to design without any system at all.

Do I need a paid Figma plan to build a design system?

No — styles, components, variants, and auto layout are all available on Figma's free tier, which is enough to build and use a system within a single file. Publishing the system as a shared library that other files can consume, and Figma variables with multiple modes, require a paid plan, and matter more once more than one person or project is drawing from the same system.