💡 Усі статті, обговорення та новини про дизайн зібрані в одному місці. Запрошуємо приєднатись до спільноти Design!
Мене звати Ніна Войтович, я Product Designer в Involve.software.
Сьогодні я розкажу про тестування інтеграції GitHub у Figma Make. Мета – перевірити, наскільки ця інтеграція здатна полегшити роботу дизайнера. Для першого досліду я обрала власний сайт-портфоліо, над яким довгий час працюю в Cursor. Репозиторій був готовий, а проєкт містив розвинену дизайн-систему, готові компоненти та досить унікальну структуру, що зробило його ідеальним кандидатом для тестування.
Сценарій 1: Коли доступ до репозиторію не дає повного розуміння продукту
Логіка за задумом була простою: Figma Make мав доступ до репозиторію, отже міг проаналізувати не лише код, а й структуру продукту загалом. Очікувалась ніби магія: Figma Make прочитає репозиторій, збагне структуру, і я зможу швидко відтворити або продовжити розробку сайту.
Після підключення GitHub я попросила створити сайт на базі дизайн-системи з репозиторію. Figma Make проаналізував код і компоненти, точно визначив стек технологій, включно з React, TypeScript, Tailwind, а також структуру проєкту. Проте наступний крок виявився несподіваним і не зовсім вдалим.
Замість мого портфоліо відобразився сайт на ім’я Layla Chen з Амстердама — типовий шаблон продуктової дизайнерки з вигаданими кейсами та наповненням. Структура і анімації нагадували звичайний Framer-сайт. Візуально це було досить приємно, однак не відповідало реальному проекту.
Ключовий висновок: бачити код не означає розуміти продукт
Figma Make прекрасно опрацював код. Але код і сам продукт — це різні речі. Він зафіксував, що має справу з React-проєктом, визначив компоненти і структуру сторінок, але не збагнув, хто є власником сайту, які проєкти реальні і що робить цей сайт унікальним.
Після приблизно шести ітерацій із промптами результат поступово став наближатися до очікуваного. Довелось докладно пояснювати, що не створюється новий дизайнер, і не генерується новий шаблон, а працюємо в рамках вже існуючої дизайн-системи з реальними кейсами.
Інсайт 1: Контекст ≠ розуміння
Магія сталася, але не в тому ключі, що я очікувала. GitHub Integration надає доступ до структури проєкту, але не пояснює сутність продукту, який стоїть за кодом. Саме тому якість промптів залишається критичною.
Сценарій 2: Чи збережеться дизайн-система при створенні нової сторінки
Після першого експерименту виникло інше питання. Що, якщо не просити Make перебудувати весь сайт, а дати вузьку задачу — створити новий кейс, який виглядає органічною частиною портфоліо? Для цього я попросила додати новий проєкт — мій реальний концепт мобільного застосунку, оформлений також у Behance. Я не просила розробляти новий стиль чи структуру.
Завдання було чітке: використати існуючу дизайн-систему сайту й органічно інтегрувати новий кейс.
Що зробив Figma Make:
- повторив структуру сторінок;
- застосував ті самі принципи композиції;
- утримався від створення нових компонент без потреби;
- адаптував новий контент під наявну систему.
Завдяки цьому нова сторінка справляє враження природного продовження портфоліо, ніби працюєш не з окремим екраном, а з уже сформованою системою з репозиторію.
Інсайт 2: Менший обсяг завдань — точніший результат
Особливо вразило, що Figma Make не просто повторив компоненти, а підхопив логіку існуючого портфоліо. Без знання, що сторінка — результат генерації, можна було б подумати, що її створили вручну нещодавно.
Сценарій 3: Чи можливо автоматично змінити тему без ручного втручання
Наступним кроком я зацікавилась, наскільки глибоко Figma Make може працювати з кодом і яким буде результат. Я попросила додати перемикач світлої теми до проєкту, який вже мав темну тему, кольорові токени та набір компонентів. У підсумку Figma Make:
- проаналізував файл theme.css;
- виявив жорстко задані значення;
- працював через дизайн-токени, а не вручну по кожному екрану;
- додав клас .light;
- підключив перемикач теми;
- зробив збереження вибору в localStorage.
Інсайт 3: AI працює з системою, а не лише з екранним дизайном
Очікувала, що просто замінять кольори, але Figma Make почав з аналізу theme.css. Це показало, що інтеграція працює на рівні архітектури дизайн-системи, а не окремих макетів. GitHub надає доступ не тільки до коду, а й до структури проєкту. Figma Make виявляється ближчим до ролі AI-розробника, аніж простого графічного редактора — це дало дуже цікавий результат.
Сценарій 4: Чи можна зберегти зміни назад у GitHub
Спочатку я вважала, що всі зміни автоматично потрапляють у репозиторій. Проте на практиці виявилось, що це не так. Підключений репозиторій не означає автоматичної синхронізації. Шукаючи кнопку Commit, я виявила лише стандартні опції Hard reload preview та Open console, а опція Publish виявилась механізмом публікації Figma Site, а не записом у GitHub.
З’ясувалось, що є два окремі сценарії роботи з репозиторієм:
- Figma Make читає репозиторій і використовує його як джерело контексту.
- Зміни необхідно повернути назад у GitHub.
Це різні процеси з окремими налаштуваннями.
Щоб перевірити це, я створила тестовий репозиторій, щоб не ризикувати основним проєктом. Цікаво, що Figma Make не починав роботу з чистого аркуша, а використав контекст з попередніх дослідів, проаналізував структуру, компоненти та дизайн-систему портфоліо.
В результаті він сформував нову структуру застосунку, додав нові екрани та записав усе в тестовий репозиторій.
Інсайт 4: Новий репозиторій — не порожній початок
Figma Make не тільки зчитав код, але й записав отриманий результат назад у GitHub. Найбільш вражаючим було те, що процес не здався початком роботи з нуля. Контекст із попередніх завдань перейшов у новий проєкт, тож GitHub виконує роль не лише сховища коду, а й своєрідної пам’яті між завданнями.
Узагальнення досвіду тестування
Чотири сценарії продемонстрували, що інтеграція GitHub у Figma Make — це не просто механізм надання AI доступу до коду. Її основна цінність полягає в контексті, який отримує штучний інтелект. Водночас сам цей доступ не гарантує успіху, якщо продукт не роз’яснено або задача сформульована нечітко — AI почне вигадувати.
Рекомендації для роботи з інтеграцією GitHub:
- Починайте з вузьких завдань. Наприклад, не «Створи сайт за дизайн-системою», а «Додай одну конкретну сторінку». Менше простору для фантазій — точніший результат.
- Описуйте продукт, а не лише технологічний стек. Figma Make сам виявить React, TypeScript та Tailwind.
- Подбайте про контекст у репозиторії. Чим більше структурованого контексту — тим кращий результат. Інакше отримаєте свій шаблон Layla Chen.
- Не плутайте зчитування репозиторію із записом змін. Підключений репозиторій не означає автоматичної синхронізації. Краще упевнитися одразу, ніж шукати кнопку Commit пізніше.
- Перевіряйте продуктову логіку. Figma Make може пропонувати правила або обмеження, відсутні в реальному продукті, і це вимагає контролю.
GitHub Integration не робить Figma Make розумнішим самою по собі — вона лише постачає більше матеріалу для роботи. Результат залежить від того, наскільки чітко та ґрунтовно пояснено AI продукт, який стоїть за кодом.
Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.
