Ще торік «зробити прототип у Figma» означало клікабельні екрани зі стрілочками між фреймами. У 2026 Figma Make змінив правила: ви описуєте ідею словами — і отримуєте не картинку, а робочий застосунок, який реально клікає, зберігає стан і працює на справжньому коді.

Це і захоплює, і плутає. Бо одразу постає питання: якщо AI пише код за мене, навіщо тоді розбиратися в коді? Розберемо, як Figma Make працює насправді, де його межа — і чому він не скасовує навичку Design Engineer, а робить її ще потрібнішою.

Що таке Figma Make і чим він відрізняється від звичайного прототипу

Figma Make — це вбудований у Figma інструмент типу «prompt-to-app»: ви описуєте, що має робити продукт, як він виглядає і які фічі потрібні, а Make генерує інтерактивний застосунок, який можна клікати, редагувати й ділитися.

Ключова різниця від класичного прототипу: під капотом не фрейми зі зв'язками, а справжній код — React і TypeScript зі стилями на Tailwind CSS. Тобто кнопка не просто «переводить на інший екран», а має стан, логіку й поведінку, яку можна розвивати далі. Figma тихо змістила роль дизайнера від «того, хто рухає пікселі» до чогось ближчого до режисера, який задає напрям, а не вимальовує кожну деталь руками.

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

Як це працює: від промпту до застосунку

Базовий цикл у Make займає хвилини, а не дні:

  1. Відкрийте файл у Figma, натисніть Cmd+K або кнопку в тулбарі.
  2. Опишіть застосунок звичайною мовою: що це, для кого, які екрани й дії.
  3. Make генерує робочий інтерфейс, який можна одразу клікати й тестувати.
  4. Уточнюйте результат наступними промптами — «додай темну тему», «зроби список фільтрованим», «винеси форму в модалку».

Найкраще Make працює, коли ви ставитеся до нього як до діалогу, а не як до автомата з однією кнопкою. Перший промпт задає скелет, а далі ви ліпите деталі ітераціями — рівно так, як робили б у реальному коді, тільки швидше. Гарний промпт описує не тільки вигляд, а й поведінку: які стани має екран, що відбувається при помилці, як виглядає порожній список.

Вибір AI-моделі: Claude, GPT чи Gemini

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

Універсальної відповіді немає, тому правило просте — не одружуйтеся на одній моделі. На складній логіці чи довгому проєкті спробуйте кілька й порівняйте результат на вашому кейсі: наскільки код читабельний, чи ламається інтерфейс після п'ятого уточнення, чи тримається дизайн-система. Живі порівняння різних AI-інструментів для дизайнерів ми регулярно показуємо на YouTube-каналі UX Hero.

Як тримати дизайн-систему під контролем

Головний ризик будь-якого prompt-to-app — «красиво, але не наше». AI охоче вигадує власні кольори, відступи й кнопки, які не мають нічого спільного з вашою дизайн-системою. Щоб цього уникнути, Make не варто використовувати ізольовано.

  • MCP-сервер. Через Model Context Protocol Make (і ваш редактор коду) читає контекст дизайну — фрейми, компоненти й змінні — тож генерація спирається на реальні токени, а не на вигадані значення. Детальніше — у гайді Figma MCP: дизайн у код за один промпт.
  • Code Connect. Він перетворює generic-розмітку на код із вашими компонентами, вашими шляхами імпорту й вашими інтерфейсами пропсів — щоб AI перевикористовував наявні патерни, а не плодив нові.
  • Змінні як джерело істини. Що чіткіша ваша структура токенів у Figma, то передбачуваніший код на виході. Хаос у змінних = хаос у згенерованому коді.

Іншими словами, Make дає максимум не тому, у кого найкращий промпт, а тому, у кого впорядкована дизайн-система під ним.

Де Figma Make сильний, а де ні

Чесна картина важливіша за хайп. Make чудово закриває одні задачі й погано — інші.

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

Слабкий бік: Make дає першу версію, а не готовий до продакшену продукт. Реальна бекенд-логіка, безпека, продуктивність на великих даних, крайові випадки, тести, доступність за WCAG — це все ще зона відповідальності людини. Що складніший продукт, то більше ручної роботи після генерації. Ставитися до виходу Make як до фінального коду — найшвидший спосіб принести технічний борг у проєкт.

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

Що робити з кодом далі

Ось точка, де prompt-to-app перестає бути іграшкою й стає частиною реального процесу. Make дозволяє експортувати код у GitHub-репозиторій або перенести дизайн у ваше середовище розробки через MCP — і саме тут вирішується, чи стане прототип продуктом.

Щоб довести застосунок до кінця, потрібно вміти:

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

Тобто Make не прибирає навичку Design Engineer — він робить її вигіднішою. Дизайнер, який зупиняється на «згенерував і не розумію», залежить від інструмента. Дизайнер, який володіє кодом, використовує Make як прискорювач і доводить справу до продакшену сам. Якщо хочете спокійно читати вихід Make й керувати ним, почніть з першого React-компонента з Figma — далі решта складається сама.

Figma Make не відповідає на питання «дизайнер чи розробник». Він робить актуальним інше питання — наскільки далеко ти можеш довести власну ідею сам. І чим краще ти розумієш код під капотом, тим далі ця межа.