Variant Explosion Control (Wrangling Systems)

The Problem: The Variant Labyrinth

Before improvements in tools like Figma, creating a simple component (like a button) with 3 sizes, 4 color variants, 2 icon states, and 5 interaction states (default, hover, active, focus, and disabled) required the manual creation of 120 individual variants (3 x 4 x 2 x 5).

This caused serious problems:

• File Performance: Extremely heavy Figma files that were slow to load.
• Ease of Use: An unmanageable selection panel for designers using the system.
• Technical Inconsistencies: Any global change (e.g., the border-radius of all buttons) became a manual update nightmare for the team.

Tools for “Wrangling” (Taming the System)

Fortunately, Figma introduced Component Properties that allow visual variants to be replaced by logical attributes:

1. Boolean Properties (Yes/No)

Instead of creating one variant for “Button with Icon” and another for “Button without Icon,” create a single variant and assign a visibility boolean to the icon layer.

• Result: Immediate 50% reduction of visual variants on your canvas.

2. Instance Swap Properties

Allows a child component (like an icon or an avatar) to be changed for another from the library without needing to create variants for every possible system icon. It relies on swapping instances rather than creating new versions of the parent component.

3. Text Properties

Allows text content to be changed directly from the parent component’s property panel, ensuring the defined style is respected and eliminating the need to manually enter the component’s internal layers.

4. Nested Components (Base Structure)

Create a “Base Layer” (usually a private or hidden component by prefixing a . to the name) that contains all possible logic, structure, and behaviors. Then, create the public component that inherits from that base. If you change a padding or color in the base, it will automatically update in all public variants.

When is a Variant YES Necessary?

Not everything can or should be a property. Cases where it remains legitimate to create separate variants are:

• Dimensional Changes (Sizes): If internal spacing (padding) or typographic hierarchy (font-size) changes considerably.
• Structural Difference (Visual Types): If a primary button is substantially different in structure from a ghost or icon-only button.
• Layout Alterations: If the order of elements or their arrangement changes radically (e.g., a vertical Card in mobile that becomes a horizontal Card on desktop).

Strategic Benefits of Variant Control

• Better Performance: Faster design files to load, navigate, and prototype.
• High Adoptability: Designers like using simple and intuitive components, not indecipherable 200-piece puzzles.
• Technical-Visual Consistency: Much better reflects how components are actually written in code (using if/else logic and states instead of creating 120 individual button files).

Mentor’s Tips

• Don’t obsess over perfection: Sometimes it’s faster for a small team to have 4 clear variants than a single hyper-complex component full of logical properties.
• Do the “Stress Test”: Show your component to a designer outside your team. If they don’t understand how to use it in less than 10 seconds, your property system is too complex.
• Involve Developers: Ask how the components are actually coded. Often, their “props” and “interfaces” logic will give you the key to structuring your components in Figma identically.

Useful Resources and Tools

• Figma Design Blog: Reducing Component Complexity with Properties
• Design Systems Collective: How to wrangler your figma variants
• Brad Frost Book: Atomic Design (Chapters on managing component variations).
• Video Tutorials: Figma YouTube channels or experts like Malcom Kee on “Advanced Figma Components.”

component-api-design component-props-organization