Как и зачем дизайнеры развивают библиотеку ИИ‑компонентов от макета до кода

Привет! Меня зовут Егор Шувалов, я дизайнер в Cloud.ru и работаю над интерфейсами для взаимодействия с ИИ-агентами. Вместе с коллегами мы развиваем отдельную библиотеку компонентов на базе нашей основной дизайн-системы.

Как мы заметили потребность в общей библиотеке

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

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

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

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

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

Почему мы организовали отдельный процесс

Потребность в общих элементах совпала с другой проблемой — изменения в Snack UI Kit, нашей основной дизайн-системе, проходят слишком долгий для нас путь. У ее команды свой бэклог и порядок работы. Дизайнер готовит задачу, собирает компонент в ветке Figma, проходит согласования и ревью. При этом реализация зависит и от планов команды, у которой есть другие задачи.

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

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

Мы выделили отдельное направление и взяли его развитие на себя. Теперь сами определяем очередность, исследуем сценарии, проектируем и реализуем компоненты, проверяем их и готовим мерж-реквесты (merge request, MR). Фронтендеры подключаются к ревью кода. Так работа внутри нашего направления не зависит от очереди задач основной команды.

При этом наша библиотека опирается на Snack UI Kit: мы используем ее базовые компоненты, иконки, токены и гайдлайны. Свои элементы строим в той же системе оформления. Получается, что библиотека ИИ-компонентов развивается параллельно основной системе и дополняет ее под наши задачи.

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

От исследования продуктов к бэклогу

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

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

Как мы проектируем общий компонент для разных продуктов

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

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

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

Например, список команд Action List открывается по «/». В библиотеке мы описываем его устройство, раскрытие и работу со вложенными пунктами, а конкретные команды задает продукт. Так разные команды могут использовать один компонент, сохраняя собственный набор действий.

Компоненты мы проектируем в Figma. Для сборки используем агента, который работает с макетом через MCP — подключение к Figma, позволяющее агенту читать и изменять его содержимое. К общему ревью каждый из нас готовит компонент в ветке Figma с необходимыми состояниями.

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

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

Как мы фиксируем решения для реализации

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

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

Агент работает со скиллами из нашего пакета Design Lab — это инструкции о том, как выполнять задачу и проверять результат. Спецификация описывает конкретный компонент, а скилл задает порядок работы агента. Мы используем скиллы при подготовке материалов, оформлении спецификаций, проверке макетов и приемке кода перед MR. Требования к компоненту, сами решения и ответственность за результат остаются у дизайнеров.

Например, при работе над Message Bubble я разобрал сценарии и собрал компонент из подготовленных элементов. Коллеги оставили замечания и подсказали, что еще учесть. После исправлений я передал агенту материалы и поручил обновить существовавшую спецификацию. Для таких задач в Design Lab есть три основных скилла: design-spec помогает оформить договоренности рядом с макетом; aix — описать общие правила компонента и проверить макет или код по спецификации; accept — проверить готовый результат по требованиям к качеству перед передачей автору задачи.

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

Для подготовки спецификаций я использовал Claude Code и Codex. Заметной разницы в своем опыте не увидел, но специального сравнения, если честно, и не проводил. Я уделяю больше внимания тому, какие материалы передаю и как ставлю задачу: что уже решено, что нужно оформить и по каким требованиям буду проверять результат.

От спецификации к мерж-реквесту

Перед переносом компонента в код дизайнеру нужно получить доступ к репозиторию библиотеки в GitLab с необходимой ролью и правами, настроить подключение агента к репозиторию и проверить, что локальный Storybook запускается. Для подключения могут понадобиться SSH-ключи и настройки API. После этой подготовки дизайнер реализует компонент вместе с агентом и доводит изменения до ревью фронтендеров.

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

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

Сверяем реализацию с макетом и спецификацией, исправляем найденное и готовим MR.

Фронтендеры получают код для ревью. Например, в одном из моих MR они заметили, что свойство названо иначе, чем принято в главной дизайн-системе. Мы исправили название, чтобы оно соответствовало общим правилам.

В моих первых задачах замечания в основном касались таких деталей. Это были небольшие компоненты. С более сложными компонентами вопросов возникает больше, в том числе при нашей собственной проверке.

После исправлений мы возвращаем MR на ревью. Когда изменения согласованы и слиты, компонент становится доступен в нашей библиотеке ИИ-компонентов и Storybook.

Что обнаруживается при проверке в браузере

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

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

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

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

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

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

Что уже получилось

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

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

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

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

А как у вас устроена работа над общими компонентами: дизайнеры доводят их до кода или передают реализацию отдельной команде? Что в вашем процессе помогает изменениям доходить до продукта?