Від «намалювати макет» до системного мислення: що насправді змінює відкриття Figma Canvas для агентів

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до 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 радить структурувати файли, писати ефективні промпти й додавати кастомні правила, щоб агент працював стабільніше та точніше.

Як це можна налаштувати на практиці

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

1. Підготуйте Figma-файл як систему, а не як набір екранів

Агенту складно працювати з хаотичним файлом. Якщо у вас:

• безіменні фрейми;
• дублікати кнопок у різних місцях;
• локальні стилі без логіки;
• відсутні variables;
• немає component set або чітких variant states,

то результат буде слабким.

Перший крок — привести файл до системного вигляду:

• назвати сторінки за призначенням;
• виділити окремо foundation, components, patterns, screens;
• перевести кольори, відступи, типографіку в variables/tokens;
• зібрати базові компоненти й стани;
• використовувати Auto Layout там, де це справді має сенс.

Чим краща структура — тим менше агент «вгадує».

2. Увімкніть Figma MCP

Figma описує два базові способи підключення: через desktop MCP server або через remote server. Для desktop-варіанту потрібно оновити десктопний застосунок, відкрити Figma Design file, перейти в Dev Mode й увімкнути desktop MCP server в inspect panel. Remote server Figma рекомендує як основний варіант для підтримуваних MCP-клієнтів.

На практиці це означає: ваш агент у Cursor, Claude Code чи іншому MCP-сумісному середовищі отримує доступ до структури Figma-файлу, а не лише до скриншота.

3. Додайте правила, без яких агент не повинен працювати

Одна з найсильніших ідей у новому підході — не просто «дати агенту доступ», а дати йому правила.

Наприклад:

• використовуй лише компоненти з бібліотеки Design System;
• не створюй нових button styles без потреби;
• усі нові card patterns мають підтримувати desktop/tablet/mobile;
• spacing — тільки через 8pt scale;
• текстові стилі — лише через variables;
• для таблиць використовуй готовий table wrapper;
• не генеруй декоративні елементи поза брендовими правилами.

Figma прямо рекомендує додавати custom rules and instructions, щоб отримувати стабільніший і більш послідовний результат.

4. Починайте не з «намалюй мені екран», а з вузьких сценаріїв

Найгірший сценарій — дати агенту розмитий запит на кшталт:

«Створи сучасний dashboard для SaaS.»

Найкращий — давати вузький, структурований запит.

Наприклад:

Створи новий екран Billing Overview для B2B SaaS у поточній дизайн-системі.
Використовуй існуючі header, tabs, cards, table, badge і button components.
Додай 3 стани: normal, empty, error.
Підтримай desktop first.
Не створюй нових кольорів або типографічних стилів.
Усі відступи — тільки зі spacing variables.

Такий підхід різко зменшує хаос.

5. Використовуйте agent workflow у дві сторони

Один із найцікавіших моментів у Figma MCP — це не лише write to canvas, а й code to canvas. Figma описує roundtrip-модель: UI можна захопити з коду й повернути у Canvas для рев’ю, порівняння, уточнення й подальшої імплементації назад у код.

На практиці це дає дуже сильний процес:

• дизайнер або агент створює структуру в Canvas;
• команда погоджує напрям;
• розробник швидко збирає working version;
• UI повертається в Canvas;
• далі відбувається не повторне перемальовування, а уточнення системи.

Це вже не класичний handoff. Це набагато ближче до спільного продуктового середовища.

Конкретні сценарії, де це реально корисно

Сценарій 1. Швидкий старт нового модуля

У вас є дизайн-система і треба швидко зібрати новий back-office екран: список користувачів, фільтри, стани, таблиця, empty state. Раніше дизайнер робив це майже з нуля руками. Тепер агент може створити 70–80% структурної роботи, а дизайнер сфокусується на UX, логіці й перевірці якості.

Сценарій 2. Масштабування існуючого продукту

Коли в продукті вже 20–30 схожих екранів, агент може допомогти не «намалювати нове», а послідовно розширювати наявну систему: додати нові стани, зібрати адаптації, створити варіанти для ролей або нових сутностей.

Сценарій 3. Синхронізація дизайну й фронтенду

Якщо команда вже працює зі Storybook, tokens і component-driven підходом, агент стає містком між двома середовищами. Не ідеальним, але дуже корисним. Особливо там, де раніше було багато ручного дублювання рішень.

Що це означає для ролі дизайнера

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

Раніше можна було довго залишатися в моделі «я відповідаю за візуал». Добре підібрана типографіка, акуратний UI, зрозуміла презентація — і цього часто вистачало, щоб вважатися сильним спеціалістом. Сьогодні цього вже замало.

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

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

Що виграє бізнес

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

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

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

І головне питання зараз не в тому, чи змінить AI дизайн.

А в тому: чи готові ми змінитися разом із ним.