How do you define component structure, variants, and states?
Explain a part's composition, adjustable options, and states so it can be reused reliably.
A component is a reusable interface part. Its definition explains what it contains, what can change, and how it responds when people interact with it.
Keep these basics in mind
- Structure describes a part’s contents, such as button text and an optional icon.
- A property is an adjustable option, such as button text or whether an icon appears.
- A variant is an agreed version of a part, such as a regular or primary button. A state is its default, hover, focus, disabled, or loading condition.
- Explain triggers and whether actions remain available, as well as drawing default appearance. Different parts may need different states.
See Figma’s component-property guide for organising options and variants.
Define a component
Illustrative Save-button states
These are hypothetical rules, not an existing component interface.
| State | When it appears | Available action |
|---|---|---|
| Default | Information can be submitted | Save |
| Focus | Keyboard reaches the button | See position and activate |
| Loading | Submitted, awaiting a result | Understand processing; avoid duplicate submission |
| Disabled | Submission currently unavailable | Understand the reason or availability condition |
Walk through an example
A profile form uses the same Save button throughout. Valid input can be submitted; selecting Save starts loading; failure returns it to an operable state and explains the problem. The team checks keyboard use, long labels, and error paths rather than copying only the default appearance.
Limits and common misunderstandings
Each new text string does not need a new variant. Too many options make a part difficult to use; expose changes that serve real needs. Drawn states do not automatically create browser behaviour. Developers still need to implement triggers and actions.