From design to code: Figma, handoff and working with AI

Handoff is preparing a Figma design for building: named layers, components, variables instead of numbers, every state, and a narrow screen.

How a designer sees a page

A designer works not in code but in a tool for designs. The most widespread is called Figma; there’s an open alternative, Penpot. They share a principle: a canvas, frames on it, layers in the frames. It’s good to know a few words of their vocabulary, because it’s in these words that a design speaks to code.

• A frame. A rectangle with content, a “screen” or a block. In code it corresponds to an element (div, section).
• Auto layout. A frame that lays out its children in a row or a column, with a set gap and padding. It’s almost exactly display: flex with gap and padding. Width has three modes: Hug (by content), Fill (take all the room, like flex: 1) and Fixed (a number).
• A component and variants. A part that can be repeated; variants (a primary and a secondary button, a pressed and an ordinary one) are gathered into one component with “properties”. In code that’s a component and its modifiers.
• Variables and modes. Named values (colors, numbers) that can have several definitions by mode: for example a light and a dark theme. Figma itself says design tokens can be built on them.
• Dev Mode. A developer’s workspace in Figma: they see sizes, layer properties, variables and code, and the designer can mark a design “ready for dev”.

Click the parts of the design below: on the left is what the designer set, on the right the same meaning in CSS. Notice that everywhere there are names of tokens, not numbers.

.card {
  display: flex;
  flex-direction: column;
  gap: var(--space-2);
  padding: var(--space-4);
  border-radius: var(--radius-md);
  background: var(--surface-raised);
}

What a developer needs: a design ready for handoff

The handoff of a design (handoff) breaks where the designer is sure that “everything is obvious”. These are the things whose absence forces a developer to ask questions:

1. Named layers. Hero/Title, Hero/Action, Cards/Item, not “Frame 482”. From the names a developer finds what is needed, and an AI tool gets meaningful names.
2. Components, not copies. If a button is drawn ten times instead of taken from a component, there will be ten of them in code too.
3. Variables instead of random values. A color taken from the variable color/accent turns into var(--action). A color picked with an eyedropper turns into a number that nobody can find later.
4. Every state of the main components: hover, focus, disabled, loading, error.
5. A narrow screen. You don’t have to draw all the pages, but you must describe the behavior: what goes in one column, what hides, what turns into a menu button. Usually three frames are drawn: about 375, 768 and 1280 pixels.
6. Assets. What is delivered as vectors (icons, a logo: SVG, sharp on any screen) and what as raster (photographs: WebP, AVIF or JPEG, in several sizes for different screens), and in what sizes.
7. Real text. A design with “Lorem ipsum” hides problems: long headings, empty fields. Labels in other languages are usually longer than English ones.
8. Notes. What happens on a press, the focus order, the text for alt.

How a design becomes code

There are several ways, and all of them lean on tokens.

• By hand. A developer looks at the design and writes the markup. The most reliable way for a small site.
• Through Dev Mode. Code and sizes are taken from the design. With care: automatic code likes absolute sizes, which good markup shouldn’t have. Besides, Figma has Code Connect, which links a design’s component to the real component in code, so that new parts take the ready one.
• Through tokens. Figma variables are exported to a tokens file (the DTCG format from the previous lesson), and a program such as Style Dictionary makes CSS from it. Then values stay in step without manual work. You learned more about the tokens file in the eleventh lesson.
• With the help of AI. Figma offers an MCP server, through which an AI agent gets structured information about a design so as to make code from it. You’ll meet such tools in the part on AI.

About this last way it’s worth being honest: an AI builds markup from a design quickly, but errs just as a person does. Typical mismatches:

• a number copied from the design stands in place of a token;
• a state is forgotten (most often focus);
• there’s no version for a narrow screen;
• the colors are “almost the same”, not taken from variables.

So the task you give an AI is the same handoff specification: the fuller it is, the fewer the corrections. And the result is checked all the same: against the tokens, against the states, and on a narrow screen.

An example from this textbook

The textbook itself has a design system, and it’s arranged exactly like this. The design/ folder of the repository holds the tokens: they weren’t written by hand but generated from a tokens file in the DTCG format that lives in the NoeticEcho project. Where they come from and what was changed is recorded in the file PROVENANCE.md (linked in the sources). Open design/tokens.css: you’ll see the same layers as in the last lesson. Base values such as --ink-100 and --paper-100, semantic ones such as --surface-canvas, --text-primary, --accent-command, and comments where the designer decided something: for example, why the text color has a separate, lighter step than the fill color (because on a dark panel the original color failed the contrast check).

This is just what you do in the practice: the decision is written in a file and in a name, not in the author’s head.

Practice

Write the handoff specification of your project’s first screen. Begin with the content: the sections and the main action are filled in from your brief. Then the frames, layers, tokens, states, assets and the narrow screen.

Fill in the last section after the markup has been built from the specification. If you have no AI tool at hand, take any code (your own from the earlier lessons too) and find the mismatches with the specification: numbers instead of tokens, forgotten states, no narrow screen. The ability to find such mismatches is the skill we write all this for.

What was wrong with 2025

In 2025 AI tools were already building markup from designs, but without a design system they took values “from the picture”: the code came out looking like the design and drifting from the tokens. The teams that gained were those whose design and code spoke one language of tokens, so the tools had something to keep to.