Component Variants & Design Tokens Explained
Understand how variants reduce complexity and tokens ensure consistency. Real examples show how to structure these in Figma for maximum efficiency.
Why Variants Matter in Modern Design
Building design systems without variants is like managing a wardrobe with only one outfit. You’ll spend time creating duplicate components when you could be focusing on actual design work. Variants let you bundle related component states into a single, organized unit.
Design tokens take this further. They’re the underlying values — colors, spacing, typography — that power your entire system. When you change a token, it cascades everywhere it’s used. We’re talking about eliminating those tedious find-and-replace nightmares across 200 files.
The combination of variants and tokens creates what we call a “living design system.” It’s maintainable, scalable, and honestly, way less frustrating to work with. Let’s walk through how to set this up properly in Figma.
Understanding Component Variants
A variant is essentially a version of a component that changes based on specific properties. Think of a button — it has different states (default, hover, active, disabled) and different sizes (small, medium, large). Instead of creating four separate button components, you create one with variants.
Here’s the structure you’ll want: Each property becomes a dimension. A button component might have properties for “State” (default, hover, pressed, disabled) and “Size” (small, medium, large). That’s 12 different button variations, all managed from one component. When you update the padding or corner radius, every single variation updates instantly.
We typically organize variants hierarchically. The primary property goes first — usually the most important visual distinction. Secondary properties follow. This keeps your component library readable even when you’ve got 20+ variants per component.
Design Tokens: The Foundation
Design tokens are the atomic values that define your entire visual system. They’re not just colors — though those are important. Tokens cover spacing (8px, 16px, 24px), typography (font sizes, line heights, weights), shadows, border radius, opacity levels, and more.
The magic happens when your components reference tokens instead of hardcoded values. You define a token called “Color/Primary/500” with the value #3B82F6. Every button, badge, and link that uses that token automatically inherits the same color. Need to adjust your brand blue? Change it once in the token definition, and it updates across your entire design system.
Naming conventions matter tremendously. We use a category/type/variant structure. “Spacing/Margin/Large” is immediately understandable. “S12” is not. Good token names act like documentation — developers and designers both understand what each token is for just by reading its name.
Setting It Up in Figma: The Process
Start by creating a tokens file. This isn’t a design file — it’s your reference library. Document every color, spacing value, and typography scale your system uses. We typically organize this into a main tokens page and then separate pages for each category.
Next, create your base component. Let’s use a button as an example. You’ll set up the variant properties in the main component settings. Create instances that represent each combination of properties. For a button with “Size” (small/medium/large) and “State” (default/hover/active), you’re creating 9 component instances within the main component.
Then comes the crucial step: Apply tokens to these components. The button padding uses your “Spacing/Padding/Medium” token. The background color uses “Color/Primary/500.” Text color uses “Color/Text/Primary.” Now when you need to adjust spacing across your entire system, you modify one token value.
- Create a dedicated tokens file
- Define all tokens with consistent naming
- Build base components with variants
- Apply tokens to component properties
- Test each variant combination
Real-World Best Practices
We’ve built design systems at agencies managing 50+ client projects. Here’s what actually works in practice.
Limit Variant Combinations
Don’t create variants for every possible state. Stick to the combinations that actually exist in your product. A button doesn’t need a “disabled + hover” variant because disabled buttons don’t respond to hover. Keep it practical.
Document Token Usage
Create a token documentation page that shows which token applies where. This becomes your communication bridge between design and development. Developers need to know that button padding uses “Spacing/Padding/Medium,” not guessing at pixel values.
Use Semantic Token Names
Avoid naming tokens by their values. “Color/Blue/500” isn’t as useful as “Color/Primary/Default.” Semantic names describe the purpose, not the appearance. This makes it easier to rebrand — change one token and your entire system updates.
Version Your System
Keep historical versions of your design system. When you introduce breaking changes, archive the old version. Teams working on legacy projects need access to the tokens and components they were designed with.
Sync with Development
Export your tokens in a format developers can use. JSON is standard. Tools like Figma Tokens or Storybook integration make this automatic. Your design changes should flow directly into code without manual translation.
Test Variant Performance
Large component libraries with many variants can slow down Figma. Monitor file performance. If you’re seeing lag, consider breaking very complex components into separate, simpler components rather than piling on variants.
Integrating Variants and Tokens Together
Here’s where it gets powerful. Variants handle the structural changes (a button that’s small versus large). Tokens handle the visual consistency (that button is always using your primary color). Together, they eliminate redundancy.
When you’re designing a new feature, you’re not picking colors or measuring spacing. You’re selecting from your existing variants and tokens. It’s faster, more consistent, and keeps everyone aligned. A designer in Toronto and a developer in Vancouver are using the exact same definitions.
The real benefit emerges during brand updates or design system evolution. You need to adjust your primary color from blue to teal? One token change. Need to increase spacing across the board for better breathing room? Update your spacing tokens. Both of these ripple through every component, every variant, every design file using your system.
Moving Forward
Component variants and design tokens aren’t just features in Figma — they’re a shift in how you approach design systems. Instead of managing hundreds of individual components, you’re managing a smaller set of thoughtfully structured components with clear, reusable values.
Start small if you’re new to this. Pick one component — maybe a button or card — and build out its variants properly. Create a basic token set for colors and spacing. Get comfortable with how they interact. Then expand from there. Most teams find that after the initial setup investment, they’re moving faster and maintaining consistency more easily.
The systems that scale aren’t the ones with the most components. They’re the ones with the most thoughtful structure. Variants and tokens give you that structure.
Ready to build your system?
These principles apply whether you’re working on a personal project or an enterprise design system. The fundamentals remain the same — smart organization, consistent naming, and strategic use of components and tokens.
Explore More Design System GuidesDisclaimer: This article provides educational information about design systems, component variants, and design tokens in Figma. The approaches and practices discussed reflect common methodologies in the design community. Your specific implementation may vary based on your project requirements, team structure, and organizational needs. Always test workflows within your own context before implementing them across your entire design system. Design tool features and capabilities may change with software updates.
