Тестувала GitHub Integration у Figma Make: AI прочитав репозиторій, але вигадав нового дизайнера

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

Мене звати Ніна Войтович, я Product Designer в Involve.software.

Цього разу розповім про тестування GitHub Integration у Figma Make. Я хотіла перевірити, наскільки ця інтеграція справді може спростити роботу дизайнера. Для першого експерименту обрала власний сайт-портфоліо, над яким уже давно працюю в Cursor. Репозиторій був готовий, а сам проєкт мав сформовану дизайн-систему, готові компоненти та досить незвичну структуру. Саме тому він здавався мені ідеальним кандидатом для тестування.

Сценарій 1: Коли доступ до репозиторію не допоміг зрозуміти продукт

Логіка була проста — Figma Make уже має доступ до репозиторію, а отже може проаналізувати не лише код, а й усю структуру продукту. Здавалось, зараз відбудеться магія: Figma Make прочитає репозиторій, зрозуміє структуру і я зможу швидко відтворити або продовжити свій сайт.

Підключивши GitHub я попросила створити сайт за дизайн-системою з репозиторію. Figma Make проаналізував код і компоненти. Він правильно визначив стек, побачив React, TypeScript, Tailwind та структуру проєкту. Але далі щось пішло не так.

Замість мого портфоліо на екрані з’явилась якась Layla Chen з Амстердама. Це був типовий шаблон продуктового дизайнера з вигаданими кейсами та інформацією. А структура та анімації були схожі на типовий Framer-сайт. Візуально було досить навіть непогано, але все ж зовсім не те.

Перший результат після підключення GitHub. Make зчитав код, але згенерував типовий шаблон портфоліо.

Бачить код ≠ розуміє продукт

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

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

Після кількох ітерацій Figma Make почав використовувати існуючу дизайн-систему та реальний контекст проєкту.

Інсайт № 1. Контекст не дорівнює розумінню. Магія відбулась, але не та на яку я очікувала. Просто GitHub Integration дає Figma Make доступ до структури проєкту, але не пояснює, який продукт стоїть за цим кодом. Саме тому якість промптів досі має вирішальне значення.

Сценарій 2: Чи втримається дизайн-система на новій сторінці

Після першого експерименту мені стало цікаво інше. Якщо не просити Make перебудувати весь сайт, а дати йому набагато вужчу задачу. Чи зможе він створити новий кейс так, ніби той завжди був частиною портфоліо? Для цього я попросила додати новий проєкт — мій реальний концепт мобільного застосунку, який уже був оформлений окремо на Behance. Я не просила вигадувати новий стиль чи нову структуру.

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

Що зробив Figma Make:

• повторював структуру сторінок;
• використовував ті самі принципи композиції;
• не створював нові компоненти без потреби;
• підлаштовував новий контент під існуючу систему.

Новий кейс інтегровано в існуючу структуру портфоліо без зміни стилю сайту.

Сторінка продовжує використовувати ті самі принципи композиції, типографіку та компоненти, що й решта портфоліо.

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

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

Інсайт № 2: Менший скоуп — точніший результат. Найбільше мене здивувало, що Figma Make не просто повторив компоненти. Він ніби підхопив логіку вже існуючого портфоліо. Якби я не знала, що сторінка була згенерована, то цілком могла б подумати, що сама створила її кілька тижнів тому.

Сценарій 3. Чи можна перебудувати тему без ручної роботи

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

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

• проаналізував theme.css;
• знайшов hardcoded-значення;
• працював через токени, а не вручну по екранах;
• додав клас .light;
• додав перемикач теми;
• зберіг вибір теми через localStorage.

Темна та світла теми після генерації. Make працював не з окремими екранами, а зі структурою проєкту та системою дизайн-токенів.

Інсайт № 3: AI починає із системи, а не з екранів. Я очікувала, що він просто замінить кольори. Натомість він почав із theme.css. Саме в цей момент стало зрозуміло, що він працює не на рівні окремих макетів, а на рівні архітектури дизайн-системи. Тобто GitHub Integration дає доступ не лише до коду, а й до структури проєкту. Саме тут я зрозуміла, що Figma Make працює не як графічний редактор, а значно ближче до AI-розробника. Це був класний результат.

Сценарій 4: Чи можна повернути результат назад у GitHub

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

Тоді я пішла шукати кнопку Commit. Але саме тут почались пригоди. Спочатку я перевірила меню з трьома крапками — там були лише Hard reload preview та Open console. Потім відкрила Publish, але він виявився стандартним сценарієм публікації Figma Site, а не записом у GitHub.

Я вже почала сумніватися, чи взагалі підтримує Figma Make запис у GitHub. Перевіряла налаштування проєкту, інтеграції та все, що хоч якось було пов’язано з GitHub. Саме в цей момент з’ясувалось що існує два окремі сценарії роботи з репозиторієм:

1. Коли Figma Make використовує репозиторій як джерело контексту та читає код.
2. Коли зміни потрібно повернути назад у GitHub.

Думала що це одна функція, але виявилось, що це два різні процеси з різними налаштуваннями.

Щоб перевірити це на практиці, я вирішила не ризикувати основним проєктом і створила окремий тестовий репозиторій.

Найцікавіше те, що Figma Make працював не з порожнього аркуша. До цього моменту він уже кілька сценаріїв поспіль аналізував мій сайт-портфоліо, його структуру, компоненти та дизайн-систему.

Фактично новий проєкт став продовженням попереднього контексту. Figma Make використав уже проаналізовані підходи, сформував нову структуру застосунку, доповнив її новими екранами та записав результат у тестовий репозиторій.

Саме це стало для мене найцікавішою частиною експерименту. GitHub використовувався не лише як сховище коду, а й як джерело контексту, який Figma Make переносив між різними задачами.

Новий GitHub-репозиторій після коміту з Figma Make. Згенерований проєкт уже містить структуру сайту, новий кейс та оновлений README.

Інсайт № 4: Новий репозиторій не означав новий початок. Figma Make не лише прочитав код, але і записав результат назад у GitHub. Але найбільше мене здивувало те, що він не поводився так, ніби починає з нуля. Контекст із попередніх сценаріїв перейшов у новий проєкт. Тобто GitHub тут працює не лише як сховище коду, а як пам’ять між задачами.

Що я винесла з цього тестування

Після чотирьох сценаріїв стало зрозуміло: GitHub Integration у Figma Make — це не просто спосіб дати AI доступ до коду. Її найбільша цінність у контексті. Але навіть доступу до репозиторію недостатньо. Якщо продукт не пояснений або задача сформульована нечітко — AI все одно почне вигадувати.

Якщо ви плануєте працювати з GitHub Integration, я б рекомендувала врахувати кілька речей:

• Починайте з вузького завдання. Не «Створи сайт за цією дизайн-системою», а «Додай одну конкретну сторінку». Чим менше простору для вигадки — тим точнішим буде результат.
• Пояснюйте продукт, а не лише стек. React, TypeScript і Tailwind Figma Make побачить і сам.
• Подбайте про контекст. Чим більше в репозиторії структурованого контексту — тим кращим буде результат. Якщо цього немає — чекай свою Layla Chen.
• Не плутайте читання репозиторію із записом змін. Підключений репозиторій не означає автоматичної синхронізації. Краще перевірити одразу, ніж потім шукати кнопку Commit по всьому інтерфейсу.
• Завжди перевіряйте продуктову логіку. Figma Make може запропонувати правила та обмеження, яких немає в реальному продукті. Це завжди потребує перевірки.

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