Claude економить дизайнеру найдорожче — час на рутині. Нижче сім конкретних скриптів, які я щодня запускаю прямо у Figma через плагін, що виконує JavaScript: чистка невикористаних стилів, генерація всіх станів компонента, аудит спейсингів по 4-піксельній сітці, масове перейменування шарів, експорт токенів у JSON, перевірка контрасту за WCAG і генерація реалістичного контенту. Разом вони знімають приблизно годину ручної роботи на день — і, що важливіше, прибирають нудьгу, від якої псується увага до деталей.

Головна ідея не в тому, щоб «Claude усе зробив за вас». Ідея в тому, що більшість дизайнерської рутини — це послідовність однакових дій над сотнями шарів. А будь-яка послідовність однакових дій — це скрипт. Claude пише цей скрипт швидше, ніж ви клікнете третій шар вручну.

Що потрібно, щоб запускати скрипти у Figma?

Стек мінімальний. По-перше — акаунт Claude (Pro або Max), бо безкоштовний ліміт швидко закінчується. По-друге — плагін, який виконує довільний JavaScript через Figma Plugin API: найпопулярніший варіант — Code Runner, але підійде будь-який «console»-плагін. По-третє — звичка формулювати задачу як технічне завдання: що на вході, що на виході, які краєві випадки.

Робочий цикл завжди однаковий: описуєте задачу Claude → отримуєте код під Figma Plugin API → читаєте його очима → запускаєте на копії файлу. Останнє — не формальність. Скрипт, що перейменовує шари або видаляє стилі, працює миттєво й на всьому файлі одразу. Відкат через Ctrl+Z існує, але дешевше зробити дубль сторінки перед першим запуском.

Скрипт 1: чистка невикористаних стилів і змінних

За рік роботи над продуктом у файлі накопичується 200–300 стилів, з яких реально живуть 60. Решта — дублі кольорів, тіні «на спробувати» й текстові стилі з мертвих екранів. Скрипт проходить усі локальні стилі, звіряє з фактичним використанням на сторінках і повертає список кандидатів на видалення.

Промпт: «Напиши скрипт для Figma Plugin API, який збирає всі локальні paint- і text-стилі, перевіряє, чи вони застосовані хоч на одному вузлі документа, і виводить у консоль список невикористаних із їхніми id. Нічого не видаляй — тільки звіт.»

Ключове слово — «тільки звіт». Спершу дивитесь список, і лише потім окремим запуском видаляєте. Автовидалення без перегляду — найшвидший спосіб знести стиль, який використовувався в одному прихованому компоненті.

Скрипт 2: генерація всіх станів компонента

Ви намалювали default-стан кнопки. Далі треба hover, focus, active, disabled і loading — і так для кожного розміру. Це п'ять–шість майже однакових копій, де змінюється прозорість, заливка або бордер. Claude генерує скрипт, що бере обраний фрейм, клонує його потрібну кількість разів, розкладає в ряд і застосовує до кожної копії описані модифікації.

У продуктовій дизайн-системі це економить не хвилини, а години на місяць: стани — найнудніша й найпомилковіша частина роботи над компонентом, бо руками легко забути про focus або переплутати disabled з активним.

Скрипт 3: аудит спейсингів по сітці 4px

Найтихіший борг у макеті — відступи, що випадають із сітки: 6, 10, 15, 22 замість 4, 8, 16, 24. Око їх не ловить, а розробник ловить одразу й ставить питання. Скрипт обходить вибрані фрейми, читає padding та item spacing в Auto Layout і підсвічує все, що не ділиться на 4 (або на вашу базову одиницю).

Промпт: «Пройди по вибраних вузлах з Auto Layout, збери paddingLeft/Right/Top/Bottom та itemSpacing. Виведи вузли, де хоча б одне значення не кратне 4, у форматі: ім'я вузла → проблемні значення.»

Скрипт 4: масове перейменування та впорядкування шарів

«Frame 1274», «Group 88», «Rectangle 5» — класика імпортованого чи наспіх зібраного файлу. Перед хендофом це треба привести до ладу, бо назви шарів стають назвами класів і змінних у коді. Скрипт перейменовує за правилом (наприклад, за роллю вузла й типом контенту), прибирає порожні групи й розкладає елементи в передбачуваному порядку.

Тут Claude корисний не лише кодом, а й логікою неймінгу: попросіть запропонувати конвенцію імен під ваш стек — і потім згенерувати скрипт, що її застосує.

Скрипт 5: експорт токенів у JSON (W3C DTCG)

Якщо ви ведете токени у Figma Variables, рано чи пізно їх треба віддати в код. Скрипт читає колекції змінних, розкладає їх за режимами (light/dark) і формує JSON у форматі, близькому до стандарту W3C DTCG — з $value та $type. Далі цей файл підхоплює Style Dictionary й генерує CSS-змінні, iOS- та Android-ресурси.

Це і є та точка, де дизайнер перестає бути «людиною, що малює», і стає ланкою в автоматизованому пайплайні. Як зібрати такий пайплайн цілком — я розкладав в окремому матеріалі про AI DesignOps.

Скрипт 6: перевірка контрасту за WCAG

Контраст тексту — вимога, яку зручно перекласти на машину. Скрипт бере текстові вузли, визначає колір тексту й колір фону під ним, рахує коефіцієнт контрасту й позначає все, що не дотягує до 4.5:1 для звичайного тексту або 3:1 для великого. На виході — список екранів, які завалять аудит доступності ще до того, як його хтось замовить.

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

Скрипт 7: генерація реалістичного контенту

«Lorem ipsum» і «John Doe» брешуть про макет. Реальні дані іншої довжини: українські прізвища довші за англійські, суми в гривнях мають інший формат, дати — свій. Скрипт проходить текстові шари з певними іменами (наприклад, усе, що названо amount, name, date) і підставляє правдоподібні значення, які Claude генерує під ваш контекст — банк, маркетплейс, крипто-гаманець.

Побічний ефект — ви одразу бачите, як ламається верстка на довгому імені чи великій сумі. Це та перевірка на міцність, яку інакше робить уже розробник — і повертає макет назад.

Як писати власні скрипти: промпт-патерн

Сім скриптів вище — не межа, а приклади одного підходу. Щоб згенерувати свій, тримайте структуру промпта постійною:

  • Контекст: «Це скрипт для Figma Plugin API, виконується через Code Runner.»
  • Вхід: що обрано або що читати (виділення, сторінка, весь документ).
  • Дія: що зробити з кожним вузлом.
  • Вихід: звіт у консоль чи зміни в макеті — і чітко, що саме.
  • Обмеження: «Нічого не видаляй», «не чіпай приховані шари», «працюй лише з виділенням».

Що конкретніший вхід і вихід, то менше правок після першого запуску. Живий розбір того, як я збираю такі скрипти на реальному файлі, є на моєму YouTube-каналі — там видно і промпти, і помилки, і як їх ловити.

Скільки часу це реально економить?

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

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

Чого не варто автоматизувати?

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

Почніть з одного скрипта — чистки стилів. Він дає результат уже сьогодні й показує сам принцип: рутина — це код, а код можна попросити написати. Далі апетит приходить швидко.