Як перетворити фронтенд-код на редагований Figma-макет: розробка плагіна Source → Design

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Останнім часом я багато працюю на перетині дизайну, фронтенду та AI. Раніше процес був для мене досить звичним: спочатку дизайн у Figma, потім верстка, розробка і правки.

Але, працюючи над власними продуктами, я дедалі частіше бачив іншу ситуацію. Інтерфейс уже існує в коді. Він працює у браузері, має компоненти, стилі, адаптивність, тексти, кнопки та різні стани. Водночас актуального Figma-файлу для нього немає.

Таке часто трапляється, коли AI генерує цілком непоганий інтерфейс у HTML або React. Код уже можна відкрити, протестувати й показати користувачам. Проте якщо далі його потрібно обговорити з дизайнером, командою або замовником, і для цього необхідно мати не готову зверстану версію продукту, а макет у Figma, якій можна редагувати.

Коли його не має, починається зайва ручна робота. Відкриваєш сайт, відкриваєш Figma і відтворюєш те, що вже існує: тексти, шрифти, відступи, кольори, форми, зображення та вектори. Десь допомагає Dev Mode, десь доводиться вимірювати на око, а десь результат виходить лише приблизно схожим на оригінал.

Після кількох таких ситуацій я зловив себе на простій думці: браузер уже знає, як виглядає інтерфейс. Код уже містить його структуру. CSS описує кольори, шрифти, тіні, радіуси та відступи. Чому ж усе це потрібно вручну переносити назад у Figma?

Так з’явилася ідея Source → Design.

Ідея

Source → Design це плагін для Figma, який перетворює вихідний фронтенд-код на редагований Figma-макет.

Йдеться не про скриншот сторінки чи картинку, вставлену на полотно. Після імпорту користувач отримує нативні шари Figma: фрейми, текст, вектори, зображення, заливки, межі, тіні, параметри типографіки та відступи. Важлива й логічна структура шарів, щоб із документом можна було працювати далі.

Сценарій наступний: завантажити HTML-файл або ZIP-архів із фронтенд-проєктом і отримати у Figma його редаговану версію.

На практиці ця задача виявилася значно складнішою, ніж здавалося спочатку.

HTML, React чи Next.js це не дизайн-макет. Навіть якщо сторінка має охайний вигляд у браузері, всередині можуть бути десятки вкладених div, Tailwind-класи, CSS variables, SVG, псевдоелементи, вебшрифти, градієнти, адаптивна верстка, canvas, sticky-блоки, Shadow DOM і різні viewport-и. Браузер уміє все це відобразити, але Figma не завжди має прямий спосіб відтворити той самий результат.

Мені не хотілося робити інструмент, який фактично створює скриншот сайту й вставляє його у Figma. Такі рішення можуть бути корисними для референсу, але з отриманим результатом неможливо працювати як із повноцінним дизайном.

Я хотів іншого: щоб текст залишався текстом, SVG залишалися векторами, блоки мали зрозумілі межі, кольори можна було змінювати, а структура документа була прозорою та логічною.

Чому це взагалі потрібно

У класичному процесі Figma передує коду. Дизайнер створює макет, розробник його реалізує, а потім команда або замовник порівнюють результат із дизайном.

У реальному житті цей порядок часто змінюється.

1. Стартапи. Першу версію збирають на React без окремих макетів, бо потрібно швидко перевірити гіпотезу. Через кілька місяців продукт росте, з’являються нові екрани й маркетингові задачі. Тоді виникає потреба привести інтерфейс до єдиної дизайн-системи у Figma.
2. AI-генерація. Розробник створює інтерфейс за допомогою ChatGPT, Claude, v0 або Lovable. Код уже є й працює. Але дизайнер не буде редагувати HTML у браузері. Йому потрібен Figma-файл, щоб доопрацювати композицію, перевірити типографіку та зібрати систему.
3. Розбіжність із продакшеном. У Figma лежить застаріла версія, а реальний сайт змінюється окремо. Якщо потрібно почати редизайн, чесніше спиратися на те, що користувачі бачать у браузері, а не на файл, який давно перестав бути актуальним.

У таких ситуаціях я бачу Source → Design як спосіб швидко повернути наявний фронтенд у звичний робочий простір дизайнера, тобто у Figma.

Як працює продукт

У першій версії я зосередився на таких джерелах:

• HTML-файли;
• ZIP-архіви зі статичними проєктами;
• ZIP-архіви проєктів на React, Next.js, Vue та Svelte.

Окремо довелося врахувати складні браузерні елементи, для яких у Figma немає прямого редагованого відповідника: canvas, WebGL і відео. У таких випадках краще зберегти конкретну ділянку як растрове зображення, ніж зламати весь імпорт або створити штучну структуру, з якою все одно неможливо нормально працювати.

Процес виглядає так:

1. Користувач запускає плагін у Figma та завантажує HTML або ZIP-архів.
2. Сервіс визначає тип проєкту.
3. Якщо це фронтенд-проєкт, він збирається в ізольованому середовищі.
4. Chromium відкриває результат як реальну сторінку.
5. Система зчитує фактичне розташування й розміри елементів, обчислені стилі, типографіку та доступні зображення й вектори.
6. Дані перетворюються на проміжну модель інтерфейсу.
7. На її основі формується план створення шарів у Figma.
8. Плагін створює нативні елементи Figma.

Тут важлива одна деталь. Я не хотів покладатися лише на DOM, тобто технічне дерево елементів сторінки. DOM показує, які елементи є на сторінці, але не завжди пояснює, як саме вони виглядають після застосування CSS-правил, JavaScript і браузерного рендерингу.

Тому Source → Design аналізує не тільки вихідний код, а й результат його рендерингу у Chromium. Саме браузер дає найточнішу відповідь про фактичний вигляд інтерфейсу.

Розробка

Технічний стек я обрав наступний:

• Frontend: React, Vite, TypeScript
• Figma plugin: TypeScript, React UI (всередині iframe плагіна)
• API: Fastify
• Worker: Node.js (ізольована обробка ZIP)
• Rendering: Playwright / Chromium
• Database: PostgreSQL + Prisma
• Hosting: Railway
• Payments: WayForPay

Архітектурно продукт складається з вебзастосунку, API, worker, плагіна для Figma та окремих пакетів для аналізу коду, рендерингу, зіставлення вихідного коду з результатом рендерингу, пошуку токенів і компонентів, а також створення Figma-шарів.

У реальній розробці найскладнішим було не намалювати прямокутник у Figma. Це якраз одна з простіших частин.

Складність полягала в іншому: зрозуміти, який саме елемент потрібно створити, як його назвати, які стилі застосувати, що робити з вкладеністю, як не зламати позиціонування, не втратити текст і вектори, а головне, не перетворити документ на хаос із тисячі безіменних шарів.

Проблема 1. Структура коду не збігається зі структурою дизайну

Коли дивишся на готовий сайт, він ніби складається з логічних частин: шапки, першого екрана, карток, кнопок, блоку з тарифами та підвалу.

Але в коді ця структура може виглядати зовсім інакше. Один компонент може містити цілу секцію, інший відповідати лише за кнопку, а третій бути технічним контейнером для побудови макета і взагалі не мати власного візуального змісту.

Figma-файл має бути зрозумілим людині. Якщо переносити кожен DOM-вузол, тобто кожен технічний елемент структури сторінки, як окремий фрейм, результат буде точним з погляду коду, але незручним для подальшої роботи.

Тому я поєднав два типи аналізу. Аналіз вихідного коду допомагає зрозуміти, які компоненти є у проєкті, як вони називаються, які дані отримують і які можуть мати варіанти. Аналіз сторінки у браузері показує, як ці елементи насправді виглядають після рендерингу.

Окремий шар логіки зіставляє ці дані. Якщо система визначає, що конкретний блок на сторінці відповідає певному React-компоненту, вона може дати йому зрозумілу назву, правильно розмістити у структурі Figma-файлу та зберегти корисний контекст.

Проблема 2. Концепція Pixel perfect і редагованість часто конфліктують

У браузері текст може мати певну висоту й ширину через особливості відображення шрифту, міжрядковий інтервал і субпіксельні вимірювання. У Figma той самий шрифт іноді поводиться трохи інакше.

Якщо за будь-яку ціну прагнути повної візуальної ідентичності з браузером, іноді доведеться пожертвувати можливістю редагування. Якщо ж максимально зосередитися на редагованості, можуть виникати невеликі відмінності від оригіналу.

Тут немає одного ідеального рішення. Я обрав практичніший підхід: головна мета це створити редагований Figma-документ. Якщо Figma не може коректно відтворити певну браузерну можливість, краще залишити окремий фрагмент растровим зображенням.

Наприклад, елементи, створені через canvas або WebGL, не варто імітувати набором векторів. Це створило б лише видимість редагованості. Краще точно зберегти такий фрагмент візуально, а решту сторінки залишити повноцінно доступною для змін.

Проблема 3. У Figma інша модель побудови інтерфейсу

У браузері розробник мислить CSS-властивостями: display, position, z-index, overflow, font-family, box-shadow, transform.

У Figma інша модель: фрейми, шари, заливки, межі, ефекти, обмеження позиціонування, текстові та векторні елементи.

Не кожна CSS-властивість має прямий відповідник у Figma. Деякі речі можна перенести точно, деякі лише наближено, а деякі краще залишити растровими, бо спроба зробити їх редагованими дасть гірший результат.

Щоб не змішувати аналіз сторінки та створення Figma-шарів в одному наборі умов, я додав проміжну структуру DesignIR. Вона зберігає нейтральний опис інтерфейсу: його елементи, розміри, стилі та ієрархію.

Лише після цього окремий план рендерингу перетворює опис на фрейми, текст, заливки, вектори та інші нативні елементи Figma.

Без такого проміжного шару логіка швидко перетворилася б на набір простих правил: якщо є div, створити фрейм; якщо є текст, створити текстовий шар; якщо є фон, додати заливку. Але для реальних проєктів потрібна значно гнучкіша модель, яку я реалізував.

Проблема 4. Архів із проєктом не завжди можна запустити однаково

З окремим HTML-файлом усе відносно просто. У ньому вже є структура сторінки, стилі та підключені ресурси. Набагато складніше, коли користувач завантажує ZIP-архів із проєктом на React або Next.js.

Кожен проєкт має власну структуру та спосіб запуску. У ньому можуть використовуватися різні менеджери залежностей, відрізнятися команда для збірки, бракувати окремих файлів або ресурсів. Частина зображень, шрифтів чи іконок може завантажуватися із зовнішніх сервісів і не потрапити до архіву. Іноді для запуску потрібні змінні середовища, а іноді код взагалі розрахований на конкретну інфраструктуру.

Тому не можна просто прийняти архів і запустити його на основному сервері застосунку. Це створило б ризики для безпеки та стабільності сервісу.

Я виніс обробку таких архівів в окреме ізольоване середовище. Воно має власні тимчасові та кешовані теки, обмеження часу на виконання і не має доступу до платежів, бази даних чи інших чутливих даних продукту. Після завершення обробки всі запущені процеси очищуються.

Ця частина майже непомітна для користувача, але вона критично важлива. Інструмент, який приймає чужий код, має думати не лише про те, як відтворити інтерфейс, а й про те, як зробити це безпечно.

Проблема 5. Імпорт має бути не лише точним, а й зрозумілим

Перші вдалі імпорти виглядали переконливо, доки я не відкривав панель шарів у Figma.

Візуально результат уже був схожим на оригінал. Але якщо всередині документа хаос, працювати з ним складно. Дизайнер не має витрачати десять хвилин, щоб знайти шапку сайту, кнопку, текстовий блок або зрозуміти, які шари є лише технічними контейнерами.

Тому багато роботи пішло не тільки на точність відтворення, а й на назви шарів, групування та очищення структури від зайвих технічних елементів.

Водночас не можна просто видалити всі технічні контейнері. Частина з них відповідає за обрізання вмісту, прозорість, позиціонування або структуру макета. Але залишати їх усі без змін теж не варто, бо тоді Figma-документ повторює технічний хаос коду.

Поступово сформувався принцип: зберігати точність там, де вона важлива для вигляду інтерфейсу, і прибирати технічний шум там, де він не впливає на результат.

У цьому для мене різниця між простим конвертером і робочим інструментом. Робочий інструмент має подбати про те, щоб користувач міг з цим результатом зручно працювати.

Що вміє перша версія

У першій версії Source → Design створює Figma-макети з підтримуваних файлів фронтенд-коду.

Після імпорту користувач отримує:

• редаговані текстові шари;
• фрейми та групи з розмірами й позиціями, отриманими після рендерингу у браузері;
• заливки, межі, радіуси, тіні, градієнти та прозорість;
• параметри типографіки: шрифт, накреслення, розмір, міжрядковий інтервал, відстань між літерами та вирівнювання;
• векторні SVG-елементи й зображення у відповідних межах;
• зрозумілішу структуру шарів;
• растрове представлення для складних браузерних елементів, які неможливо коректно редагувати у Figma;
• підтримку HTML, ZIP-архівів, React, Next.js, Vue та Svelte.

Сайт продукту: sourcetodesign.com

Плагін у Figma Community: Source → Design

Що я зрозумів під час розробки

Головний і досить очевидний висновок для мене такий: як не дивно, перетворити код на дизайн складніше, ніж перетворити дизайн на код 😃. Figma-файл це структурована модель інтерфейсу коли браузерна сторінка це результат роботи коду, CSS, JavaScript і підключених ресурсів. Вона може виглядати просто, але всередині мати складну структуру, .

Інструменти штучного інтелекту лише посилюють цю зміну. Інтерфейс дедалі частіше народжується не тільки у Figma, а й одразу у коді або AI генераторі. Щоб нормально працювати з такими результатами, потрібні інструменти, які дозволяють рухатися в обидва боки.

Напрям перетворення дизайну на код існує давно. Але перенесення коду у Figma стає не менш важливим, особливо коли команді потрібно не просто подивитися на готовий інтерфейс, а повернути його в дизайн-процес, доопрацювати, узгодити й перетворити на систему.

Source → Design для мене саме про те, щоб прибрати ручну роботу там, де браузер і код уже містять достатньо інформації.

Адже іноді найкраща точка старту для нового дизайну, це продукт, який уже працює.