💡 Усі статті, обговорення та новини про штучний інтелект тепер зібрані в одному місці. Запрошуємо приєднатися до AI-спільноти!
Мене звати Олена Івлєва. Я UX/UI дизайнерка, UX Engineer і фронтенд-розробниця в компанії Kavita Systems, маю більш ніж 15 років досвіду в професії.
Протягом останнього року я помітила цікаву і разом із тим тривожну тенденцію: розробники почали випереджати дизайнерів. Не через те, що вони раптово стали кращими спеціалістами, а через те, що залучили агентів і почали рухатися в звичному темпі, але значно швидше. Тим часом більшість дизайнерів і надалі працювали вручну в Figma.
Деякий час тому агенти вже могли «читати» макети у Figma і на цій основі допомагати з фронтендом. Figma MCP server передає агенту структурований контекст із вибраних елементів: фрейми, компоненти, layout, variables та інші дані, надалі AI-асистент генерує код відповідно до вашого стеку технологій.
Саме в цей період я вперше побачила суттєвий дисбаланс: розробка стрімко прискорилася, а дизайн — ні. Розробники вже активно взаємодіяли з агентами, тоді як дизайнери здебільшого залишалися у традиційному ручному режимі в Canvas. Тож новина про те, що Figma відкриває Canvas для агентів, для мене — не просто чергова AI-фіча, а сигнал кардинальної трансформації самої логіки професії. Figma безпосередньо описує цей крок як можливість агентам працювати прямо на Canvas, використовуючи дизайн-системи, файли і «skills», які визначають правила та контекст роботи.
Неприємна реальність, яку я спостерігала у проєктах
У більшості команд між ідеєю та реалізацією завжди існував «міжетап перекладу». Дизайнер формує концепцію, розробляє UX, пропрацьовує структуру. Проте на етапі розробки частина рішень спрощується, інша змінюється, а дещо зовсім зникає. Причина не в неякісній роботі — а в тому, що між Figma та кодом постійно був розрив. Цей розрив обходився бізнесу дорого: втраченим часом, збільшеними витратами і зниженням якості.
Особисто я багато разів стикалась із такими викликами. Саме тому, почавши працювати не тільки у Figma, а й безпосередньо на фронтенді — у Storybook, із дизайн-системами і токенами — моє сприйняття дизайну змінилося. Тепер ти вже не просто «малюєш сторінки», а проектуєш середовище, яке повинно жити і витримувати реальні виклики розробки.
Агенти в Canvas — це не про те, що «AI тепер малює замість нас». Це про те, що дизайн перестає бути лише візуальним артефактом і перетворюється на систему, з якою можуть працювати інтелектуальні інструменти безпосередньо у середовищі створення інтерфейсу. Figma MCP вже не тільки зчитує контекст, а й записує у Canvas: створює фрейми, компоненти, variables і auto layout нативно всередині Figma.
Раніше були шаблони, тепер змінюється сама механіка роботи
Раніше існували готові шаблони, конструктори, UI kits, бібліотеки форм, карток, ілюстрацій та секцій. Замовник міг самостійно «зібрати щось», а дизайнер використовував основу і адаптував її.
Зараз ми рухаємося від моделі «знайти готове» до моделі «описати вимоги і згенерувати нове». Це принципово інша річ.
Якщо раніше завдання дизайнера часто звучало як: знайти референс, адаптувати шаблон, зібрати екран, то тепер дедалі частіше необхідно:
- Сформулювати промпт;
- Описати структуру;
- Надати агенту правила, обмеження й контекст;
- Отримати варіант, максимально відповідний до системи продукту.
Отже, AI не спрощує професію до рівня «натиснув кнопку — отримав дизайн». Навпаки — він підвищує цінність тих, хто вміє формулювати систему грамотно, а не просто підбирати гарні зображення.
Що фактично змінюється
Якщо раніше розробка могла чекати дизайн, то зараз, коли агенти прискорюють процеси нерівномірно, відсутність адаптації означає відставання. Важливо не лише малювати швидше, а мислити системно, а не обмежуватися лише екранами.
Коли агенти працюють із компонентами, variables, auto layout і правилами, вони функціонують не на рівні «красивого мокапу», а в площині архітектури інтерфейсу. Тому Figma рекомендує структурувати файли, створювати ефективні промпти та додавати кастомні правила, щоб агент виконував роботу стабільніше і точніше.
Як реалізувати це на практиці
Найцікавіший момент — не в абстрактних обговореннях ШІ, а у практичних кроках підготовки команди до нової системи роботи.
1. Організуйте Figma-файл як систему, а не набір екранів
Агенти важко працюють із хаотичними файлами. Якщо у вашому файлі:
- відсутні назви фреймів;
- є дублікати кнопок у різних місцях;
- локальні стилі не мають логіки;
- немає variables;
- відсутні component set або чіткі варіанти станів,
результат буде посереднім.
Передусім слід упорядкувати файл системно:
- назвати сторінки за призначенням;
- чітко виділити foundation, components, patterns, screens;
- перевести кольори, відступи, типографіку в variables/tokens;
- зібрати базові компоненти і стани;
- застосувати Auto Layout там, де це дійсно має сенс.
Чітка структура мінімізує здогадки агентів.
2. Увімкніть Figma MCP
Існує два основних способи підключення: через desktop MCP server або remote server. Для десктопного варіанту потрібно оновити застосунок, відкрити файл Figma, перейти в Dev Mode і активувати desktop MCP server в inspect panel. Remote server є рекомендованим основним варіантом для підтримуваних MCP-клієнтів.
На практиці це означає, що агент у Cursor, Claude Code чи іншому MCP-сумісному середовищі отримує доступ до структури Figma-файлу, а не лише до скріншота.
3. Впровадьте правила, без яких агент не може працювати
Одна з ключових ідей нової підходу — не просто надати агенту доступ, а встановити для нього чіткі правила.
Наприклад:
- Використовуй тільки компоненти з бібліотеки дизайн-системи;
- Не створюй нові стилі кнопок без необхідності;
- Усі нові card patterns мають підтримувати desktop, tablet і mobile;
- Використовуй spacing виключно за 8pt scale;
- Текстові стилі — лише через variables;
- Для таблиць застосовуй готовий table wrapper;
- Не генеруй декоративні елементи поза межами брендованих правил.
Figma рекомендує додавати кастомні правила та інструкції для забезпечення стабільнішого і послідовнішого результату.
4. Починайте не з розмитого запиту на екран, а з вузьких сценаріїв
Найгірше — це давати агента загальний і нечіткий запит, наприклад:
«Створи сучасний dashboard для SaaS.»
Краще — подавати структуровані і чіткі запити, наприклад:
«Створи новий екран Billing Overview для B2B SaaS у поточній дизайн-системі. Використовуй існуючі header, tabs, cards, table, badge і button components. Додай три стани: normal, empty, error. Підтримай desktop first. Не створюй нових кольорів або типографічних стилів. Усі відступи — тільки зі spacing variables.»
Такий підхід значно зменшує хаос у процесі.
5. Використовуйте двосторонній workflow з агентом
Однією з унікальних можливостей Figma MCP є не лише write to canvas, а й code to canvas. Figma описує модель кругового циклу: UI можна імпортувати з коду у Canvas для рев’ю, порівняння, коригування та подальшої імплементації в код.
Практичний процес виглядає так:
- Дизайнер або агент створює структуру у Canvas;
- Команда узгоджує напрям;
- Розробник швидко збирає робочу версію;
- UI повертається у Canvas;
- Далі відбувається не повторне перемальовування, а уточнення системи.
Це не класичний handoff, а набагато тісніша інтеграція у спільне продуктове середовище.
Практичні сценарії застосування
Сценарій 1. Швидкий старт нового модуля
Маєте дизайн-систему і треба оперативно створити новий back-office екран із списком користувачів, фільтрами, станами, таблицею, empty state. Раніше дизайнер виконував цю роботу вручну майже з нуля. Тепер агент може здійснити 70–80% структурної роботи, а дизайнер сконцентрується на UX, логіці і контролі якості.
Сценарій 2. Масштабування існуючого продукту
Якщо в продукті вже 20–30 схожих екранів, агент допомагає не «намалювати новий екран», а послідовно розвивати наявну систему: додавати стани, адаптації, варіанти для різних ролей чи нових об’єктів.
Сценарій 3. Синхронізація дизайну та фронтенду
Якщо команда вже працює із Storybook, tokens та компонентно-орієнтованим підходом, агент стає містком між різними середовищами. Не ідеальним, але надзвичайно ефективним, особливо у випадках численного дублювання рішень.
Що це означає для ролі дизайнера
Фахівці не будуть замінені агентами, проте роль дизайнера стає більш вимогливою.
Раніше можна було тривалий час працювати в моделі «відповідаю за візуальне». Гарна типографіка, акуратний UI, чітка презентація — і цього часто було достатньо для визнання як професіонала. Тепер цього недостатньо.
Цінність зміщується від статичних макетів до системного мислення. Набувають значення інформаційна архітектура, логіка компонентів, взаємозв’язок дизайну з фронтендом, масштабованість рішень. Гарний дизайнер має хоча б базово розуміти, як поводяться компоненти, що таке стани, чому рішення можуть «ламатися» у продакшені і чому красивий макет не обов’язково добре масштабується у реальному продукті.
AI у дизайні радше підкреслює прогалини у підходах, ніж замінює спеціалістів. Він наочно демонструє, де людина працювала саме з системою, а де лише поверхнею.
Що отримує бізнес
Будь-який бізнес платить за розрив між дизайном та реалізацією — через затримки, переробки, ускладнену комунікацію, розбіжність між задумом і кінцевим продуктом. Якщо цей розрив зменшується, виграють усі: гіпотези перевіряються швидше, втрата інформації на handoff зменшується, інтерфейси стають більш послідовними.
Справжня цінність змін полягає не в тому, що «AI малює швидше», а в тому, що дизайн перестає бути окремою фазою і стає частиною продуктового інжинірингу. Межа між дизайном і фронтендом починає розмиватися — дизайнер, що усвідомлює це, отримує професійну перевагу: менше непорозумінь із розробниками, менше зайвих ітерацій, зміцнення спільної мови та довіри в команді.
Ця трансформація означає початок нової ери, де дизайн вже не є суто візуальною дисципліною — він перетворюється на інфраструктуру продукту.
Головне питання полягає не в тому, чи змінить AI дизайн, а в тому, чи здатні ми змінюватися разом із ним.
