Contact:

andrew.antoshkin@gmail.com
Writing

Why design system designers should understand development in 2026

design systems Figma Slots Code Connect

Current as of August 21, 2026. A design system designer does not need to become a frontend developer. But without an understanding of layout, component APIs, tokens, accessibility, and change validation, it is difficult to design a system that works consistently in Figma and production.

The gap between Figma and code has not disappeared

A component in Figma and a component in React, SwiftUI, or Compose are different objects. They may describe the same interface, but they have different constraints, lifecycles, and methods of composition.

A mockup does not automatically show:

  • HTML semantics and the accessibility tree;
  • keyboard interaction and focus management;
  • loading, empty, error, and permission states;
  • localization, long content, and data formatting;
  • API boundaries and component responsibilities;
  • performance and the cost of dependencies.

That is why “pixel-perfect” is not enough. A system designer must be able to discuss behavior, not just appearance.

Props, state, and composition

In React, a component receives props and returns UI. Nested JSX is passed through the children prop:

function Card({ children }) {
  return <div className="card">{children}</div>
}

<Card>
  <Avatar />
  <p>User profile</p>
</Card>

This does not mean every component API should be as flexible as possible. Sometimes children is appropriate, sometimes named content props are better, and sometimes a strict subset of child components is needed. Understanding code helps you choose the right degree of flexibility instead of creating an endless component set.

Figma Slots: what they actually are

Native Slots reached general availability in June 2026, not 2025. A Slot is one of five types of component properties in Figma, alongside boolean, instance swap, text, and variant properties.

A Slot creates a flexible area inside a component instance. Content can be added, edited, and reordered within it without detaching the instance. You can define default content, preferred instances, minimum and maximum layer counts, and other slot settings. Slots are available in Figma Design on all plans; any user with permission to edit the file can create them.

This is similar to children or a content slot in code, but it is not a complete equivalent:

  • a Figma Slot controls how layers are edited inside an instance;
  • a code API controls types, data, state, and runtime behavior;
  • a visually valid composition may be semantically incorrect;
  • slot constraints do not replace a type system or tests.

When to use a Slot, instance swap, or variant

  • Variant — for a constrained set of states or types: size, tone, state.
  • Instance swap — when a specific nested component needs to be replaced from a controlled set.
  • Slot — when an area needs to support different content arrangements and combinations: a modal body, an action list, or card content.

Do not migrate everything to Slots. The more flexible an area is, the more responsibility falls on the library user. For a status icon or leading action, instance swap is often safer.

Code Connect and Slots

Code Connect can map a native Slot to composition in code. As of August 17, 2026, the only actively supported format is framework-agnostic .figma.ts template files. In these files, a Slot is read with getSlot(); the older figma.slot() belongs to the legacy React/HTML parsers.

// url=https://figma.com/design/...?node-id=123
// source=src/components/Card.tsx
// component=Card

import figma from 'figma'

const content = figma.selectedInstance.getSlot('Content')

export default {
  example: figma.code`<Card>${content}</Card>`,
  imports: ['import { Card } from "@company/ui"'],
  id: 'card',
}

There is an important limitation: by default, Dev Mode displays a slot as a clickable link rather than expanding all of its nested code. connectedInstances can output directly nested code-connected components, but the lookup is shallow: text, regular layers, unconnected instances, and deeply nested instances are omitted. The remote Figma MCP, by contrast, can traverse a slot and retrieve its layout and nested content.

Tokens: a stable format has arrived

A design token is more than a name for a HEX value. It provides a durable link between intent and a platform-specific value. A semantic token such as color.text.muted makes it possible to change a theme or contrast mode without rewriting components.

In October 2025, the DTCG published its first stable specification, 2025.10. This is an important step toward exchanging tokens between tools, but it is not a W3C Standard, nor does it guarantee that Figma, your transformer, and every platform support each type in the same way.

The practical implications for designers:

  • separate primitive, semantic, and component tokens only where justified;
  • do not manually duplicate values between Figma and the repository;
  • document modes, aliases, and fallback behavior;
  • validate generated outputs on every target platform;
  • do not call arbitrary JSON “DTCG-compatible” without validation.

Code Connect is not magical synchronization

Code Connect links a library component in Figma to a component in the repository. Template files are not tied to a framework: a single TypeScript template can generate a snippet for React, Web Components, SwiftUI, Compose, or another language. Framework-specific parsers remain available in older CLI versions but are no longer supported.

The Code Connect UI is simpler: it runs inside Figma and connects to GitHub to map design and code for MCP. However, a UI mapping does not display a custom snippet in Inspect — that requires the CLI.

Neither the UI nor the CLI provides automatic two-way API synchronization. If a prop is renamed, a variant is removed, or behavior changes, the mapping and documentation must be updated and verified.

AI accelerates execution but does not make product decisions

Cursor, Claude Code, and other agents can inspect a repository, retrieve Figma context through MCP, modify files, and run checks. This lets a designer build a working prototype more quickly or test a solution in a real layout.

But an agent does not automatically know:

  • which product behavior is considered correct;
  • which component is canonical;
  • whether a new dependency is acceptable;
  • whether the interface meets accessibility requirements;
  • which tradeoffs matter to the team.

Designers need a basic understanding of browsers and code to evaluate the result. Otherwise, AI turns an unverified assumption into a convincing-looking diff.

What designers should actually learn

  1. HTML and semantics. Elements, forms, headings, landmarks, accessible names.
  2. CSS layout. Box model, flex, grid, intrinsic sizing, overflow, container and media queries.
  3. Accessibility. Keyboard, focus, contrast, reduced motion, screen-reader basics.
  4. Component APIs. Props, state, composition, controlled and uncontrolled patterns.
  5. Tokens. Aliases, modes, semantic naming, transformation, and platform outputs.
  6. Git and review. Branches, diffs, commits, pull requests, conflicts.
  7. DevTools and tests. Inspect, computed styles, responsive mode, console, network, visual and interaction tests.

React is not essential if your team uses another platform. What matters is understanding the model of the target environment, not memorizing a single framework.

Practice with one component

Choose a moderately complex component — for example, a Dialog or Card — and work through the full cycle:

  1. describe its purpose and the scenarios it is not suited for;
  2. choose variants, swaps, and slots in Figma;
  3. map them to the code API;
  4. define tokens and responsive behavior;
  5. add focus, keyboard, and error states;
  6. connect it through Code Connect;
  7. verify the implementation in Storybook or the application;
  8. update the documentation in the same pull request.

Conclusion

Understanding development does not mean writing all production code yourself. It means designing component APIs, recognizing platform constraints, validating implementations, and discussing decisions with engineers without losing the original intent.

Slots, Code Connect, MCP, and AI narrow the mechanical gap between Figma and code. They do not close the architectural gap. That requires a team that has agreed on sources of truth, contracts, and validation.

Sources