Component Design for JavaScript Frameworks

Unnamed and named frame structure

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 unnamed frames (left) versus thoughtfully named frames (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.

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 your development team up for success. This will enable them to implement components quickly and accurately. Modern design systems like Material Design (Google), Carbon (IBM), and Atlassian Design System use consistent frame naming to create clarity across hundreds of components.

Front-end development has been around for a long time. 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 with using question mark ? (startIcon is must but startIcon? is optional)
• Use consistent naming patterns across all components

Property naming conventions

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. As an example, 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

Figma component properties translate naturally across frameworks. Here's how a button component with well-named props looks in React (TypeScript):

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. Let's take a look at how the same properties look in different frameworks:

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.

A token, as used in web development and design, is typically a standardized value that denotes a particular configuration or design element. Tokens are frequently used to enhance scalability, preserve consistency, and promote cooperation across various libraries and frameworks.

Modern digital products require theme support (light mode, dark mode, high contrast). This necessitates tokens, or customization features 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 touching every component.

From Hard-Coded Values to Design Tokens

If you are using CSS, SASS, 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 library like TailwindCSS. It 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 Tokens

• 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

Examples for basic design tokens for a button component

A design token is a standardized, reusable variable that stores design values like colors, spacing, or typography so they can be easily accessed across different platforms and technologies. Design tokens maintain consistency and help designers and developers collaborate more effectively. We can define various types of tokens for different purposes. For example, we can define color tokens for different purposes like primary, secondary, success, error, etc.

Tokens have various layers of abstraction, from primitive tokens to component tokens to application tokens.

• Primitive tokens: These are the most basic tokens, like colors, spacing, and typography.
• Component tokens: These are tokens that are specific to a component, like the button component illustrated above.
• Application tokens: These are tokens that are specific to the application, like the theme tokens.

Design tokens are simple to incorporate into component libraries, style guides, and design systems because they are usually stored in a format like JSON, YAML, or XML. They can be employed in a variety of frameworks and tools, frequently with the aid of design token management tools or preprocessors like Sass.

Managing design tokens is a crucial part of components and design systems maintenance. You can use various tools to manage design tokens like Tokens Studio, Specify, and Supernova.

Primitive level color token examples

Figma allows us to define various tokens through its Variables feature with four different types: Color, Number, String, and Boolean. Using these tokens improves design system maintenance, ensures consistency across the interface, eases style updates, and enables various theme modes such as dark-light mode.

Variable types available in Figma

These different types of tokens can be used in various ways to define style properties while designing components, elements, templates, pages, and more:

• Color: Semantic color tokens (primary, secondary, success, error, etc.)
• Number: Consistent spacing scale for height, gap, padding (4px, 8px, etc.)
• String: Font families, placeholders
• Boolean: Light/Dark mode switch, IF/ELSE conditions

To get started using variables in Figma, open Variables panel via right sidebar and create a "Collection" in the Variables window. Each file has its own variables yet you can publish them via a team library. You can also move tokens between design files by copying and pasting.

Placement of the Variables

Once you have created a collection, you can add variables to it by clicking the "Create Variable" button. You can also add variables to a collection by copying and pasting them from another collection.

Example of variable usage

After defining the variables, you can start to use them in every aspect of your design system. You can use color-body-text-primary to all your body text elements. This will allow you to easily change the color of your body text by changing the value of the related color variable.

Using tokens for width, height, gap, and padding

You can also use tokens for width, height, gap, and padding of your components. This will allow you to easily change the size of your components by changing the value of the related token.

Prototyping is one of the must-haves for delivering a production-ready component. It allows us to mimic real-time behaviors for actionable items. Today most UI elements have interactions. At least, a hover state is applicable for most of them. For instance, a button can redirect users to a different page, display a dialog, or open a drawer on the side. Adding an On Click event into a component in Figma actually helps developers while defining the “onClick” function on the component so they can define proper destination for the component.

Button with hover and onClick actions

Various triggers and actions are available in Figma's prototype capabilities. Page transitions can be defined using triggering overlays, which are primarily utilized for drawers, dialog, and modals, as well as animations and destinations, which aid in defining navigation. We can simulate items that function just like we developed them by using component-level prototyping. When a component has interactions, developers can see those actions via Dev Mode in Figma, VS Code, or Cursor.

Interaction configurations for hover trigger

Additionally, adding component interactions reveals the component's faults during the early stages of design. Configuring user flows is made possible by the usage of interactive components rather than static ones. Additionally, it is necessary for the initial testing of prototypes. If you conduct a usability test, you can use the prototype to test the user flows and interactions. Last but not least of the benefits is having interactive elements enables stakeholders to understand better while you are doing your presentations.

Almost all of the components need to define various states. Every state serves a distinct function in displaying a component's status. While a hover state provides visual input regarding the interactivity, a default state displays the component's initial appearance. The cursor pointer's appearance may indicate that a component is draggable or contains an anchor link that will take us to a different location.

Any interactive component needs to exhibit these fundamental states; Default, Hover, Focus, Active, Disabled, Loading, Error, Success. Let's take a look at each state in detail with using an input component as an example.

Default State

• How the component appears initially
• Resting state with no user interaction

Hover State

• Visual feedback when pointer hovers over the element
• Cursor changes to indicate interactivity
• Subtle color shifts, elevations, or underlines

Focus State

• Keyboard navigation indicator
• Critical for accessibility (WCAG compliance)
• Often a visible outline or highlight

Active/Pressed State

• Visual feedback during click/tap
• Brief state showing the component is being activated
• Often a slight scale reduction or color darkening

Disabled State

• Non-interactive appearance
• Reduced opacity or grayed-out styling
• Cursor changes to "not-allowed"

Loading State

• Indicates asynchronous operations
• Often shows spinner or skeleton loader
• May disable interaction during loading

Error State

• Displays validation errors or failures
• Red/warning colors, error icons, helper text
• Critical for form components

Success State

• Confirms successful operations
• Green/success colors, checkmarks, confirmation messages

Changing states of a component or assigning an onclick function requires defining triggers and actions. Figma offers various triggers and actions for both web and mobile experiences. To create an interactive component and functional interface in the design phase, you need to use triggers and actions functionality.

Interaction flow for a component

Triggers

You can designate ten distinct triggers for your components in Figma. These triggers can be used to assign keyboard keys, click and drag, move the mouse pointer over an element, or delay a transition. The two triggers that designers use the most while designing are On Click and While Hovering. On Tap and On Drag might be your top picks if you're designing for mobile.

Trigger types available in Figma

Actions

Actions are the functions that are executed when a trigger is activated. You can designate eleven distinct actions for your components in Figma. These actions define the behavior of the component when a trigger is activated.

Action types available in Figma

Most common actions when designing components and pages are Navigate, Scrool, Open, and Open Overlay. If you need to define complex behavior, you can use the Conditional, Set Variable, and Set Variable Mode. Conditional action type allows you to define IF/ELSE logic. Set Variable action type allows you to set a variable value. Set Variable Mode action type allows you to switch between different modes of a variable such as light mode, dark mode, and high contrast mode.

Defining an On Click action on a button component to navigate user to pricing page

The principles outlined in this article, Structure, Properties, Tokens, andInteractions, are essential for creating components that are easy to implement in code. When you structure frames with HTML in mind, name properties using proper conventions, implement design tokens for scalability, and prototype complete interaction states, you're not just creating better Figma files. You're building bridges between disciplines.

If you start to implement these principles, you will see the benefits like:

• Fewer clarification questions from developers
• Increased development velocity
• Better code quality with clear component architecture
• Easier iteration and maintenance
• Scalable design systems across multiple products

Bridge between design and development

Beyond Individual Components

While this article focused on component design, these principles extend far beyond single UI elements:

• Design systems become more maintainable when built on these foundations
• Cross-functional teams collaborate more smoothly with shared terminology
• Product velocity increases when handoffs are friction-free
• Technical debt decreases when designs are implementable from the start
• Career opportunities expand as you develop design engineering skills

The job market data shows this clearly: 20% of product designer positions now requires front-end development knowledge. This isn't a passing trend. It's the evolution of our discipline. Designers who understand code structure, component architecture, and developer workflows are becoming increasingly valuable.

Starting Tomorrow

You don't need to master everything at once. Start small:

This week:

• Review one existing component in your design files
• Rename frames using semantic, meaningful names
• Check if your Auto-Layout structure makes sense for HTML

This month:

• Create or refine properties for your core components
• Establish a naming convention document with your team
• Prototype interaction states for your most-used components

This quarter:

• Implement a design token system using Figma Variables
• Document your component standards
• Conduct a handoff retrospective with your development team

Your learning journey

Small, consistent improvements compound into expertise. Each component you refine teaches you more about the design-development relationship. Do not forget: The best components aren't just beautiful. They are thoughtfully structured, clearly documented, and ready to become excellent in development.

A Final Thought

The best designs aren't the ones that look most impressive in Figma presentations. They're the ones that successfully navigate the journey from concept to production, maintaining their integrity, meeting user needs, and respecting technical constraints along the way.

By mastering component design for JavaScript frameworks, you're not just becoming a better designer. You're becoming a more effective collaborator, a more valuable team member, and a more complete product professional. You're learning to speak multiple languages fluently. The visual language of design and the logical language of code. Use both to create experiences that truly work.