Figma Dev Mode made components easier to inspect

Dev Mode changed the handoff conversation in a useful way: it made the gap between a component’s appearance and its implementation easier to point at.

That gap is usually quiet. A Figma button has six variants; the production button has nine. The file names one spacing variable; the app uses a different set of values. Nobody has made an obviously bad decision. The system has simply accumulated exceptions.

Inspection turns those exceptions into visible questions.

The component is the contract

A component is not just a reusable visual layer. It describes behavior shared by design, code, and accessibility.

For a button, the contract includes dimensions, label behavior, loading, disabled and focus states, icon placement, density, and long labels. A card has its own contract: hierarchy, truncation, empty media, keyboard behavior, and responsive rules.

The visual happy path is only one slice of that contract. When the Figma component omits loading but the production component supports it, the missing state does not disappear. Engineers invent it during implementation, and the system starts speaking in two dialects.

Names are more useful than snippets

Raw values help during exploration. They are poor documentation for a component library.

#2563eb tells an engineer what a color is. A token tells them why it exists:

button.primary.background = color.action.primary
button.primary.text = color.text.inverse
button.height.md = size.control.md
button.radius = radius.control
button.gap = space.2

When Dev Mode exposes variables alongside code-oriented details, the design artifact can use the same vocabulary as the codebase. That makes inspection useful without turning it into copy-and-paste development.

The ownership record is deliberately boring

Figma cannot be the entire source of truth. The library component, implementation, docs, tests, and examples all describe the same object.

One small record can make the boundary explicit:

component: Alert
design owner: product design systems
code owner: web platform
docs: /docs/components/alert
production package: @site/ui/alert
figma library: Web Components / Alert
last reviewed: 2024-02-07
known gaps: no inline action variant in native app

The record can live somewhere other than Figma. The important part is that the design component points toward it, and that someone owns the gaps.

Inspection does not equal alignment

A perfectly inspectable component can still represent an obsolete pattern. The codebase may have a newer primitive. The frame may describe desktop while the product’s sharp edges are on mobile. A variable may have a clear name and still be the wrong variable.

The handoff needs to account for the behavior that screenshots do not settle:

• keyboard focus
• disabled and loading states
• validation and error copy
• responsive layout
• theme modes
• localization and long labels
• accessibility names and roles
• data-dependent empty states

Figma can document parts of this. The implementation and its tests have to prove the rest.

Drift leaves signals

Design-system drift is hard to notice because each exception looks small. A custom margin, an extra variant, a hardcoded color, or a prop with a different name is easy to justify in isolation.

Useful checks are unglamorous:

• detached instances in ready-for-development frames
• raw color or spacing values in component usage
• variants present in Figma but absent from code
• props present in code but absent from Figma
• screenshots that differ from component examples
• accessibility states documented in code but missing from design guidance

Dev Mode did not align the system by itself. It made the mismatches easier to inspect. Accountability starts when the team treats those mismatches as maintenance work instead of as normal handoff noise.