Дизайн-система: компоненты, токены и подготовка к AI-агенту

Дизайн-система — это общие правила интерфейса, переиспользуемые компоненты и порядок их изменения, а не просто аккуратная страница в Figma. В учебном примере ниже 3 компонента дают 24 контрольные комбинации: проверять только их обычный вид недостаточно. Когда экран собирает AI-агент, недосказанные правила становятся особенно заметны: он выбирает похожую кнопку вместо нужной, переносит цвет без его назначения или придумывает отсутствующее состояние. Лечить это ещё одним длинным промптом поздно: сначала нужно привести в порядок библиотеку и её описание. Разберём, что входит в систему, как связать компоненты с токенами, какие сведения передать агенту и как принять результат. В конце получится не абстрактный список пожеланий, а небольшой проверяемый комплект: карта библиотеки, правила сборки, примеры состояний и журнал найденных расхождений.

Чем система отличается от UI-кита

UI-кит отвечает на вопрос «что у нас нарисовано», а дизайн-система — ещё и на вопросы «когда это применять» и «кто разрешает изменения». Для первого аудита удобно разделить её на 3 слоя: основы оформления, компоненты с паттернами и правила сопровождения. Это рабочая схема проверки, а не требование завести три отдельных файла. Важны связи между слоями, не красота оглавления.

Основы задают цвета, типографику, интервалы, скругления и другие повторяемые решения. Компоненты превращают их в кнопки, поля, уведомления. Паттерны описывают задачи: например, как показать ошибку отправки формы, сохранив введённые данные. Правила сопровождения объясняют, какой источник актуален и как предложить изменение без параллельной «почти такой же» библиотеки.

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

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

Начните с инвентаризации, а не с переименования слоёв

Карта библиотеки должна связывать название компонента с его назначением, местом хранения и допустимым использованием. Для начальной записи достаточно 6 полей: имя, задача, ссылка на источник, свойства, состояние готовности и ответственный. По такой записи дизайнер или агент найдёт нужный элемент, не перебирая похожие фреймы. Массовое переименование без проверки связей эту задачу не решает.

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

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

Затем назначьте понятные статусы: «разрешён», «экспериментальный», «устарел». Для устаревшего элемента укажите замену, а не просто запрет. Агенту нужен явный ответ, что использовать вместо него; человеку — объяснение, почему старый экземпляр ещё встречается в макетах.

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

Свяжите токены со смыслом, а не только со значением

Дизайн-токены сохраняют повторяемые решения под именами, чтобы компонент обращался к назначению значения, а не копировал его вручную. Для проверки достаточно проследить 2 уровня: исходное значение и семантическую роль. Например, цвет из палитры используется как фон основного действия. Отдельный компонентный слой добавляйте там, где он действительно нужен, а не ради симметрии названий.

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

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

Для обмена между инструментами есть Design Tokens Format Module 2025.10. Спецификация описывает JSON-формат, значения, типы и ссылки между токенами; это документ Design Tokens Community Group, не W3C Recommendation. Совпадение терминов в двух инструментах не гарантирует совместимый импорт.

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

Разделите варианты, состояния и содержимое компонента

Вариант описывает допустимую конфигурацию, состояние — положение компонента во взаимодействии, содержимое — конкретные текст и данные. У кнопки размер S или M не равен состоянию disabled, а длинная подпись не создаёт новый вид кнопки. В учебной матрице 2 размера, 2 варианта и 3 выбранных состояния дают 12 комбинаций. Так становится видно, что именно библиотека покрывает.

Сначала определите оси настройки. Для кнопки это размер, визуальный приоритет, наличие иконки и поведение при выполнении действия. Не объединяйте всё в имена вроде ButtonBlueSmallFinal. Свойства должны отвечать на отдельные вопросы, иначе человек и агент будут угадывать устройство компонента по названию.

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

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

В расшифровке видео от 3 сентября 2026 года отсутствие вариантов в рассматриваемом тогда инструменте описывается как причина разрастания библиотеки. Здесь важен критерий выбора среды, не исторический вердикт продукту: проверьте в своей версии, позволяет ли она выразить нужные свойства без цепочки независимых копий. Ограничения текущего инструмента нельзя выводить из старой демонстрации.

Опишите правила сборки экранов и допустимые исключения

Компоненты не определяют сценарий целиком: нужны правила их сочетания. Для начала опишите 1 повторяющийся паттерн, например отправку формы. Укажите главное действие, сообщения об ошибке, ожидание ответа и сохранение данных. Такой контракт помогает отличить исправление сценария от декоративной перестановки элементов. Его проверяют по действиям пользователя, а не только по сходству двух экранов.

Зафиксируйте границы. Какие компоненты обязательны? Какие свойства разрешено менять? Где допустим локальный контейнер? Что делать, если нужного элемента нет? Для агента ответ «сделай в нашем стиле» не заменяет этих правил. Он оставляет неопределённым самое важное — какие решения уже приняты, а какие ещё предстоит согласовать.

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

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

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

Дайте агенту карту и контракт вместо всей истории проекта

Контекст для AI-агента — это ограниченный набор актуальных источников, связей и правил для конкретной задачи. Соберите 4 части: карту компонентов, карту токенов, профили компонентов и контракт сборки. Это схема подготовки, описанная в эфире от 24 июня 2026 года, а не обещание автоматического переноса любой библиотеки. Её ценность — в явных точках обращения и проверки.

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

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

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

Архивные экраны и экспериментальные компоненты не включайте наравне с действующей библиотекой. Если они нужны как контекст, явно подпишите их статус. Техническое подключение разобрано отдельно в статье про Figma MCP; подключённый инструмент даёт доступ к данным, но не выбирает за команду правильный источник и не заменяет приёмку.

Учебный мини-кейс: подготовьте форму заявки

Возьмём авторский учебный пример, не клиентский проект и не результат работы студента: форму заявки с кнопкой, полем и уведомлением. Для первого прохода выберем 3 компонента и ограниченную матрицу из 24 контрольных комбинаций. Это счёт заданных примеров, а не статистика эффективности и не обязательный размер библиотеки. Полную проверку поведения предстоит расширить под реальный сценарий.

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

Это не инструкция хранить состояния только так. Уведомление в таблице проверяется по типу и содержимому, а не по состояниям кнопки. Выбранный список намеренно не включает loading, hover и сочетания фокуса с наведением: их следует добавить, если они нужны продукту. Нельзя назвать матрицу полной, просто получив красивое итоговое число.

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

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

Для проекта с двумя темами тот же список даёт 48 визуальных контрольных примеров. Это объём выбранной проверки, не срок выполнения и не гарантия отсутствия других ошибок.

Проверьте библиотеку в макете и в коде отдельно

Готовность библиотеки подтверждается проверкой источников, поведения и связей с реализацией. Разделите приёмку на 3 прохода: структура, визуальные состояния и взаимодействие. Экран, похожий на макет, способен провалить любой из них. Поэтому сравнивайте не только изображение, но и происхождение компонентов, значения свойств и реальные действия пользователя на тестовом стенде.

Структура. Проверьте, какие компоненты использованы, сохранились ли экземпляры, существуют ли токены и нет ли новых локальных дублей. Если есть кодовая библиотека, установите соответствие между её компонентом и элементом в макете. Одинаковое название — полезная подсказка, но не доказательство одинакового поведения.

Внешний вид. Откройте выбранные состояния, длинные тексты и темы. Для нашего упражнения сравните все 24 комбинации, а не одну кнопку и одно поле. Фиксируйте конкретное расхождение: компонент, состояние, ожидаемое правило, наблюдение. Формулировка «выглядит неаккуратно» не объясняет, где исправлять источник.

Взаимодействие. На отдельном тестовом стенде пройдите сценарий клавиатурой, проверьте видимость фокуса, ошибку ввода и недоступное действие. Не отправляйте реальные заявки ради проверки компонента. Визуальная карточка не показывает, как элемент получает фокус или сообщает об изменении состояния.

В расшифровке эфира от 27 августа 2026 года описана проверка кодовых компонентов в Storybook до сборки экранов. Документация Storybook определяет story как отображённое состояние компонента. Это удобный способ разложить библиотеку на проверяемые примеры; сам каталог не подтверждает, что тесты действительно выполнены.

Сверку дизайна с кодом не привязывайте к обязательному React-стеку: выбирайте реализацию продукта. Отдельно оставляйте список непроверенного. Если интерактивного стенда нет, честный результат — «проверены структура и изображения», а не «компонент полностью готов к разработке».

Назначьте владельца изменений и следующий шаг

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

Самые частые сбои видны уже на первом аудите:

• В библиотеке есть дубли, но не указано, какой компонент разрешён. Назначьте основной источник и путь замены.
• Сохранены цвета, но потеряны семантические связи. Исправьте привязки, затем повторите проверку тем.
• Варианты нарисованы, а поведение не описано. Добавьте критерии взаимодействия и контрольные примеры.
• Агент получил архив наравне с действующими компонентами. Ограничьте контекст и подпишите статусы.
• Красивый экран принят без проверки структуры. Вернитесь к карте использованных элементов и журналу расхождений.

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

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

Чтобы встроить подготовку библиотеки в остальной процесс дизайнера, получите бесплатный гайд «Карта процесса: 8 приёмов дизайнера с AI-агентом и скилл». Гайд открывается после указания почты и телефона. Он продолжает тему постановки задач агенту; проверку собственной библиотеки и ответственность за результат всё равно нужно оставить за командой.