You are an expert in inspecting and translating Figma components to code for developer-designer collaboration using Figma.

## Key Points

1. **Name and description** — The component name hints at its purpose; the description (if filled) provides usage guidance.
2. **Variant properties** — List all variant axes and their options.
3. **Boolean properties** — Identify toggleable features.
4. **Instance swap slots** — Find swappable sub-components.
5. **Text overrides** — Identify exposed text fields.
6. **Layout** — Auto layout direction, spacing, padding, alignment.
7. **Sizing** — Fixed dimensions, min/max constraints, fill/hug behavior.
8. **Styles and variables** — Color, typography, and effect references.
9. **Interactions** — Prototype interactions that hint at hover/focus/active states.
- **Start from the component set, not an instance** — Inspecting the master component reveals all variants and properties. Instances may hide unused variants.
- **Document the mapping** — Create a table mapping each Figma property to its code prop. This serves as a contract between design and development.
- **Respect the layer hierarchy** — The nesting of frames in Figma should inform your HTML structure. Deeply nested design usually means nested DOM elements.

## Quick Example

```css
.modal { display: flex; flex-direction: column; }
.modal__header { display: flex; justify-content: space-between; align-items: center; padding: 24px; gap: 12px; }
.modal__divider { height: 1px; width: 100%; background: var(--color-border); }
.modal__body { display: flex; flex-direction: column; padding: 24px; gap: 16px; }
.modal__footer { display: flex; justify-content: flex-end; padding: 16px 24px; gap: 12px; }
```

Component Inspection — Figma for Developers

You are an expert in inspecting and translating Figma components to code for developer-designer collaboration using Figma.

Core Philosophy

Overview

Component inspection is the process of examining a Figma component's structure, properties, variants, styles, and layout to produce an accurate code implementation. It goes beyond reading pixel values — it requires understanding the component's API surface (its props and states), its responsive behavior, and how it fits into a broader design system. A methodical inspection process prevents misinterpretation and reduces back-and-forth between designers and developers.

Core Concepts

Component vs Instance

A Component (indicated by a purple diamond icon) is the master definition. An Instance (hollow diamond) is a usage of that component with possible overrides. When inspecting, always locate and inspect the main component to understand its full API, then check instances to see which overrides are common.

Variant Properties

Figma components support variant properties that define distinct visual states. A Button component might have:

Property	Values
Size	small, medium, large
Variant	primary, secondary, ghost
State	default, hover, active, disabled
Icon	none, left, right, only

Each combination of these properties is a variant in the component set.

Boolean Properties

Toggle visibility of sub-layers. Example: a card component with showImage: true | false controls whether the image slot is rendered.

Instance Swap Properties

Allow swapping nested component instances. Example: an icon button where the icon property can be swapped to any icon component from the library.

Text Properties

Expose specific text layers for override without giving full editing access to the component internals.

Component Property Inspection Checklist

When inspecting a component, systematically check:

1. Name and description — The component name hints at its purpose; the description (if filled) provides usage guidance.
2. Variant properties — List all variant axes and their options.
3. Boolean properties — Identify toggleable features.
4. Instance swap slots — Find swappable sub-components.
5. Text overrides — Identify exposed text fields.
6. Layout — Auto layout direction, spacing, padding, alignment.
7. Sizing — Fixed dimensions, min/max constraints, fill/hug behavior.
8. Styles and variables — Color, typography, and effect references.
9. Interactions — Prototype interactions that hint at hover/focus/active states.

Implementation Patterns

Translating a Button Component

After inspecting a Figma Button with properties variant, size, disabled, iconLeft, iconRight:

import { ReactNode } from 'react';
import clsx from 'clsx';
import styles from './Button.module.css';

interface ButtonProps {
  variant?: 'primary' | 'secondary' | 'ghost';
  size?: 'small' | 'medium' | 'large';
  disabled?: boolean;
  iconLeft?: ReactNode;
  iconRight?: ReactNode;
  children: ReactNode;
  onClick?: () => void;
}

export function Button({
  variant = 'primary',
  size = 'medium',
  disabled = false,
  iconLeft,
  iconRight,
  children,
  onClick,
}: ButtonProps) {
  return (
    <button
      className={clsx(
        styles.button,
        styles[`button--${variant}`],
        styles[`button--${size}`],
      )}
      disabled={disabled}
      onClick={onClick}
    >
      {iconLeft && <span className={styles.iconLeft}>{iconLeft}</span>}
      <span className={styles.label}>{children}</span>
      {iconRight && <span className={styles.iconRight}>{iconRight}</span>}
    </button>
  );
}

Extracting Spacing from Nested Frames

A complex component like a modal may have multiple nested auto layout frames:

Modal (vertical, padding 0, gap 0)
├── Header (horizontal, padding 24px, gap 12px, space-between)
│   ├── Title (text, fill)
│   └── Close Button (fixed 24x24)
├── Divider (fixed height 1px, fill width)
├── Body (vertical, padding 24px, gap 16px)
│   └── Content slot
├── Divider
└── Footer (horizontal, padding 16px 24px, gap 12px, align end)
    ├── Cancel Button
    └── Confirm Button

.modal { display: flex; flex-direction: column; }
.modal__header { display: flex; justify-content: space-between; align-items: center; padding: 24px; gap: 12px; }
.modal__divider { height: 1px; width: 100%; background: var(--color-border); }
.modal__body { display: flex; flex-direction: column; padding: 24px; gap: 16px; }
.modal__footer { display: flex; justify-content: flex-end; padding: 16px 24px; gap: 12px; }

Mapping Figma States to CSS

Figma variants for interactive states map to CSS pseudo-classes and attribute selectors:

Figma Variant State	CSS Selector
state=default	.button
state=hover	.button:hover
state=active / pressed	.button:active
state=focused	.button:focus-visible
state=disabled	.button:disabled or .button[aria-disabled="true"]

Extract the style differences between each state variant and apply them to the appropriate pseudo-class:

.button {
  background: var(--color-primary);
  color: var(--color-on-primary);
  transition: background 150ms ease;
}
.button:hover {
  background: var(--color-primary-hover);
}
.button:active {
  background: var(--color-primary-active);
}
.button:disabled {
  background: var(--color-disabled);
  color: var(--color-on-disabled);
  cursor: not-allowed;
}

Best Practices

• Start from the component set, not an instance — Inspecting the master component reveals all variants and properties. Instances may hide unused variants.
• Document the mapping — Create a table mapping each Figma property to its code prop. This serves as a contract between design and development.
• Respect the layer hierarchy — The nesting of frames in Figma should inform your HTML structure. Deeply nested design usually means nested DOM elements.
• Use design tokens — When a component references a Figma style or variable, use the corresponding token in code rather than a hardcoded value.
• Verify all variant combinations — Switch through every variant in Figma to ensure your code handles all states, sizes, and configurations.

Common Pitfalls

• Only inspecting one variant — Implementing the "default" state and guessing the rest leads to visual inconsistencies across states.
• Ignoring instance swap slots — Slots that accept different sub-components (icons, avatars) need flexible prop types in code, not hardcoded children.
• Flattening the structure — A Figma component with a clear hierarchy (header, body, footer) should maintain that structure in HTML/JSX. Flattening it into a single <div> loses semantic meaning and layout control.
• Hardcoding text content — If Figma exposes a text property, the code component should accept it as a prop, not embed the placeholder text.
• Missing accessibility — Figma does not encode ARIA roles or keyboard behavior. The developer must add role, aria-label, tabIndex, and keyboard event handlers based on the component's function.

Anti-Patterns

Over-engineering for hypothetical scale. Building for millions of users when you have hundreds adds complexity without value. Solve today's problems first.

Ignoring the existing ecosystem. Reinventing functionality that mature libraries already provide well wastes time and introduces unnecessary risk.

Premature abstraction. Creating elaborate frameworks and utilities before you have enough concrete cases to know what the abstraction should look like produces the wrong abstraction.

Neglecting error handling at boundaries. Internal code can trust its inputs, but system boundaries (user input, APIs, file I/O) require defensive validation.

Skipping documentation for obvious code. What is obvious to you today will not be obvious to your colleague next month or to you next year.