When I first started building design systems in Figma, I spent hours hunting down components across pages whenever I needed to push a small change — a button padding, a secondary color, a different icon state. It felt like firefighting: update here, forget one instance there, then wonder why the layout broke. That changed when I embraced Variants and Auto Layout together. These two features, used intentionally, turn scattered components into predictable, updatable building blocks that scale across pages and projects.
Why variants + auto layout matter
Variants let you group related component states (like default / hover / disabled, or primary / secondary / ghost) into a single component set with properties you can toggle. Auto Layout makes components responsive to content changes — text length, icon size, or added padding — so instances adapt without manual resizing.
Combine them and you get a system where one change to a master component propagates reliably across hundreds of instances, while each instance keeps sensible overrides (like label text or icons). In practice, this reduces repetitive work and prevents layout drift when you make design decisions.
Starting point: build a sensible base component
I usually start with a single, clean frame that represents the most generic version of a component — for example, the base button. I pay attention to four things:
- Auto Layout: Apply Auto Layout in the direction of the content (usually horizontal for buttons). Use consistent spacing values and padding tokens if available.
- Text styles: Use Figma text styles for font, size, and letter spacing so updates cascade from the style library.
- Icon treatment: Place icons inside the Auto Layout frame with consistent spacing. Use Fill rather than Raster so color changes work across instances.
- Constraints: Keep the frame’s constraints flexible (e.g., hug contents) unless you need fixed width variants.
Designing variants the right way
Once the base is solid, create variants. I group states and sizes into the same set rather than making separate components for every permutation. For example, a button component set could have these properties:
- type: primary / secondary / ghost
- size: small / medium / large
- state: default / hover / pressed / disabled
Use descriptive property names — not “Variant 1/2” — so teammates and developers can understand and use them easily. In the Figma right panel, rename property fields (click the property name within the variants panel).
Auto Layout patterns that prevent surprises
Auto Layout is powerful but has gotchas. Here are patterns I rely on:
- Hug contents for buttons unless you need fixed-width: this keeps padding stable when text changes.
- Use padding values instead of adding empty rectangles for spacing; they’re easier to adjust globally.
- Use Min width when you want a minimum size (e.g., icon-only buttons) while still allowing expansion.
- When stacking multiple elements, wrap them in a parent Auto Layout frame that defines the spacing and alignment. This keeps internal structure consistent if you add or remove elements.
Instance overrides — what to allow and what to avoid
Instances in Figma let you adjust certain properties locally. Some overrides are desirable (label text, icon visibility), but others can create maintenance problems (changing padding, nested layer names, or accidentally detaching instances). My rule of thumb:
- Allow content overrides: text, icon selection, link targets.
- Prevent structural overrides: padding, layout direction, spacing. Achieve these through variants instead.
- Avoid detaching instances unless you intentionally fork a new component. Keep the source of truth intact.
Naming conventions that scale
Names are critical. I use a compact, consistent scheme like component/property=value. Example for a button variant:
| Component set | Example |
|---|---|
| Button | type=primary | size=medium | state=default |
This naming helps when searching and when exporting specs to developers. Figma's property names also map nicely to design token systems if you later automate style exports with plugins like Tokens Studio or Figma Tokens.
Practical workflow to speed updates across pages
Here’s the process I follow whenever I need to implement a change that should propagate site-wide:
- Create or refine the master component set in a dedicated “Library” file or components page.
- Use Auto Layout to ensure the component is resilient to change.
- Update styles (colors, text styles) at the source where possible. If you use shared styles or tokens, edit them first.
- Publish the changes to the team library. Figma notifies files using those components. I leave a clear changelog entry — one sentence explaining the fix.
- Open the files that use the component and Accept Library updates. If some instances look off, inspect overrides rather than making local structural changes.
Handling tricky cases
Some scenarios need extra attention:
- Different padding needs across pages: Instead of allowing arbitrary padding changes on instances, add a size property or create a spacing modifier variant (e.g., spacing=tight/normal/loose).
- Icon-only vs. label buttons: Use components that adjust with Auto Layout and provide separate variants (content=icon / text / both).
- Complex layouts breaking after a change: Check for hidden layers, absolute positioning, or frames that were ungrouped. These often cause auto layout to fail.
Useful plugins and integrations
I rely on a small set of tools to keep systems tidy and consistent:
- Figma Tokens — to manage color, spacing, and typography tokens centrally.
- Instance Finder — to locate all instances of a component when auditing changes.
- Design Lint — catches inconsistent text styles or colors that might override your intentions.
Performance tips for very large files
Large design systems can slow Figma down. I keep files snappy by:
- Splitting component libraries into logical files (UI, icons, illustrations).
- Keeping only necessary pages in working files and using published libraries for components.
- Avoiding ultra-large images inside components; use optimized SVGs when possible.
Examples from real projects
On a recent product redesign I worked on, we consolidated eight button components into a single set with three properties: type, size, and state. We converted hard-coded paddings into token-based values and used Auto Layout to ensure buttons expanded naturally when copy length increased. The result: a single change to the primary color token updated every instance across 25 screens, and we didn’t have to touch layout for any of them.
Another project involved a marketing site with dozens of CTA variants. We created a “CTA” component with content=lead / supporting and intent=primary / secondary, plus responsive size variants. Because instances only controlled text and link overrides, the design system stayed coherent even as copy evolved rapidly during A/B tests.
Quick checklist before publishing library updates
- All components use Auto Layout where appropriate.
- Text styles and color tokens are applied consistently.
- Variants use clear property names and cover expected permutations.
- Instance overrides are limited to content and safe visual changes.
- Document the change briefly in the library update message.
Variants and Auto Layout are not just Figma features — they’re a mindset. Design systems built around predictable, responsive components save time and mental overhead. Treat your components like code: single source of truth, meaningful versions, and careful change management. When you do, updates stop being a chore and start being a strategic lever.
