You have seen it before. A Figma file lands in your lap with frames named Group 47, colors hard-coded as #3A2FBC, and zero indication of which states actually exist. You reverse-engineer the design, fill in the gaps, and ship something that mostly resembles what was intended. This is not a workflow problem. It is a communication problem. And it is one designers can fix on their side of the fence.
This article is written for both sides of that handoff. If you are a developer tired of ambiguous specs, here is what well-structured components actually look like. If you are a designer reading this on dev.to because you want to close that gap, welcome. You are already ahead. It covers four fundamentals: Structure, Properties, Tokens, and Interactions.
Let's begin if you're prepared to explore!
1. Structure
Every frame in Figma corresponds to an HTML element. When you nest frames to build a component, you are essentially defining the HTML structure. This is why it matters deeply how you organize and name your layers.
Frames over Groups. Figma offers two grouping methods: Groups and Frames. Use Frames. Only Frames unlock Auto-Layout, which maps directly to CSS Flexbox. When you configure Auto-Layout in Figma, you are defining display: flex, flex-direction, justify-content, align-items, gap, and padding simultaneously.
Name your layers meaningfully. A layer named CardTitle is far more useful to a developer than Text_Layer_2. Descriptive names communicate semantic purpose, inform CSS class naming, and reduce the need for developer clarifications during handoff.
Good layer naming:
CardImage
CardTitle
ActionButton
IconWrapper
PriceLabel
Avoid:
Container
Wrapper
Group
Frame #123456
Key principle: Use the minimum number of frames necessary to achieve the layout. Each frame adds a DOM element. Fewer frames mean cleaner, more maintainable code.
2. Properties
Component properties are arguably Figma's most powerful feature for creating flexible, developer-friendly components. Every reusable element I design gets a set of well-defined properties. It is a time investment that pays off significantly during development.
Figma supports four property types that map directly to JavaScript equivalents:
| Figma Property | Frontend Equivalent | Example |
|---|---|---|
| Text | string |
Button label, card title |
| Boolean | boolean |
isDisabled, isLoading |
| Instance Swap | Component instance | Icon, avatar |
| Variant |
string enum |
type="primary", size="large" |
Naming conventions matter. Adopting front-end conventions in your property naming reduces the cognitive gap between design and development:
- Use
camelCase(e.g.,buttonLabel,isDisabled) - Prefix booleans with
is,has,show, orcan - Use
?to indicate optional properties (e.g.,startIcon?) - Avoid generic names like
text1,icon, orend
When your Figma properties mirror the TypeScript interface a developer will write, handoff becomes nearly frictionless. The same label, size, type, isDisabled, and isLoading properties work identically across React, Vue, Angular, and Svelte with only minor syntax differences.
3. Tokens
Hard-coded values like #0D99FF or 16px create maintenance debt. Design tokens replace those values with named variables, such as --color-primary-600 or --spacing-4, that resolve to specific values depending on context (light mode, dark mode, high contrast).
Tokens operate across three levels of abstraction:
-
Primitive tokens: Base values like
--amber-500 -
Component tokens: Element-specific like
--button-surface-primary -
Application tokens: Theme-level like
--system-theme-primary
In Figma, tokens are managed through the Variables feature using four types: Color, Number, String, and Boolean. Once defined, you can apply them to any fill, stroke, spacing, or dimension property across your entire design system.
The payoff is significant. When a brand color changes, updating one token updates it everywhere. When a stakeholder asks for a dark mode, you have the infrastructure to deliver it without rebuilding components from scratch. Tokens also help manage accessibility compliance by making it easier to track and adjust contrast ratios systematically.
4. Interactions
A static component tells half the story. Prototyping interactions in Figma adds crucial context for developers and stakeholders alike.
Every interactive component should define these core states:
- Default: The resting appearance
- Hover: Visual feedback on pointer over
- Focus: Keyboard navigation indicator (critical for WCAG compliance)
- Active/Pressed: Feedback during click or tap
- Disabled: Non-interactive, reduced opacity
- Loading: Indicates an async operation in progress
- Error: Validation failure feedback
- Success: Confirmation of a completed action
Triggers and Actions in Figma allow you to configure how a component responds to user input. The most common triggers are On Click and While Hovering. For mobile, On Tap and On Drag take priority.
Beyond individual components, interactions map your user flows. Configuring an On Click event on a button in Figma to navigate to a destination is the same decision a developer makes when writing an onClick handler. This shared vocabulary closes the gap between disciplines.
When interactions are defined in Figma, developers can inspect them directly via Dev Mode, VS Code, or Cursor. It also helps catch design faults early and makes usability testing more meaningful.
Bringing It Together
These four fundamentals are not isolated techniques. They work together to create a component that is easy to implement, easy to maintain, and easy to scale.
When you structure frames with HTML in mind, name properties using front-end conventions, implement design tokens for scalable theming, and prototype complete interaction states, you are not just creating better Figma files. You are building bridges between disciplines.
The practical benefits show up quickly:
- Fewer clarification questions from developers
- Faster feature delivery
- Better code quality from the start
- Lower technical debt over time
- More scalable design systems
The best components are not just visually polished. They are thoughtfully structured, clearly documented, and ready to become excellent in production.
Thank you for reading this article. If you are interested in creating components that translates to code, read the full article with interactive examples, code snippets, and diagrams at o10n.design
Top comments (0)