The Shared Language of Props | Figma | Figma Blog (opens in new tab)

Design and engineering use the same component vocabulary, but often attach different meanings to terms such as “property,” “variant,” and “button.” Figma properties primarily describe visual variations, while code props may also control behavior, events, data, and rendering. Effective collaboration therefore requires translating concepts across environments rather than assuming identical names imply identical implementations.

Components and Properties as Shared Concepts

• Components are reusable elements governed by rules describing how they can look and behave.
• Properties, or “props,” define the possible expressions of a component, including:
  • Variants
  • Boolean values
  • Instance swaps
  • Text values
• In Figma, properties are used mainly to represent visual differences.
• In code, props can also represent non-visual concerns such as event handlers and data.
• A shared term can conceal different assumptions when designers and developers work in different tools and contexts.

A Button Is Not the Same Everywhere

• Designers and developers both work with buttons, but prioritize different concerns:
  • Designers focus on visual consistency and maintainability across design files.
  • Developers focus on interactivity, rendering, accessibility, and implementation.
• A Figma button and a code-based button may share a name without sharing the same API or purpose.
• Migrating a React and TypeScript application to a design-system-based frontend exposed conflicts between Material UI conventions and the organization’s custom design system.
• The component library aimed to be intuitive and lightweight for full-stack engineers who primarily connected frontend and backend systems.

Divergent Component Models

• The design system contained two Figma components:
  • Button
  • IconButton
• The codebase contained five button components.
• Figma’s Button and IconButton did not use the same inheritance or primitive-component structure as the codebase.
• Some properties, such as size and color variants, were duplicated in Figma because that structure better represented the design model.
• Although the components shared names and broad concepts, they did not share the same purpose or complete set of properties.

Teams should treat design and code components as related models rather than identical ones. Clear translation of property names, meanings, and responsibilities can preserve each environment’s strengths while reducing misunderstandings during implementation.