Ветров сделал подборку статей про подготовку дизайн-систем к работе с ИИ.

Часть статей прочитал сам, часть отправил в Claude, чтобы он сделал скрининг и дал краткое резюме, сразу приложив идеи к моим текущим наработкам. Век ИИ, нужно ускоряться.

Что интересного нашел для себя.

Статья Your next design system user is an agent — Murphy предлагает:
• документировать пропсы как параметры API — с типами, дефолтами и ограничениями
• описывать связи между компонентами и правила их вложенности.

Да, в статье много говорится про код. Но ничто не мешает описывать внутри каждого компонента правила по единой структуре (разумеется, не вручную).

Пример на обычной ячейке:

Placement: standalone

Description: A horizontal list row with three slot regions (Leading, Middle, Trailing) and an optional chevron. The middle region is flexible; leading and trailing slots hold swappable content.

Parts:
Leading Slot (optional, Has Leading Slot) ·
Middle Slot (required) ·
Trailing Slot (optional, Has Trailing Slot) ·
Chevron (optional, Has Chevron)

Accepts / Leading Slot: Icon, Avatar, Counter, Free Slot
Accepts / Middle Slot: Text 2 Lines, Text 1 Line
Accepts / Trailing Slot: Icon 24, Avatar, Counter, Free Slot

Такой подход должен помочь AI-агентам (в том числе Figma Agent) не просто находить нужный компонент, а понимать его ограничения: какие вложенные элементы допустимы, какие обязательны и в каком контексте компонент вообще можно использовать.

Хочу протестировать эту идею. Сейчас активно работаю над тем, чтобы компоненты были AI-readable: собираю единые правила, описываю структуру, связи и поведение компонентов. Цель — в будущем собрать skill, который сможет не только ревьюить дизайн, но и автоматически собирать интерфейсы.

Интересно, кто-то уже экспериментирует с подобным подходом?

В недавнем большом апдейте Figma показала Generative Plugins. По сути, их встроенный агент позволяет писать плагины прямо в Figma. Мне тут как раз нужно было мигрировать одну версию кнопки на другую — с другими слоями, полями и т. д., чего не сделаешь просто через Swap Instance.

Решил потестить, как агент с этим справится. В итоге собрался небольшой плагин, который находит все устаревшие кнопки на странице и переносит все данные в новую версию с сохранением нужных оверрайдов. Считаю, штука может быть полезной, учитывая, как мало времени на неё было потрачено и как быстро она позволяет пройтись по всем макетам, заменив деприкейт компонент на актуальный.

Единственное, что я пока не понял, — можно ли такой AI-плагин раскатать на других дизайнеров.

P.S. В первой версии плагина по моему запросу «найди все старые кнопки» он в фоновом режиме постоянно запускал поиск и тем самым забивал всю память. Figma просто умирала на глазах. Поэтому лучше сразу сказать агенту, чтобы он добавил кнопку для ручного запуска поиска нужного компонента.

P.P.S. Чтобы агент понял, что от него требуется, лучше дать ему несколько примеров старых и новых компонентов в разных вариациях, а также сгруппировать их. Тогда он лучше понимает, как работать и с модами, и с оверрайдами, слоями и свойствами.

Компонентные токены, страшно или полезно?

Раньше всегда избегал компонентных токенов и в целом, считал что если они есть, значит семантический слой собран слабо, если говорить про цвета. Как же я ошибался.

Да, количество токенов растет, и, кажется, что поддерживать такую систему сложно. Но в этом есть и свои плюсы.

Используя компонентный уровень можно переназначить токены внутри вложенного компонента. И вот это реально бывает полезно.

Например, примитивный counter может быть в брендовом цвете. Но это в обычном контексте. При использовании в кнопке контекст уже задает она. На светлой кнопке брендовый counter, а вот на темной — светлый. В Figma такое переключение можно сделать только через варианты каунтера и кнопки, что убивает всю идею модов для переключения appearance кнопки. А если кнопка в disabled состоянии, counter тоже должен уметь в логику disabled? Нет, не обязательно.

Но можно использовать компонентные токены, чтобы переназначить цвета counter. Этот механизм называется Nested component tokens — когда родитель управляет цветом или любыми другими параметрами вложенных компонентов. В Figma это открывает возможность поддержки модов для управления Appearance не только кнопки, но и вложенных компонентов.

Единственное требование, это стандартизированный контракт для таких компонентов, чтобы родитель предоставлял такие же параметры, что использует дочерний элемент.

В один пост запихнуть все сложно, поэтому попозже сделаю отдельный с примерами. Пока это все в рамках моего тестирования, но выглядит многообещающе и уже решает мои задачи: не раздувать семантический слой токенов и не множить варианты в компонентах. Управление контекстом только через Appearance, а не варианты.

Только нужная инфа

Искать новые статьи по своей теме стало в 1000 раз проще.

Недавно в ChatGPT завезли запланированные задачи. Он уже давно в контексте моих наработок, задач и подходов. Попросил его раз в неделю делать краткий дайджест по нужным мне темам, которые актуальны для меня именно в текущий момент, и пару новеньких, чтобы быть в тренде.

Он делает короткую сводку (5-7 статей), раскрывает чем полезна статья, как может мне помочь сейчас, куда смотрит рынок в целом. Ну я в шоке конечно… приятном)

Расстановка документации — убиваем рутину

Всю документацию для компонентов я храню рядом с самими компонентами. Каждый раздел (сам компонент, Demo, Specification, Change log) в отдельном фрейме. И, конечно, все эти фреймы хочется содержать в порядке: с конкретной структурой, очередностью, отступами, настройками и так далее. К тому же на одной странице в Figma может быть несколько компонентов. И у каждого свои спеки с разными высотами фреймов.

Buttons
├── Button
│   ├── Button
│   ├── Demo
│   ├── Specification
│   └── Change log
│
└── Button Icon
    ├── Button Icon
    ├── Demo
    ├── Specification
    └── Change log

Чтобы не двигать фреймы на странице вручную, а делать это всё равно приходится каждый раз, когда нужно что-то добавить в спецификацию или поправить текст, я попросил агента в Figma написать простой плагин, который автоматически расставляет всё по своим местам с нужными отступами.

На фреймы сразу прокидываются все нужные параметры — фон, скругления, отступы.

Расстановка фреймов это рутина, которая занимает время, а бизнесу это совсем не нужно. Но лично мне хочется держать документацию в чистоте и единой структуре, так потом самому проще находить нужное. А раз ценность для меня очевидна, то нужно максимально удешевлять сам процесс. Почему не просить делать это Claude? А потому что плагин делает это стабильнее, быстрее и не ест кучу токенов.

Claude и $150 на логотипы

Мы в продукте работаем на разных рынках, на которых присутствует много локальных компаний — провайдеров. Соответсвенно, нужно добавлять логотипы этих компаний в свою базу, чтобы по красоте отображать их в различных списках операций, инвестициях и тд. Руками собирать такое уже не ок. Поэтому я отдал эту задачу Claude.

Тут стоит добавить, что сначала нужно научить его, показать как нужно, как не нужно. То есть самому понимать принцип сборки провайдеров.

Что в итоге

Обучил на уже готовых хороших примерах, собрал скилл. Далее дал ему список компаний и отправил его в поля (через Goggle Chrome), попросив найти все лого в формате svg и пересобрать по всем правилам. Пришлось чуть докрутить в моменте скилл, но результат вышел достойным. Пока я делал свои задачи, он за 2 часа собрал более 200 провайдеров, оставил только эмблемы, убрав текст из исходников, отцентрировал все это по массе, убрал лишние группы и почистил слои. И после моего ревью разложил по группам рядом с другими уже существующими провайдерами. Результат, который можно использовать.

Из интересного

Работал на Fable (привык когда ему сбрасывали лимиты), и вопросов он задавал мало, и все понимал сразу, хороший такой мидл дизайнер. Когда я потратил $150☹️ — то переключился на Sonnet, и словил кучу багов. Пришлось допиливать скилл с помощью того же Fable, так как Sonnet делал не то. Сильно была заметна разница.

В целом, автоматизация настроена, в будущем добавить новых лого вообще не проблема, а это точно ещё предстоит делать.

Вывод

Писать скилы точно на Fable, плюс теперь буду просить его добавлять в него максимальное количество информации, чтобы другие модели не терялись. А после отдавать рутину моделям попроще. Плюс разделил скилл на два: создание и ревью, чтобы модель лучше понимала что от неё хотят.

Тренд: роль AI-агента в дизайн-системах

Последнее время выходит много видео и статей о роли ИИ в дизайн-системах. И заметно, что фокус постепенно смещается в сторону агента-помощника для соблюдения порядка, ревью компонентов, токенов и спецификаций. То есть, по сути, это отказ от идеи «создай мне компонент» и переход к «помоги мне поддерживать системность».

Сейчас есть идеи по разделению агентов: один делает только ревью текущей системы, другой — только правит, третий — исследует новые подходы, но не меняет текущую систему, а просто предлагает решения и план миграции.

Я всегда скептически относился к разным историям в духе: «ИИ может создавать компоненты». Безусловно, он может. Вопрос только в масштабируемости такой системы, её осознанном точечном изменении, если это требуется, и последующей поддержке.

И вот про осознанное изменение, особенно моё любимое — генерацию токенов, — это прям боль. Возможно, у кого-то реально получилось, и оно работает как нужно. Я бы посмотрел. Но то, что я вижу, говорит об обратном. Можно потратить кучу времени (и денег) на правки созданного ИИ артефакта и всё равно не понять, как была собрана та же палитра или компонент. И что делать, если нужно подвигать цвет или добавить какой-то пропс в компонент без сильной переделки (иначе у кого-то поедут макеты), — вопрос.

Это всё к тому, что ИИ — крутой помощник. Но чтобы использовать его на максимум, хорошо бы самому понимать, как устроена система, разбираться в деталях и уметь проверить результат за ИИ. Примерно так же, как мы проверяем текст или изображения: мы сразу можем сказать, ок или не ок. Потому что у нас есть экспертность в этом.

Убеждён, что нам всё ещё нужно уметь собирать компоненты и превращать это в системность. Агент тут будет выступать множителем этой системности, используя понятные правила и ограничения, которые мы ему пропишем.

Сами как думаете, согласны или можно доверить ИИ все сделать самому?

Не так давно Т-Банк стал активно заниматься развитием регионов. В рамках этой инициативы я решил поучаствовать и тоже поделиться опытом с ребятами, кто только начинает свой путь или кому было интересно узнать, как создаются крупные продукты, как дизайн можно превратить в систему и как дизайн-система помогает экономить, масштабировать и поддерживать продукты едиными в рамках всей компании.

Мне нравится делиться опытом, и точно так же всегда интересно послушать коллег по цеху и не только. Если есть чего подсмотреть/списать, я вообще за)

Дизайн-система для AI: документация или контракты?

В комьюнити ДС часто задаются вопросом — «Нужно ли разделять гайды для людей и для AI?»

Из последних трендов стала выделяться интересная модель: Documentation + Contracts.

Уже недостаточно просто писать гайды человеческим языком. AI-агенты могут их читать, получать контекст и понимать общие принципы системы. Но если мы хотим, чтобы агент не просто «знал документацию», а мог безопасно работать с системой, ему нужны более жёсткие и однозначные рамки: что допустимо, что запрещено, какие варианты существуют и какие правила нельзя нарушать.

Эту роль как раз берут на себя контракты.

Ранее я уже писал про документацию пропсов компонента, но здесь предлагается более широкая модель:

Documentation → объясняет, зачем существует компонент, как и когда им пользоваться, а когда не стоит.

Component Contract → формально определяет, что считается допустимой реализацией компонента: его props, variants, states, slots, ограничения и допустимые комбинации.

Получается, что это не две отдельные документации — одна для человека, другая для AI. Скорее два слоя одной системы:

Documentation → помогает понять решение
Contract → определяет границы решения

Человек в первую очередь работает со смыслом и контекстом. Агент тоже может использовать этот слой, но при генерации, изменении или ревью компонентов он дополнительно опирается на контракт как на проверяемый источник правил.

И здесь появляется важное следствие: контракт можно не только читать, на его основе можно валидировать компоненты, писать тесты, проверять изменения.

И самое важное: давать агенту гораздо меньше пространства для ошибок интерпретации.

Первый пробный прогон контракта на базе компонента Cell.

Это скрин теста, который агент сам прогоняет после генерации контракта по компоненту. Выдает сводную таблицу: проверяет позитивные, негативные сценарии и сам себе задает вопросы — по сути симулятор, чтобы не гонять в Figma лишние токены. Проверяет корректность и устойчивость сгенерированного контракта.

Получается такой агент-флоу:

ревью компонента → генерация контракта → тесты.

Следующий этап не начинается, пока не завершится предыдущий.

Расход токенов при работе с Figma to Claude

Токены стоят дорого, лимиты быстро утекают, особенно на сложные задачи. Но проблема даже не в том, что они сложные, иногда агент просто читает слишком много данных в Figma.

Claude частенько запрашивает метаданные всей страницы — сотни нод в XML. Хотя для задачи мог понадобиться один конкретный компонент или фрейм. Даже когда даешь ему ссылку на фрейм, просишь сделать ревью, он иногда грузит всю страницу целиком, чтобы лучше понять контекст. И он отчасти прав, но это стоит дорого и не всегда нужно.

Можно полечить это, ограничив его следующими правилами:

## Figma context rules

- Read only the scope required by the task.
- Never read the entire page or file when a specific nodeId is known.
- If the user provides a frame link, inspect only that frame.
- Use full-page or full-file reads only when explicitly requested or required by the task.
- Return aggregated results from use_figma: counts, findings, and violations.
- Never return raw node trees when aggregated data is sufficient.

То есть принцип довольно простой: не прочитать всё и потом отфильтровать, а изначально не читать лишнее.

На больших Figma-файлах разница в размере контекста может быть очень заметной. В моем случае это дало в ~69 раз меньше токенов.