Щоб зібрати дизайн-систему з AI, потрібні чотири кроки в такому порядку: аудит того, що вже є, токени у три рівні (primitives → semantic → component), компоненти з усіма станами і вивід у код через Storybook. AI закриває механічну частину кожного кроку - перейменування, генерацію станів, документацію і чернетку коду. Архітектуру ухвалюєте ви. Для продукту на 20-30 екранів це 5-7 робочих днів, а не три місяці.
Далі - що саме робити на кожному кроці, який стек склався до 2026 року і де AI справді економить час, а де тільки створює гарне сміття.
Чим дизайн-система відрізняється від UI-кіта?
Найпростіший тест: змініть один токен кольору і подивіться, що сталося з продуктом. Якщо нічого - у вас UI-кіт.
Дизайн-система складається з п'яти шарів, і намальовані компоненти - лише один із них:
- Токени - числа і кольори, вирвані з макета в окрему систему значень
- Компоненти - зі станами, варіантами і чітким API пропсів
- Патерни - як з компонентів складають типові екрани
- Документація - коли і чому використовувати цей компонент, а не сусідній
- Код - те, що реально потрапляє у продукт
Більшість «дизайн-систем» у Figma не мають шарів 3-5. Саме тому вони живуть місяць після презентації, а потім продукт знову їде у різнобій. І саме тут AI змінює економіку: раніше ці три шари не робили, бо не було рук. Тепер вони роблять за дні.
Який стек потрібен у 2026?
До 2026 року набір інструментів нарешті влаштувався. Ось мінімальний робочий стек і роль кожного елемента:
| Шар | Інструмент | Що закриває |
|---|---|---|
| Токени в дизайні | Figma Variables | значення, режими (light/dark), зв'язок з компонентами |
| Обмінний формат | W3C Design Tokens (DTCG) | щоб токени не були заручником одного інструмента |
| Збірка | Style Dictionary | перетворює токени у CSS-змінні, Tailwind-конфіг, JSON |
| Жива документація | Storybook | компонент у браузері з усіма станами |
| Доступ для AI | Figma MCP | агент читає справжні дані компонентів, а не скріншот |
Ключова зміна саме 2026 року - MCP. До нього AI дивився на дизайн як на картинку і вгадував відступи. Через MCP-сервер агент отримує структуру: назви змінних, значення, ієрархію компонентів. Різниця між «приблизно 16 пікселів» і spacing.md - це різниця між сміттям і робочим кодом.
Крок 1. Як зробити аудит того, що вже є?
Не починайте з чистого файлу. Спочатку порахуйте масштаб безладу - це дає і план, і аргументи для команди.
- Витягніть усі кольори з макета і порахуйте унікальні значення. Типова цифра для продукту без системи - 40-80 відтінків там, де потрібно 12-16.
- Те саме зі відступами. Якщо серед них є 13, 15, 17 і 18 пікселів, у вас немає шкали.
- Порахуйте дублікати компонентів: скільки різних кнопок, скільки інпутів, скільки карток.
- Позначте, які компоненти взагалі використовуються на живих екранах. Половину зазвичай можна видалити.
Тут AI корисний одразу: попросіть агента зібрати всі значення у таблицю і згрупувати схожі. Людина робить це пів дня, агент - за кілька хвилин. Рішення, які з 60 відтінків стають вашими 14, лишається за вами.
Крок 2. Як побудувати токени у три рівні?
Три рівні - не бюрократія, а єдиний спосіб зробити тему темною без переписування всього файлу:
- Primitives - сира палітра без сенсу:
blue.500,gray.900,space.4. Тут немає слова «кнопка». - Semantic - роль у продукті:
color.bg.surface,color.text.muted,color.border.danger. Цей рівень посилається на primitives і саме він перемикається між light і dark. - Component - значення конкретного компонента:
button.primary.bg, яке посилається на semantic.
Найчастіша помилка - почати з семантики, бо «так швидше». Через тиждень виявляється, що color.text.primary у різних місцях означає різне, і систему доводиться розбирати. Ми детально розбирали цю пастку в окремому матеріалі про примітиви проти семантики.
Роль AI на цьому кроці - масова механіка: перейменувати сотні змінних за схемою, знайти значення, які випали з шкали, і скласти таблицю відповідностей старих кольорів новим токенам.
Крок 3. Що саме тут робить AI?
Найчесніший спосіб пояснити - розділити роботу на дві колонки:
| AI робить добре | Лишається за дизайнером |
|---|---|
| масове перейменування шарів і змінних | схема назв і рівні токенів |
| генерація відсутніх станів компонента | рішення, які стани продукту потрібні |
| чернетка документації по кожному компоненту | правила, коли компонент не використовувати |
| переклад токенів у CSS, Tailwind, JSON | перевірка, що код збігається з дизайном |
| пошук хардкоду і відв'язаних значень | що з цього справді треба виправляти |
Практичний висновок: агент не заміняє дизайн-системного дизайнера, він знімає з нього рутину, через яку системи зазвичай не доходять до кінця. Правила для агента варто закріпити у файлі інструкцій проєкту - як це зробити, ми показували в матеріалі про AGENTS.md для дизайн-системи. Без нього агент щоразу вигадує власну схему назв.
Крок 4. Як довести систему до коду?
Система без коду - це презентація. Мінімальний шлях до живої системи:
- Експортуйте Figma Variables у DTCG-форматі.
- Проженіть їх через Style Dictionary і отримайте CSS-змінні або Tailwind-конфіг.
- Зберіть 5-7 базових компонентів у Storybook: button, input, select, card, modal, badge, table.
- Підключіть Figma MCP, щоб агент писав компоненти зі справжніх даних макета.
- Кожен компонент рев'юйте руками: стани, фокус, клавіатура, довгий текст, темна тема.
П'ятий пункт не пропускається. Агент постійно забуває стан :focus-visible і ламається на тексті у три рядки. Живі приклади такого пайплайну я розбираю у відео на YouTube-канал UX Hero.
Скільки часу це насправді займає?
Реалістичний розподіл для продукту з 20-30 екранами, у режимі кількох годин на день:
| Етап | Час | Результат |
|---|---|---|
| Аудит | 1 день | список значень, дублікатів і плану |
| Токени | 1 день | три рівні змінних, light і dark |
| Компоненти | 2-3 дні | 5-7 базових компонентів зі станами |
| Код і документація | 1 день | Storybook і токени у CSS |
| Разом | 5-7 днів | система, з якою можна працювати |
Без AI ті самі кроки займають 4-8 тижнів, і зазвичай зупиняються на етапі документації. Скорочується не кількість рішень, а механіка між ними.
Які помилки з'їдають найбільше часу?
- Почати з компонентів, а не з токенів. Тоді кожен компонент доводиться переробляти двічі.
- Пропустити семантичний рівень. Темна тема перетворюється на ручну працю по всьому файлу.
- Дати агенту велику задачу. «Зроби мені дизайн-систему» дає охайне сміття. «Додай стани hover, focus, disabled до цього button і прив'яжи до токенів» дає результат.
- Не рев'ювати код. Хардкод у згенерованих компонентах з'являється майже завжди, і знаходити його через місяць дорожче.
- Робити систему для всього продукту одразу. Візьміть один потік, доведіть його до кінця, потім розширюйте.
Часті питання
Скільки часу займає зібрати дизайн-систему з AI?
Для продукту з 20-30 екранами реально закласти 5-7 робочих днів на базову систему: день на аудит, день на токени, два-три дні на компоненти зі станами, день на код і документацію. AI не скорочує кількість рішень, які треба ухвалити, він скорочує механічну частину: перейменування шарів, генерацію станів, опис компонентів і чернетку коду.
Чим дизайн-система відрізняється від UI-кіта?
UI-кіт - це набір намальованих компонентів у Figma. Дизайн-система - це набір правил плюс токени, компоненти зі станами, документація і код, який реально використовують у продукті. Простий тест: якщо змінити один токен і колір не поїхав по всьому продукту, у вас UI-кіт, а не система.
Чи може AI сам зробити дизайн-систему?
Ні. AI добре робить механічну роботу: масово перейменовує шари, генерує відсутні стани компонентів, пише документацію і перекладає токени у код. Але архітектуру токенів, семантику назв і рішення про те, які компоненти взагалі потрібні продукту, ухвалює дизайнер. Агент без цих рішень згенерує охайний за формою, але безсистемний набір.
Який стек потрібен для дизайн-системи з AI у 2026?
Мінімальний робочий стек: Figma Variables для токенів, формат W3C Design Tokens (DTCG) як обмінний, Style Dictionary для збірки у CSS або Tailwind, Storybook як живу документацію і Figma MCP, щоб AI-агент читав справжні дані компонентів, а не вгадував їх зі скріншота.
Де навчитись збирати дизайн-систему з AI українською?
У UX Hero є курс «Дизайн-система з AI» від Dmytro Nikolaienko: 7 модулів за 7 днів - фундамент і аудит, Figma Variables від primitives до component, компоненти з 10 станами, автоматизація рутини через Claude, генерація артефактів і документації, пайплайн Figma to Storybook і фінальна збірка системи, готової до продакшну.
Дизайн-система з AI - це не новий інструмент, а стара дисципліна, з якої нарешті прибрали найнуднішу частину. Порядок кроків не змінився: спочатку токени, потім компоненти, потім код. Просто тепер між кроками не треба тиждень ручної роботи.