Variant properties (boolean, enum) in Figma - Deep Dive

Overview - Variant properties (boolean, enum)

What is it?

Variant properties in Figma are special settings that let you create different versions of a design component. These properties can be boolean, meaning they have two states like true or false, or enum, which means they can have multiple named options. They help organize and switch between variations easily without making separate components. This makes designing faster and more consistent.

Why it matters

Without variant properties, designers would need to create many separate components for each style or state, making it hard to manage and update designs. Variant properties solve this by grouping related versions together, saving time and reducing mistakes. This improves teamwork and speeds up building user interfaces, which is crucial for business success.

Where it fits

Learners should first understand basic Figma components and how to create simple variants. After mastering variant properties, they can explore advanced component interactions and design systems for scalable projects.

Mental Model

Core Idea

Variant properties let you control different versions of a design component by toggling simple settings like on/off or choosing from named options.

Think of it like...

It's like a light switch (boolean) or a TV remote with buttons for different channels (enum) that change what you see without replacing the whole TV.

┌───────────────────────────────┐
│        Component Variant       │
├─────────────┬───────────────┤
│ Boolean     │ Enum          │
│ (On/Off)    │ (Multiple     │
│             │ Options)      │
├─────────────┼───────────────┤
│ Enabled     │ Size: Small   │
│ Disabled    │ Size: Medium  │
│             │ Size: Large   │
└─────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Basic Components

Concept: Learn what a component is in Figma and why it is useful.

A component is a reusable design element like a button or icon. Instead of copying and pasting, you create one component and use it many times. When you change the main component, all copies update automatically.

Result

You can create consistent designs faster and avoid mistakes from manual updates.

Knowing components is essential because variant properties build on this idea to manage multiple versions within one component.

2

Foundation

Creating Simple Variants

Concept: Introduce the idea of variants as different states or styles of a component.

Variants let you group similar components with small differences, like a button in normal and hover states. You create variants inside one component set to switch between these states easily.

Result

You get a cleaner design file with fewer components and easier switching between styles.

Understanding variants prepares you to use variant properties that control these differences systematically.

3

Intermediate

Boolean Variant Properties Explained

🤔Before reading on: do you think a boolean property can have more than two states? Commit to your answer.

Concept: Boolean properties have only two states, like true/false or on/off, to toggle features in a variant.

For example, a button can have a boolean property called 'Disabled' with values true or false. This controls whether the button looks clickable or greyed out. You set this property when creating variants and use it to switch states.

Result

You can quickly toggle simple on/off styles without creating separate components.

Knowing boolean properties helps you manage binary design choices cleanly and reduces clutter.

4

Intermediate

Enum Variant Properties Explained

🤔Before reading on: do you think enum properties can only have numeric values? Commit to your answer.

Concept: Enum properties let you choose from multiple named options, not just two states.

For example, a button might have an enum property called 'Size' with options Small, Medium, and Large. Each variant uses one size option. This lets you switch sizes easily without separate components.

Result

You can handle complex variations with many options in one organized component set.

Understanding enums unlocks flexible design control for multiple styles or states.

5

Intermediate

Combining Boolean and Enum Properties

Concept: Learn how to use both boolean and enum properties together in one component set.

You can create a button with a boolean property 'Disabled' and an enum property 'Size'. This means you have variants for enabled/disabled states and small/medium/large sizes all in one place. You switch properties to get the exact variant you want.

Result

Your design system becomes more powerful and easier to maintain with fewer components.

Combining properties lets you build scalable, flexible components that cover many use cases.

6

Advanced

Best Practices for Naming Properties

🤔Before reading on: do you think property names can be anything, even confusing ones? Commit to your answer.

Concept: Clear, consistent naming of variant properties and their values is key for teamwork and usability.

Use simple, descriptive names like 'Disabled' for boolean and 'Size' for enum. Avoid vague names like 'Option1'. This helps everyone understand and use variants correctly, especially in large teams.

Result

Designers and developers can quickly find and apply the right variants without confusion.

Good naming prevents errors and speeds up collaboration in real projects.

7

Expert

Handling Complex Variant Combinations

🤔Before reading on: do you think having many variant properties always improves design clarity? Commit to your answer.

Concept: Too many variant properties or options can make components hard to manage and slow to use.

Experts balance the number of properties to keep components flexible but not overwhelming. They may split very complex variants into smaller component sets or use nested components. They also document variant usage clearly.

Result

Design systems stay efficient and easy to update even as projects grow.

Knowing when to simplify or split variants avoids performance issues and user frustration.

Under the Hood

Figma stores variant properties as metadata attached to component sets. Each variant is a unique combination of property values. When you select a variant, Figma shows the matching design instance. This system lets Figma quickly switch visuals without duplicating components or files.

Why designed this way?

Figma created variant properties to solve the problem of managing many similar components separately. Grouping variants under properties reduces file clutter and improves performance. The boolean and enum types cover most design needs simply and intuitively.

┌───────────────┐
│ Component Set │
├───────────────┤
│ Variant 1     │
│ Disabled: No  │
│ Size: Small   │
├───────────────┤
│ Variant 2     │
│ Disabled: Yes │
│ Size: Small   │
├───────────────┤
│ Variant 3     │
│ Disabled: No  │
│ Size: Medium  │
└───────────────┘
       │
       ▼
┌─────────────────────┐
│ User selects Disabled│
│ = Yes, Size = Small │
│ Figma shows Variant 2│
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think boolean properties can have more than two states? Commit to yes or no.

Common Belief: Boolean properties can have multiple states beyond true and false.

Reality: Boolean properties strictly have only two states: true or false (on or off).

Why it matters: Misusing boolean properties for multiple states causes confusion and breaks variant logic, making designs inconsistent.

Quick: Do you think enum properties must use numbers as options? Commit to yes or no.

Common Belief: Enum properties only accept numeric values as options.

Reality: Enum properties use named text options, like 'Small', 'Medium', 'Large', not numbers.

Why it matters: Using numbers instead of descriptive names makes variants hard to understand and maintain.

Quick: Do you think adding many variant properties always makes components better? Commit to yes or no.

Common Belief: More variant properties always improve component flexibility and design clarity.

Reality: Too many variant properties can overwhelm users and slow down design tools, reducing clarity.

Why it matters: Ignoring this leads to complex, hard-to-use components that hurt productivity.

Quick: Do you think variant properties replace the need for separate components entirely? Commit to yes or no.

Common Belief: Variant properties can handle all design variations, so separate components are unnecessary.

Reality: Some complex or unrelated variations still require separate components or nested components.

Why it matters: Relying only on variant properties can cause messy designs and maintenance headaches.

Expert Zone

1

Variant properties can be combined with interactive components to create dynamic prototypes that respond to user actions.

2

Boolean properties are often used for states like 'Disabled' or 'Active', but naming consistency across a design system is critical to avoid confusion.

3

Enum properties can be nested logically by splitting complex variants into smaller component sets, improving performance and clarity.

When NOT to use

Avoid using variant properties when variations are too complex or unrelated; instead, use separate components or nested components. For highly interactive or animated states, consider using interactive components or prototyping tools.

Production Patterns

In real projects, teams create design systems with variant properties to manage buttons, inputs, and icons efficiently. They use boolean properties for simple toggles like 'Disabled' and enum properties for options like 'Size' or 'Color'. Naming conventions and documentation ensure smooth collaboration.

Connections

Feature Flags in Software Development

Both use boolean and enum-like toggles to control different versions or states of a feature or component.

Understanding variant properties helps grasp how software teams manage feature rollout and testing with flags.

Product Configuration in Manufacturing

Variant properties are like product options (color, size) that customers select to customize a product before purchase.

Knowing this connection shows how design variants mirror real-world product customization.

State Machines in Computer Science

Variant properties represent discrete states and transitions similar to state machines controlling system behavior.

Recognizing this link helps understand how UI states are managed systematically.

Common Pitfalls

#1 Using unclear or inconsistent property names.

Wrong approach:

Boolean property named 'X' with values 'Yes' and 'No' mixed with enum property named 'Size' with options 'S', 'M', 'L'.

Correct approach:

Boolean property named 'Disabled' with values 'True' and 'False'; enum property named 'Size' with options 'Small', 'Medium', 'Large'.

Root cause:

Lack of naming standards causes confusion and misuse of variant properties.

#2 Creating too many variant properties in one component.

Wrong approach:

A button component with 10 variant properties each having multiple options.

Correct approach:

Split complex variants into smaller component sets or nested components with fewer properties each.

Root cause:

Trying to handle all variations in one component leads to complexity and performance issues.

#3 Using boolean properties for multi-option states.

Wrong approach:

Boolean property 'Color' with values 'Red', 'Green', 'Blue'.

Correct approach:

Enum property 'Color' with options 'Red', 'Green', 'Blue'.

Root cause:

Misunderstanding the difference between boolean and enum properties.

Key Takeaways

Variant properties in Figma let you manage multiple versions of a component efficiently using simple toggles.

Boolean properties have only two states, perfect for on/off or true/false design choices.

Enum properties allow multiple named options, ideal for sizes, colors, or styles.

Clear naming and balanced use of variant properties keep design systems easy to use and maintain.

Too many variant properties or misuse can cause confusion and slow down design workflows.