Перетворити Figma в код у 2026 означає не натиснути кнопку в плагіні, а пройти пайплайн: увімкнути Dev Mode, звести кольори й відступи до Figma Variables як єдиного джерела правди, а потім поставити точну задачу Claude Code, який напише компонент на основі цих токенів. Плагін-експортер дає розмітку з абсолютним позиціюванням, яку доведеться переписувати з нуля. Пайплайн дає компонент, що живе в дизайн-системі і не ламається при першій же зміні кольору. Різниця не в швидкості, а в тому, хто контролює результат: інструмент чи ти.
Я, Dmytro Nikolaienko, 15 років роблю продукти у фінтеху і останні кілька років веду дизайнерів через перехід у код на курсі «Design Engineer». Питання «як з Figma отримати код» мені пишуть щотижня, і майже завжди мають на увазі саме плагін-кнопку. Нижче - чому це не працює, який пайплайн працює замість неї і скільки часу він насправді забирає.
Що насправді означає Figma to code?
Визначення: Figma to code - це не разова конвертація файлу, а повторюваний процес, у якому макет, токени і компонент у коді залишаються синхронізованими після кожної зміни дизайну.
Коли хтось шукає «figma to code», у голові зазвичай картинка: завантажив файл, отримав готовий сайт. Так це не працює і ніколи не працювало добре. Макет у Figma - це намір: тут кнопка primary, тут відступ 16px, тут стан hover. Код - це реалізація цього наміру у браузері, з усіма станами, адаптивом і доступністю, яких на статичному кадрі просто немає.
Тому робочий Figma to code - це міст, а не переклад. З одного боку макет з чіткими токенами, з іншого код, що читає ці токени. Посередині людина, яка перевіряє, що міст не просів.
На практиці це виглядає так. Зробив зміну кольору кнопки в Figma Variables - у коді значення підтягнулось само, бо компонент посилається на той самий токен, а не на захардкоджений хекс. Додав новий стан у макеті - написав задачу агенту, той доробив компонент за 10 хвилин замість того, щоб чекати на розробника два спринти. Пайплайн не про швидкість першого разу, а про те, що кожен наступний раз дешевший за попередній.
Чому плагіни-експортери коду не працюють?
Тут немає нічого особисто проти конкретних плагінів. Проблема в самому підході: плагін читає координати шарів, а не намір дизайнера. Він бачить прямокутник на 240 на 48 пікселів з певним кольором фону і текстом усередині, і видає саме це: прямокутник. А не кнопку з роллю, станами і зв'язком з рештою системи.
- Абсолютне позиціювання замість flex і grid. Все тримається на пікселях, тому будь-яка зміна тексту ламає верстку.
- Кольори хексами, а не токенами. Замість
var(--color-primary)ти отримуєш#3B82F6у сотні місць, і темна тема стає окремим проєктом. - Один файл замість компонентів. Кнопка не переюзається, вона копіюється кожного разу з нуля.
- Немає станів. Плагін бачить один кадр, а не hover, focus, disabled чи loading.
- Код не мержиться в реальний проєкт. У команди вже є свій стек, конвенції і рев'ю, а експортований файл про це нічого не знає.
Результат завжди однаковий: розробник дивиться на експортований код, зітхає і переписує його заново. Тобто плагін не заощадив час, а додав крок. У проєктах, де я аудитую дизайн-систему, такий код зазвичай навіть не потрапляє в pull request: його показують один раз, як демо, і забувають, бо мержити нема куди.
Який робочий пайплайн Figma → код у 2026?
Ось послідовність, яку я показую на курсі і використовую сам у реальних проєктах.
| Крок | Що робиш | Інструмент |
|---|---|---|
| 1. Підготовка макета | Auto Layout замість вільних груп, семантичні назви шарів, компоненти замість копіпасти | Figma |
| 2. Dev Mode | перевіряєш згенеровані CSS-значення, шукаєш значення поза токенами | Figma Dev Mode |
| 3. Токени | зводиш кольори, відступи і типографіку до Variables трьома рівнями | Figma Variables |
| 4. Постановка задачі | описуєш компонент, стани і посилання на існуючі токени в проєкті | CLAUDE.md |
| 5. Генерація | агент читає структуру і токени та пише компонент у твоєму стеку | Claude Code + MCP |
| 6. Перевірка | стани, адаптив, контраст, пошук хардкоду замість токена | Браузер, Storybook |
| 7. Деплой | компонент іде в реальний проєкт з посиланням, а не скріншотом | Cloudflare Pages / Vercel |
Перші три кроки роблю я, останні два теж я, а середину бере на себе агент. Це і є весь фокус: людина відповідає за намір і перевірку, AI відповідає за набір коду. Якщо пропустити крок з токенами і одразу дати агенту макет, він все одно щось згенерує, тільки значення візьме приблизні, і ти отримаєш той самий хардкод, тільки написаний нейромережею замість плагіна.
Як Figma Variables стають токенами в коді?
Тут найчастіше все ламається, тому що дизайнери і розробники називають одне й те саме по-різному. Правильна структура - три рівні.
- Примітиви. Сирі значення:
blue-500,space-4, без прив'язки до сенсу. - Семантичні токени. Значення з роллю:
color-primary,space-md. Саме тут з'являється темна тема без переробки компонентів. - Токени компонента. Прив'язка до конкретного місця:
button-primary-bg,card-padding.
Коли ці рівні названі однаково в Figma Variables і в конфігу коду, наприклад у Tailwind, Claude Code не вигадує значення сам, а читає їх напряму через Dev Mode чи MCP. Я детальніше розбирав саму структуру токенів у статті CSS-змінні і дизайн-токени для Design Engineer, там же пояснюю, як уникнути 73% захардкоджених кольорів, які зазвичай знаходжу в чужих дизайн-системах під час аудиту.
Де тут Claude Code?
Claude Code не «генерує сайт з картинки». Він виконавець твоєї постановки, і якість результату дорівнює якості задачі. У проєкті лежить файл CLAUDE.md з правилами: стек, назви токенів, заборона хардкоду кольорів, як називати компоненти. Через MCP агент може напряму звернутись до Figma і прочитати структуру шару, а не вгадувати її з картинки.
Формулювання задачі виглядає так: «Компонент Card, Auto Layout по вертикалі, padding з токена card-padding, тінь shadow-sm, у стані hover тінь shadow-md, адаптив за брейкпоінтом md». Це не творче завдання, це технічна специфікація. Саме тому дизайнер, який розуміє код, ставить її краще, ніж будь-який автоматичний конвертер.
Різниця з простим чатом теж принципова. У звичайному чаті ти вставляєш скріншот і сподіваєшся, що модель вгадає розміри. У Claude Code з MCP агент має доступ до файлової системи проєкту, бачить існуючі компоненти і не створює дублікат кнопки, яка вже є в бібліотеці. Він працює в контексті реального репозиторію, а не у вакуумі одного запиту.
Я показую цей процес наживо на YouTube-каналі UX Hero, а базовий захід у Claude Code без досвіду в коді розібрав окремо в статті Claude Code для дизайнерів.
Скільки часу це займає дизайнеру?
Чесно: перший запуск пайплайна на одному компоненті займає день, іноді два, бо треба навести лад у токенах і написати перший нормальний CLAUDE.md. Після цього один екран з 5-6 компонентами виходить за 3-5 годин замість тижня в черзі на розробку.
Порівняй два сценарії. У першому дизайнер робить макет, передає у Jira, чекає на спринт розробки, отримує результат через два тижні і ще тиждень узгоджує розбіжності з макетом. У другому дизайнер сам доводить компонент до коду за день, показує посилання розробнику вже на рев'ю, а не на етапі «ще не почали». Другий сценарій не скасовує розробників, він прибирає з їхньої черги дрібні зміни, які й так забирали час на комунікацію більше, ніж на код.
Головна умова - дизайнер уже має базу: HTML, CSS, Git і розуміння, як читати компонент у коді. Без цієї бази пайплайн перетворюється на здогадки, бо неможливо перевірити, що агент написав правильно. Якщо бази ще нема, я розписав окремий 90-денний план у статті Як дизайнеру навчитись кодити у 2026, і саме з неї варто почати перед першим запуском пайплайна.
Часті питання
Що таке Figma to code простими словами?
Це не одна кнопка, а пайплайн: розмітити макет через Auto Layout, звести кольори й відступи до Figma Variables, а потім поставити чітку задачу Claude Code, який напише компонент на основі цих токенів у твоєму стеку. Результат - живий компонент у реальному проєкті, а не файл, який ще треба переписувати.
Чи можна перетворити Figma в код без Claude Code?
Технічно можна, руками або з іншим агентом. Але Claude Code через MCP бачить структуру макета і токени напряму, тому пише компонент, що одразу відповідає дизайн-системі, а не типовий div на div. Без агента доведеться робити ту саму верстку вручну, і це просто довше.
Чому автоматичний експорт з Figma дає поганий код?
Плагіни-експортери читають координати шарів, а не намір дизайнера. Вони видають абсолютне позиціювання замість flex чи grid, кольори хексами замість токенів і один величезний файл замість компонентів зі станами. Такий код неможливо підтримувати, тому команди його переписують з нуля.
Що таке Figma Variables і навіщо вони для коду?
Variables - це змінні всередині Figma для кольору, відступу, розміру шрифту і радіуса, організовані в три рівні: примітиви, семантичні токени і токени компонентів. Коли вони названі однаково з токенами в коді, Claude Code читає їх напряму через Dev Mode чи MCP і не вигадує значення сам.
Скільки коштує навчитись цьому пайплайну?
У UX Hero є курс «Design Engineer»: 10 лекцій, включно з окремою лекцією про Figma Dev Mode і токени та лекцією про Claude Code з MCP. Курс веде Dmytro Nikolaienko, 130+ випускників уже пройшли шлях від макета до задеплоєного проєкту.
Figma to code - це не про те, щоб AI намалював картинку в код. Це про пайплайн, де токени, постановка задачі і рев'ю важать більше, ніж сама генерація. Онови так один компонент, і решта дизайн-системи піде за тим самим маршрутом.