Figma Component Properties: A Practical Guide
Expose intentional component choices as properties so another designer can configure an instance without hunting through its layers. Choose properties for meaningful variation; do not create a separate variant for every possible combination of labels and icons.
Before you start: Use edit access to the main component and a test instance. Agree which states exist in code so the design controls do not suggest combinations the application cannot support.
Worked example: A notification banner needs message text, an optional leading icon and a severity choice. Model those as distinct decisions rather than duplicating the complete banner for every message.
Step-by-step guide
List supported decisions
Write down what a consumer may change: copy, optional elements, nested components and named states. Separate those decisions from internal layout details that should remain consistent.
Choose property types
Use text for editable copy, visibility controls for optional layers, instance swaps for nested components and variants for named design states. Check current property behavior in Figma’s documentation.
Name controls for consumers
Use names that describe outcomes, such as Show icon or Severity. Avoid internal layer codes that force another designer to understand the component’s construction before using it.
Configure a test instance
Change each exposed property on an instance and inspect the result. Include long copy and missing optional elements so the component remains understandable outside its default example.
Check unsupported combinations
Try the combinations most likely to break layout or imply invalid behavior. Document what is supported and simplify the property model if it allows confusing or contradictory states.
Review with implementation
Compare property names with the code component’s public interface. Keep intentional differences explicit and include a link to the component documentation for future consumers.
Common mistakes
Variants for every text value
Copy changes do not usually need a new named variant. Use a text property when the difference is only the string.
Boolean equals business logic
Visibility controls do not implement product rules. Document when an element should appear separately from the property that draws it.
No instance test
A well-organized main component can still be awkward to consume. Test the controls on a fresh instance before publishing.
Tips
Keep property labels short enough to scan in the sidebar.
Use realistic error copy when testing component resizing.
Document the reason for any deliberate design-to-code naming difference.
Sources and verification
Based on product documentation checked on 2026-10-24. This is a documentation-based guide, not a hands-on benchmark. Features and availability can change.