Как сделать дизайн-систему готовой для агентов

Если не хотите, чтобы ваш ИИ-агент захлебнулся design.md, перестаньте складывать всю дизайн-систему в один файл.

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

Как нам использовать эту технологию, чтобы оставаться востребованными, укреплять навыки и готовиться к грядущему?

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

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

Я хочу, чтобы ИИ понимал, как мы проектируем продукт.

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

Когда «почти правильно» недостаточно

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

Мы уже генерировали фронтенд с помощью ИИ прямо по нашим дизайнам в Figma. И пробуем шаг дальше: пропустить часть привычной стадии дизайна и идти от брифа и правил дизайн-системы сразу к рабочему фронтенду.

Первые результаты впечатляли. С Figma MCP путь от дизайна до рабочего фронтенда занимал минуты.

Потом мы присмотрелись.

У карточки было неверное состояние наведения. Цвет использовался не по семантическому назначению. Отступы между элементами не соответствовали нашим правилам. Кнопки были технически правильными, но не соблюдалась иерархия основных и вторичных действий.

Ничто из этого не было сделано плохо.

Просто это было не так, как принято у нас.

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

То же относится и к сгенерированному коду. Мы снова и снова поправляли агента:

Не используй здесь брендовый цвет. Этому компоненту нужны другие состояния. Используй этот токен отступа. Для этого у нас уже есть паттерн. Этому действию место в тулбаре.

И вот тогда щёлкнуло.

Проблема была не в том, чтобы сгенерировать интерфейс. А в том, чтобы дать агенту достаточно контекста, чтобы собрать его по нашей дизайн-системе.

Дизайн-система становится контекстом

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

Проблема в том, что большинство дизайн-систем создавали в первую очередь для людей.

Мы собираем библиотеки в Figma. Документируем компоненты в Storybook или на сайтах документации. Рассчитываем, что дизайнеры и инженеры найдут эту информацию, разберутся в ней и правильно применят.

Но агенту тоже нужен доступ к этим решениям.

Дать ему доступ к Figma — часть ответа. Figma многое сообщает о том, как что-то выглядит: компоненты, варианты, переменные, отступы, цвета и композиция. Но она не содержит всего, что агенту нужно знать: что собирать и как это должно работать.

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

Поэтому я начала спрашивать:

Как нам структурировать знания дизайн-системы так, чтобы агент мог по ним рассуждать и применять их?

Делаем дизайн-систему готовой для агентов

Вы, возможно, спросите: а почему бы не отдать агенту наш tokens.json?

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

Файл токенов не говорит агенту, что наш Wizard состоит из Top Bar, Stepper, Header, Content Area и Bottom Action Bar. Не говорит, какие действия куда ставить, как устроена навигация между шагами и когда пользователь может идти дальше, а когда нет.

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

Именно этот подход мы и пробуем.

Структура, которой агент может пользоваться

На верхнем уровне мы делим систему на:

Создание → Спецификация → Поставка

1. Создание

Figma по-прежнему остаётся местом, где мы создаём и ведём визуальную дизайн-систему.

Мы делим её на базовые параметры, компоненты, паттерны и шаблоны.

Компоненты — отдельные строительные блоки; паттерны описывают, как компоненты работают вместе; шаблоны дают стартовую структуру для типичных страниц и сценариев.

Наш Wizard, например, — это шаблон. В Figma мы можем задать его компоновку, паттерны, компоненты и визуальные состояния.

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

Вот тут появляется слой спецификации.

2. Спецификация

Параллельно с Figma мы ведём структурированные спецификации, которые агент может читать.

Структура, с которой мы экспериментируем, выглядит так:

                         tokens.json
                      Базовые параметры
                              │
                              ▼
                          design.md
                   Общие правила и стандарты
                              │
                              ▼
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
     components.md        patterns.md        templates.md
  Реестр компонентов   Реестр паттернов    Реестр шаблонов
          │                   │                   │
          ▼                   ▼                   ▼
    *.component.md       *.pattern.md       *.template.md

tokens.json содержит визуальные базовые параметры. design.md — общие правила и договорённости. (Подробнее об истоках этого подхода — у Google Labs.)

components.md, patterns.md и templates.md работают как реестры (списки): агент видит, что существует и где лежит нужная спецификация.

В отдельных Markdown-файлах — уже сами правила.

Например, templates.md направляет агента к wizard.template.md. В этом файле не нужно заново определять каждый Button, Stepper или Action Bar. Вместо этого он ссылается на соответствующие спецификации и задаёт, как они складываются в сценарий нашего Wizard.

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

Упрощённо это выглядит так:

# Wizard

## Назначение
Помогает пользователям выполнить сложную задачу, 
разбивая её на последовательность простых шагов.

## Зависимости

### Паттерны
- [Top Bar](../patterns/top-bar.pattern.md)
- [Header](../patterns/header.pattern.md)
- [Bottom Action Bar](../patterns/bottom-action-bar.pattern.md)
- [Dialog](../patterns/dialog.pattern.md)

### Компоненты
- [Stepper](../components/stepper.component.md)
- [Status label](../components/status-label.component.md)
- [Button](../components/button.component.md)

## Поведение
- Пользователи проходят шаги последовательно.
- Пользователи могут возвращаться к завершённым шагам.
- Пользователи не могут переходить напрямую к невыполненным последующим шагам.
- Введённая информация сохраняется при переходе между шагами.
- Stepper отображает текущий и завершённые шаги.

## Действия
- «Выход» использует кнопку / третичного уровня и отображается в верхней панели.
- «Назад» использует кнопку / вторичного уровня и отображается в нижней панели действий.
- «Далее» использует кнопку / первичного уровня и отображается в нижней панели действий.
- «Назад» возвращает к предыдущему шагу.
- «Далее» проверяет правильность ввода на текущем шаге перед продолжением.
- «Выход» позволяет выйти из мастера.
- Для выхода требуется подтверждение в диалоговом окне.

## Доступность
- Информация о текущем шаге передаётся программным путём.
- Ошибки проверки привязаны к соответствующим полям.
- Все действия доступны с клавиатуры.

Теперь агенту не приходится выводить всё это из фрейма в Figma.

wizard.template.md даёт ему структурированную точку входа и явные ссылки на необходимые спецификации. Если нужно разобраться в Bottom Action Bar, агент читает нужный файл. Если этот паттерн использует Button, можно пройти и к спецификации Button.

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

3. Поставка

В конечном счёте эти спецификации должны помогать делать настоящие продукты.

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

Но именно здесь, мне кажется, ИИ становится особенно интересным.

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

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

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

Разумеется, отсюда другой вопрос: кто поддерживает все эти спецификации?

Ответ, на мой взгляд, не должен сводиться к тому, что дизайнеры вручную обновляют Markdown каждый раз, когда что-то меняется в Figma. Это ещё одна область, где ИИ, мне кажется, может сыграть серьёзную роль — и, вероятно, тема для другой статьи.

Напоследок

Если ИИ позволяет почти кому угодно сгенерировать вполне приличный интерфейс, дизайн-системы становятся одним из способов сохранить узнаваемый характер наших продуктов.

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

Готовить дизайн-системы к этому будущему мы можем начинать уже сейчас.

Перевод статьи "How to Make Your Design System Agent-Ready" @Eva Nudea Hörner.