Найкращі промпти для дизайн-системи з Claude - це не «зроби мені дизайн-систему», а 15 вузьких задач під кожен етап: аудит (3), токени (4), компоненти і стани (3), документація (2), код (2) і підтримка (1). Кожен промпт має чотири частини: контекст (що за продукт і де лежать дані), задачу, формат відповіді і обмеження. Тоді Claude видає результат, який можна вставити у Figma чи в код, а не загальні поради.
Нижче - всі 15 промптів, готових до копіювання, з поясненням, де їх запускати: у звичайному чаті Claude, у Claude Code з доступом до файлів чи через Figma MCP. Це ті самі промпти, якими я, Dmytro Nikolaienko, збираю системи на проєктах UX Hero і на курсі «Дизайн-система з AI».
Чому промпт «зроби дизайн-систему» не працює?
Бо Claude не бачить ваш продукт. Без даних він видає середню по інтернету систему: синій primary, 8px-сітку і кнопку з трьома станами. Це виглядає як відповідь, але нічого не знає про ваші 47 відтінків сірого і три різні кнопки «Зберегти».
Робочий промпт = контекст + задача + формат + обмеження.
- Контекст: що за продукт, звідки дані (експорт змінних, CSS-файл, скриншот, Figma-файл через MCP).
- Задача: одна дія, а не «все одразу».
- Формат: таблиця, JSON, Markdown, код. Те, що ви вставите далі без переписування.
- Обмеження: що не чіпати, які назви використовувати, коли зупинитись і спитати.
Де запускати промпти: чат, Claude Code чи Figma MCP?
| Де | Коли підходить | Промпти |
|---|---|---|
| Чат Claude | вставляєте експорт, CSS або скриншот і отримуєте аналіз | 1, 2, 4, 5, 6, 9, 11 |
| Claude Code | треба читати і змінювати файли проєкту: токени, компоненти, сторі | 3, 7, 10, 12, 13, 14, 15 |
| Figma MCP | Claude читає змінні і компоненти прямо з Figma-файлу | 1, 3, 8 |
Якщо ще не працювали з MCP, почніть з чату: експорт змінних з Figma у JSON вже дає Claude достатньо контексту. Різницю підходів розбирали в матеріалі Claude у Figma: MCP чи скрипт через плагін.
Які промпти для аудиту дизайн-системи?
1. Інвентаризація кольорів
Ось експорт усіх кольорів з нашого Figma-файлу (HEX + де використовується).
Згрупуй їх у кластери візуально близьких відтінків (різниця менше ніж ~3% за яскравістю).
Формат: таблиця | кластер | відтінки | скільки разів трапляється | кандидат на токен |.
Не вигадуй нових кольорів, працюй тільки з тим, що є.
2. Дублі компонентів
Ось список компонентів і їхніх варіантів з нашої бібліотеки.
Знайди дублі: компоненти, які роблять одне й те саме під різними назвами або відрізняються лише 1-2 властивостями.
Для кожної групи: що лишити, що злити, які властивості стануть варіантами.
Формат: таблиця, відсортована від найбільшої кількості дублів.
3. Хардкод замість токенів (Claude Code)
Пройдись по src/components. Знайди всі місця, де кольори, відступи, радіуси чи тіні задані числами або HEX, а не через CSS-змінні з src/tokens.css.
Нічого не змінюй. Видай звіт: файл, рядок, значення, найближчий існуючий токен.
Окремо список значень, для яких токена немає.
Детальний план аудиту на день - у матеріалі аудит дизайн-системи за один день.
Які промпти для design tokens?
4. Primitive-палітра
На основі кластерів з аудиту побудуй primitive-палітру: для кожного кольору шкала 50-950 (11 кроків).
Базовий відтінок кожної шкали = найчастіший колір кластера, він має стати кроком 500 або 600.
Назви: color.{hue}.{step}. Формат: W3C DTCG JSON.
5. Semantic-шар
Ось primitive-токени. Запропонуй semantic-шар за ролями: bg, surface, text, border, action, feedback (success/warning/danger/info).
Кожен semantic-токен посилається на primitive, а не на HEX.
Для кожного: назва, значення, де використовувати, де НЕ використовувати. Не більше 40 токенів.
6. Темна тема з перевіркою контрасту
Згенеруй значення semantic-токенів для темного режиму з тих самих primitives.
Для кожної пари text/bg порахуй контраст за WCAG 2.2: звичайний текст ≥ 4.5:1, великий ≥ 3:1.
Пари, що не проходять, виділи окремо і запропонуй інший крок шкали.
7. Перейменування за конвенцією (Claude Code)
У tokens/ змінні названі хаотично. Приведи назви до схеми {category}.{role}.{variant}.{state}.
Спочатку покажи таблицю «стара назва → нова назва» і зупинись. Після мого ОК онови файли і всі посилання в src/.
Якщо плутаєте primitive, semantic і component - спершу прочитайте design tokens простими словами.
Які промпти для компонентів і станів?
8. Матриця станів (Figma MCP)
Прочитай компонент Button з цього Figma-файлу.
Склади матрицю: variant (primary/secondary/ghost/danger) × size (sm/md/lg) × state (default/hover/focus/active/disabled/loading).
Познач, яких комбінацій не вистачає у Figma, і які токени має використовувати кожна клітинка.
9. API компонента
Ось варіанти компонента Input у Figma. Спроєктуй його API для React: пропси, типи, значення за замовчуванням.
Правило: стан, який задає користувач (disabled, error), - це проп; стан, який задає браузер (hover, focus), - це CSS, не проп.
Формат: TypeScript-інтерфейс + коротке пояснення до кожного пропа.
10. Edge cases
Для компонента Card перелічи edge cases, які ламають верстку: довгий текст, відсутнє зображення, 0 і 999+ у лічильнику, RTL, збільшений шрифт 200%, порожній стан, помилка завантаження.
Для кожного: як має поводитись компонент і чи вистачає для цього поточних токенів.
Які промпти для документації?
11. Сторінка компонента
Напиши документацію для компонента Modal за шаблоном: призначення одним реченням, коли використовувати, коли НЕ використовувати (і що замість), анатомія, стани, доступність (фокус, Esc, aria), приклади тексту кнопок.
Тон: коротко, без води. Формат: Markdown.
12. Правила для AI-агентів (Claude Code)
Проаналізуй tokens/ і src/components/ і напиши AGENTS.md для цього репо:
які компоненти існують і коли їх брати, заборона хардкоду кольорів і відступів, схема назв токенів, де лежать сторі.
Не більше 80 рядків: агент має прочитати це за секунди.
Чому AGENTS.md важливий саме для дизайн-системи - у статті AGENTS.md для дизайн-системи.
Які промпти, щоб довести систему до коду?
13. Токени в CSS (Claude Code)
Візьми tokens/tokens.json (W3C DTCG) і згенеруй src/tokens.css: primitives у :root, semantic-токени як var() на primitives, темний режим через [data-theme="dark"].
Нічого не хардкодь. Додай npm-скрипт build:tokens, щоб перегенерувати файл після змін.
14. Компонент + Storybook (Claude Code)
За матрицею станів і API з попередніх кроків створи src/components/Button.tsx тільки на CSS-змінних з tokens.css.
Додай Button.stories.tsx: по одній сторі на кожен variant і окрему сторі «All states» з усією матрицею.
Запусти Storybook і перевір, що всі стани рендеряться.
Який промпт для підтримки системи?
15. Дрейф між Figma і кодом
Порівняй змінні з Figma (експорт у tokens/figma-export.json) з tokens/tokens.json у репо.
Покажи: токени, що є тільки в Figma; тільки в коді; з різними значеннями.
Для кожної розбіжності запропонуй, яке джерело правди, і чернетку запису в CHANGELOG.
Запускайте його раз на спринт, і система не роз'їдеться. Як я ганяю ці промпти наживо на реальних файлах, показую на YouTube-каналі UX Hero.
Як не зіпсувати систему промптами?
- Один промпт - одна задача. «Зроби аудит, токени і компоненти» дає поверхневе все.
- Спочатку звіт, потім зміни. У промптах 3, 7 і 15 Claude спершу показує план. Так ви ловите помилки до того, як він переписав 40 файлів.
- Давайте дані, а не опис. Експорт змінних краще за «у нас багато синіх».
- Фіксуйте результат у файлах. Вихід кожного кроку (кластери, токени, матриці) - вхід наступного.
- Рішення лишаються за вами. Claude пропонує 40 semantic-токенів, а ви вирішуєте, які з них потрібні продукту.
Тут і проходить різниця, на якій стоїть UX Hero. Згенерувати картинку інтерфейсу вміє будь-яка нейромережа. А провести систему від хаосу у Figma до токенів і компонентів у коді вміє дизайнер, який знає, що просити в Claude і як перевірити відповідь.
Часті питання
Які промпти найкорисніші для дизайн-системи з Claude?
Найбільше часу економлять три: інвентаризація кольорів (зводить десятки відтінків до кластерів), semantic-шар токенів з перевіркою контрасту для темної теми і матриця станів компонента. Разом вони знімають кілька днів ручної роботи на старті системи.
Чи потрібен Claude Code, чи вистачить звичайного чату?
Для аудиту, токенів і документації вистачить чату Claude: вставляєте експорт змінних або CSS і отримуєте результат. Claude Code потрібен, коли треба читати і змінювати файли проєкту: шукати хардкод, перейменовувати токени, генерувати CSS, компоненти і Storybook.
Чи можна дати Claude доступ прямо до Figma-файлу?
Так, через Figma MCP. Тоді Claude сам читає змінні, компоненти і їхні варіанти без ручного експорту. Для разових задач простіше експортувати змінні в JSON і вставити в чат.
Як писати промпт, щоб Claude не вигадував значення?
Давайте реальні дані (експорт, файл, скриншот) і прямо пишіть обмеження: «не вигадуй нових кольорів», «посилайся тільки на існуючі токени», «спочатку покажи план і зупинись». Формат відповіді (таблиця, JSON) теж зменшує фантазування.
Де навчитись збирати дизайн-систему з AI українською?
На курсі UX Hero «Дизайн-система з AI» від Dmytro Nikolaienko: 7 модулів від аудиту і Figma Variables до компонентів з 10 станами, документації і пайплайну до Storybook. Усі промпти з цієї статті там розібрані на живих файлах.
Промпти - це не магія, а спосіб розбити велику задачу на 15 маленьких і перевірних. Скопіюйте перші три, проженіть на своєму файлі сьогодні, і вже ввечері побачите, скільки в системі насправді хаосу.