Figma Renk Stilleri vs Değişkenler: Ne Zaman Hangisi Kullanılır?

Figma introduced color variables in 2023, and the design community immediately asked: what happens to my existing styles? Do I migrate everything? Can I run both simultaneously? What do variables actually do that styles cannot?

The short answer is that color styles and color variables are not competing features — they solve different problems. Styles are document-level presets. Variables are token-based architecture with modes, aliasing, and code export capabilities. Most mature design systems will end up using both, in different roles.

This guide breaks down the mechanical differences, when each tool is the right choice, how to plan a migration, and how to structure color workflows that scale across large teams.

What Are Figma Color Styles?

Color styles (now called "local styles" in Figma's panel) are named color presets stored at the document or library level. They have been part of Figma since the early days, predating variables by years.

How styles work

A color style is simply a named swatch. You create a style named Primary/Blue, set its color to #2563EB, and then apply that style to any shape, text, or effect. When you update the style definition, every element using it updates automatically.

Styles support: - Solid colors — standard hex/RGB/HSL values with optional opacity - Linear, radial, and angular gradients — no variable can store a gradient - Image fills — embedded or linked images as fills - Library publishing — styles can be published to a shared team library and consumed by other files

What styles cannot do

Styles have two significant limitations:

1. No modes — a style called Background has exactly one value. You cannot define a light mode value and a dark mode value for the same style. Switching themes requires manually swapping styles or using a plugin.

2. No aliasing — you cannot create a style that references another style. Primary/Button cannot point to Blue/500; it stores its own independent color value. This means two styles can have the same value without being linked — change one, the other does not follow.

What Are Figma Color Variables?

Color variables, introduced in June 2023 (Variables API) and available to all Figma plans, implement a token-based architecture directly inside Figma.

The structure of variables

Variables live in collections, and each collection can have multiple modes. A collection is a named group (e.g., "Primitives" or "Semantic"). A mode is a context variant (e.g., "Light" and "Dark", or "Brand A" and "Brand B").

Each variable has: - A name (following a slash-separated path, e.g., color/background/primary) - A value per mode — each mode can have a different hex value - An optional alias — the value can point to another variable instead of a raw color

Variable aliasing: the key capability

This is where variables fundamentally change how color systems work. Consider this structure:

Primitive collection (no modes needed):

blue/100  →  #EFF6FF
blue/500  →  #3B82F6
blue/700  →  #1D4ED8
blue/900  →  #1E3A8A

Semantic collection (Light mode, Dark mode):

background/primary    → Light: alias(blue/100)   Dark: alias(blue/900)
text/interactive      → Light: alias(blue/700)   Dark: alias(blue/100)
border/focus          → Light: alias(blue/500)   Dark: alias(blue/500)

Now when you use background/primary, Figma resolves it to #EFF6FF in Light mode and #1E3A8A in Dark mode — automatically. Switching the frame's mode from Light to Dark recolors every element that uses a semantic variable.

Variable types

Figma variables support four types: Color, Number, String, and Boolean. Color variables specifically accept hex values or aliases to other color variables.

Key Differences Between Styles and Variables

Scope control in variables

Variables have a scoping system that styles lack. When you create a color variable, you can specify where it is allowed to be applied:

• All scopes — anywhere color is used
• Fill color — only as a fill, not stroke or effect
• Stroke color — only as border/stroke
• Effect color — only in shadows and blurs
• Frame background — only as the frame background fill

This prevents design system consumers from accidentally using a semantic color in the wrong context. A variable called background/surface can be scoped to frame backgrounds only, so it never appears as an option when a designer is setting text color.

When to Use Color Styles

Use color styles when:

You need to store gradients. Variables cannot hold gradient definitions. If your brand palette includes a signature gradient — say, a #FF6B35 to #F7C59F warm gradient — store it as a style. Styles are the only native Figma mechanism for gradient presets.

You are working in a simple single-theme project. If your product has no dark mode and no multi-brand requirements, the overhead of setting up a full variable collection with modes adds complexity without benefit. A flat set of named styles is easier to maintain.

You are supporting older Figma users or workflows. Variables require Figma's newest clients. If your team has members on older versions, or if you publish to external collaborators who may not have variables support, styles are universally compatible.

You are defining granular visual properties. Styles excel at representing specific visual decisions — a shadow's color, a specific icon's fill. For properties that will never need mode switching, a style is simpler.

When to Use Color Variables

Use color variables when:

You are building or maintaining a design system with dark mode. This is the flagship use case. Modes eliminate the manual work of maintaining parallel light and dark stylesheets. Define semantic tokens once, assign values per mode, and let Figma handle the rest.

You need to export tokens to code. Variables can be exported as JSON through Figma's REST API or community plugins like Tokens Studio, enabling direct sync with design token workflows (Style Dictionary, @design-tokens/ format). Styles have no equivalent code export.

You support multiple brands or themes in a single component library. Multi-brand component libraries — where the same button component renders in Brand A's primary blue #2563EB or Brand B's primary violet #7C3AED — are straightforward with variable modes. Without modes, you need parallel component sets or manual reskinning.

You want aliasing to enforce token hierarchy. Aliasing ensures that a semantic token like interactive/primary always derives from the same primitive. When the primitive changes, all semantic tokens that alias it update automatically. This is how design token methodologies like Material Design 3 and the W3C Design Tokens spec work.

You are using Figma's prototype variable features. Figma's prototype interactions can toggle variable modes, change variable values, and respond to variable-driven conditions. This enables interactive prototypes that simulate real theme switching, form validation states, and dynamic content — none of which is possible with styles.

Migration Path: From Styles to Variables

Migrating an existing style-based system to variables requires careful planning. A hard cut-over is disruptive; most teams run parallel systems during a transition period.

Step 1: Audit your existing styles

Export your current styles list. Categorize them: - Primitives (raw brand colors like Blue 500, Neutral 900) — these migrate directly to a Primitive variable collection - Semantic (intent-named like Primary Button Background, Error Text) — these become Semantic variable aliases - Gradients — keep as styles; they have no variable equivalent - One-offs (colors used in exactly one place) — consider inlining rather than migrating

Step 2: Build the primitive collection

Create a variable collection called "Primitives" with a single mode (primitives rarely need modes). Populate it with your raw palette. If you use a systematic shade scale, use ColorFYI's Shade Generator to generate the complete 50–950 scale for each hue, then enter all values.

Example primitive naming:

blue/50    → #EFF6FF
blue/100   → #DBEAFE
blue/500   → #3B82F6
blue/700   → #1D4ED8
blue/900   → #1E3A8A
neutral/50  → #F8FAFC
neutral/900 → #0F172A

Step 3: Build the semantic collection with modes

Create a second collection called "Semantic" with modes for your contexts (Light, Dark; or Brand A, Brand B). For each semantic token, set the value per mode as an alias to the appropriate primitive:

background/page       → Light: blue/50    Dark: neutral/900
background/surface    → Light: neutral/50  Dark: neutral/800
text/primary          → Light: neutral/900 Dark: neutral/50
text/interactive      → Light: blue/700    Dark: blue/300
interactive/primary   → Light: blue/500    Dark: blue/400

Step 4: Update components to use semantic variables

This is the most time-consuming step. Open each component and replace style-based fills with the equivalent semantic variable. Do this in a dedicated branch so your main library remains stable during the transition.

Practical order: Start with the most-used components (buttons, inputs, typography, cards). Leave less-used components on styles temporarily — both can coexist in the same file.

Step 5: Publish and communicate

Once the semantic variables cover your most-used components, publish the updated library with a clear changelog. Document which styles are deprecated and which variables replace them. Provide a mapping table (style name → variable name) for designers migrating individual files.

Best Practices for Team Color Workflows

Naming conventions matter

Adopt consistent token naming before you start building. A common three-tier approach:

1. Global/Primitive tier: {hue}/{shade} — e.g., indigo/400
2. Semantic tier: {category}/{role} — e.g., background/surface, text/primary, border/interactive
3. Component tier (optional for large systems): {component}/{element}/{state} — e.g., button/background/hover

Avoid encoding visual descriptions in semantic names. primary/blue encodes the specific hue — if you rebrand, the name becomes wrong. interactive/primary describes purpose and survives any visual rebrand.

Keep primitives lean

The primitive collection should contain every raw color in your palette, but resist the urge to add hundreds of primitives. A well-structured 60–80 primitive palette (six to eight hues, eight to ten shades each, plus neutrals and a few accents) covers virtually all design system needs. Use ColorFYI's Palette Generator to generate harmonically related hues before committing to your primitive palette.

Use styles for gradients alongside variables for solids

The hybrid approach works well: maintain a "Gradients" style group alongside your variable system. Document explicitly that solids use variables and gradients use styles. This clarity prevents confusion when new designers join the project.

Validate contrast as tokens are defined

Define semantic background/foreground token pairs together and immediately verify their contrast ratio. A token pair like background/primary and text/primary should meet WCAG AA (4.5:1 for text) at the token definition stage. Use ColorFYI's Contrast Checker — enter the Light mode value of background/primary as the background and the Light mode value of text/primary as the foreground.

If the pair fails, fix the primitive values before building any components that depend on them. Contrast problems discovered at the component level are much more expensive to fix than problems discovered at the token definition stage.

Version your token collection

When you make breaking changes to semantic variable names (renaming, restructuring), publish a new library version with a clear deprecation period. If your team uses Tokens Studio or another token sync plugin, maintain a CHANGELOG that maps old token names to new ones.

Key Takeaways

• Color styles store named color presets (and gradients) at the library level — they are simple, universal, and ideal for projects without theming requirements.
• Color variables implement a token architecture with modes (themes), aliasing, scoping, and code export — they are the right foundation for design systems with dark mode, multi-brand, or code-sync requirements.
• Gradients must remain as styles — variables cannot store gradient definitions.
• Aliasing is the defining capability of variables: semantic tokens alias primitives, so updating a primitive propagates to all semantic tokens automatically.
• Migrate in phases: build the primitive collection first, then the semantic collection, then update components progressively — both systems coexist safely during transition.
• Name semantic tokens by role, not visual appearance: text/interactive ages better than text/blue.
• Validate contrast ratios at the token definition stage using the primitive values — fixing problems before components are built costs far less time than fixing them after.