Figma
Design Systems
How to create components with conditional property logic
Jan 25, 2026
The problem: Flat properties don't scale
As design systems grow, component properties accumulate. Properties get added to support edge cases, variations, and reuse. Over time, components expose more properties than are ever meant to be used together.
The result is a flat configuration model. Every property is available all the time, even when it doesn’t apply. Designers are expected to know which combinations are valid and which are not.
This works at small scale. It breaks down quickly in larger systems.
What is conditional property logic?
Conditional property logic means certain properties only exist when specific conditions are met.
In simple terms: if X is true, then Y becomes available.
Rather than treating components as a collection of independent toggles, this approach embeds logic directly into the component. Properties have dependencies. Behavior and styling change based on prior configuration, not just values.
This reflects how real components work. Not everything is possible at once.
Why it matters in design systems
Conditional property logic produces components that are easier to understand and harder to misuse.
It reduces redundant properties and prevents invalid combinations. Instead of creating multiple near-identical components, a single component can adapt based on intent. A slider does not need separate “single” and “range” components if that distinction is structural.
This also helps keep variant count under control, improves maintainability, and aligns more closely with how components are built in code. Most importantly, it provides conceptual clarity. The component communicates how it is meant to work.
The constraints: Figma's property model
Figma does not support conditionally exposing nested properties.
When properties from a subcomponent are exposed, all of them are exposed. There is no way to show or hide properties based on configuration. This makes true conditional logic impossible to express directly at the property level.
Because of this, property logic has to live somewhere else.
The approach: Embodying logic in variants
In practice, conditional property logic is best expressed through variants.
Variants define structural differences rather than cosmetic ones. They represent decisions that meaningfully change how a component behaves. By encoding logic into variants, you control which layers, subcomponents, and properties exist at any given time.
This often involves decoupling components into base or atomic layers and nesting them intentionally in higher-level components. Rather than exposing every nested property, only the relevant ones are mirrored or surfaced.
The result is not fewer options, but more intentional ones.
Putting it into practice
First, define the shared atoms. In the case of a slider, this includes elements like the track, handle, midpoint, and input. These atoms are reused across all configurations and remain logic-free.
Next, decouple the component into separate bases. This will depend on your component and its conditional properties. With slider, single and range have unique and exclusive properties. So instead of a single base where "type = single or range", there are two bases, single and range, each with their respective properties.
Finally, nest those bases into the main component and expose the properties of each base. Map these to their corresponding variant in the main component properties. For slider, when "type = range" range-specific properties become available. When type = single, they do not.
What this enables
Components built this way guide correct usage by default.
They prevent invalid configurations, reduce cognitive load, and make systems easier to scale. Designers spend less time managing complexity and more time making decisions that matter.
Components stop behaving like collections of options and start behaving like systems with rules.
TL; DR
Conditional property logic means properties only exist when conditions are met
Not all component options should be available at the same time
This reduces redundancy and prevents invalid configurations
Components become more resilient and easier to maintain
Variant count stays manageable without duplicating components
Design systems align more closely with development and real component behavior