Component Design for JavaScript Frameworks

Proper layer naming is essential for clear communication between designers and developers. Meaningful names help developers understand the purpose of each frame and how it maps to code. If you wouldn't name a CSS class "Frame 1" or "Group 2", don't use those names in your layers. Instead, use descriptive names that reflect the element's role.

Unnamed vs Meaningful Layer Names for a Card Component

Above example shows a card component with poorly named layers (left) versus thoughtfully named layers (right). The meaningful names clarify the structure and purpose of each element, making it easier for developers to implement the design accurately. Even the Figma icons tells the layout direction (horizontal vs vertical) at a glance.

Benefits of Thoughtful Layer Naming

• Clarifies HTML structure:Layer names can inform semantic HTML elements and CSS class names.
• Improves maintainability: Easier to understand and modify components later.
• Aligns with development patterns: Developers can quickly map design to code.
• Enhances team communication: Shared vocabulary between design and development.
• Enables better search: Find components quickly in large Figma files.

Naming Conventions

Follow these guidelines when naming layers:

/// Use clear, descriptive names

🟩 CardImage (not Image1)
🟩 CardTitle (not Text_Layer_2)
🟩 ActionButton (not Button)
🟩 IconWrapper (not Group_23)
🟩 PriceLabel (not Text)

/// Do not use vague, generic names

🟥 Container
🟥 Wrapper
🟥 Group
🟥 Frame #123456
🟥 Text

By combining proper Auto-Layout structure with meaningful layer names, you set developers up for success—enabling them to implement components quickly and accurately. Modern design systems like Material Design (Google), Carbon (IBM), and Atlassian Design System use consistent layer naming to create clarity across hundreds of components.

Properties of the button component in Figma UI

Component properties (props) are arguably Figma's most powerful feature for creating flexible, functional components that mirror real component behavior. As a designer, If I am going to use an UI element more than once, I always create a component with well-defined properties. This approach not only streamlines my design process but also significantly reduces the development effort required to implement the component. Defining properties is a time investment that pays off in spades.

Figma supports several property types that map directly to JavaScript/TypeScript:

Property types available in Figma

Property Naming Best Practices

While naming properties, consider giving meaningful names that convey the purpose of the property. Following front-end conventions can help maintain consistency and clarity and it also reduce the development time. Adding a ? at the end of boolean properties indicates that the property is optional which is a valuable info for the development team.

/// Use descriptive, purposeful names

🟩 cardTitle
🟩 isDisabled
🟩 buttonLabel
🟩 iconStart
🟩 hasEndIcon
🟩 showKebabMenu

/// Do not use vague, generic names

🟥 text1
🟥 disabled
🟥 label
🟥 icon
🟥 end
🟥 menu

Follow frontend conventions

Front-end development is in progress since the early 2000s. Over the years, certain conventions have emerged that enhance code readability and maintainability. Adopting these conventions in your property naming can significantly improve collaboration with developers. As designers, we should strive to speak the same language as our developer counterparts. Here are some key conventions to consider:

• Use camelCase (e.g., buttonLabel, isDisabled) for property names to align with JavaScript conventions.
• Prefix boolean properties with is, has, show, or can to indicate their true/false nature.
• Use specific, clear names (`primaryColor` not `color1`)
• Indicate optional behavior clearly (`startIcon?` or `iconStart?`)
• Use consistent naming patterns across all components

Framework-Specific Implementation

The same Figma component properties translate naturally across frameworks. Here's how a button component with well-named props looks in different ecosystems:

Component property mapping between Figma and code

Above Figma button component properties map directly to props in React, Vue, Angular, and Svelte with minimal adjustments for framework syntax. This consistency reduces cognitive load for developers and help them implement components faster and with fewer errors.

 /// React (TypeScript)

interface ButtonProps {
  label: string;
  size?: 'small' | 'medium' | 'large';
  type?: 'primary' | 'secondary' | 'tertiary';
  isLoading?: boolean;
  isDisabled?: boolean;
  endIcon?: React.ReactNode;
  startIcon?: React.ReactNode;
  onClick?: () => void;
}


// Usage

<Button 
  label="Click me" 
  type="primary" 
  size="medium"
  isDisabled={false}
  startIcon={<WestRoundedIcon />}
  onClick={() => { /* handle click */ }}
/>
                  

 /// Vue 3 (TypeScript)

interface ButtonProps {
  label: string;
  type?: 'primary' | 'secondary' | 'tertiary';
  size?: 'small' | 'medium' | 'large';
  isDisabled?: boolean;
  isLoading?: boolean;
  startIcon?: Component;
  endIcon?: Component;
}


// Usage

<Button 
  label="Click me" 
  type="primary" 
  size="medium"
  :is-disabled="false"
  :start-icon="ArrowLeft"
  @click="handleClick"
/>
                  

 /// Angular (TypeScript)

@Component({
  selector: 'app-button',
  template: ''
})
export class ButtonComponent {
  @Input() label!: string;
  @Input() type?: 'primary' | 'secondary' | 'tertiary' = 'primary';
  @Input() size?: 'small' | 'medium' | 'large' = 'medium';
  @Input() isDisabled?: boolean = false;
  @Input() isLoading?: boolean = false;
  @Input() startIcon?: TemplateRef<any>;
  @Input() endIcon?: TemplateRef<any>;
  @Output() onClick = new EventEmitter<void>();
}


// Usage

<app-button 
  label="Click me" 
  type="primary" 
  size="medium"
  [isDisabled]="false"
  [startIcon]="arrowLeftTemplate"
  (onClick)="handleClick()"
/>
                  

 /// Svelte (TypeScript)

<script lang="ts">
  export let label: string;
  export let type: 'primary' | 'secondary' | 'tertiary' = 'primary';
  export let size: 'small' | 'medium' | 'large' = 'medium';
  export let isDisabled: boolean = false;
  export let isLoading: boolean = false;
  export let startIcon: Component | undefined = undefined;
  export let endIcon: Component | undefined = undefined;
</script>


// Usage

<Button 
  label="Click me" 
  type="primary" 
  size="medium"
  isDisabled={false}
  startIcon={ArrowLeft}
  on:click={handleClick}
/>
                  

As we can see, the same well-defined properties in Figma translate cleanly to props in React, Vue, Angular, and Svelte. This consistency not only speeds up development but also reduces the likelihood of miscommunication or errors during implementation. By investing time in defining clear, js-friendly component properties in Figma, we set the stage for a smoother handoff to developers and a more efficient development process overall.

Modern digital products require theme support (light mode, dark mode, high contrast). This necessitates tokenization, using variables instead of hard-coded values. Besides that, using tokens instead of fixed values also enables scalability and consistency across the design system. For example, if your brand color changes, updating a single token updates it everywhere. As designers, we often hear new iteration ideas from stakeholders. Using tokens allows us to implement changes quickly without redesigning every component.

From Hard-Coded Values to Design Tokens

If you are using CSS or CSS-in-JS, design tokens are typically implemented as CSS variables (custom properties). You need to create your own primitive and component tokens. If you want to skip the creating primitive tokens, it's best to use an existing open-source token library like TailwindCSS. Tailwind provides a comprehensive set of design tokens that cover colors, spacing, typography, and more. You can then create component-specific tokens that reference these primitives. For example, a button's primary background color token might reference Tailwind's `--tw-color-blue-600`. Here is an example of how to transition from old way to modern way:

/// Old approach (hard-coded values)

🟥 Color: "#0D99FF" (specific hex value)
🟥 Spacing: "16px" (specific pixel value)
🟥 Font: "Inter" (specific typeface)
🟥 Border radius: "8px" (specific value)

/// Modern approach (design tokens)

🟩 Color: "--color-primary-600" → resolves to "#0D99FF" in light mode, "#3B82F6" in dark mode
🟩 Spacing: "--spacing-4" → resolves to "16px" (or "1rem" in fluid systems)
🟩 Font: "--font-family-sans" → resolves to "Inter, system-ui, sans-serif"
🟩 Border radius: "--radius-md" → resolves to "8px"

Benefits of Tokenization

• Easy theme switching: Change entire color schemes by swapping variable collections
• Consistent design: All components reference the same token system, eliminating one-off values
• Simplified maintenance: Update a token once, change it everywhere
• Developer alignment: Design tokens map directly to CSS custom properties
• Accessibility compliance: Manage contrast ratios systematically
• Brand flexibility: Support white-label products or multi-brand systems

Figma's Local Variables feature enables comprehensive tokenization:

Our goal was to improve account security with an additional layer of authentication—without creating friction or drop-off in user experience. We needed a solution that served both our individual (B2C) users and our enterprise clients with scalable and customizable options.