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

Почему библиотека ИИ-компонентов требует отдельного процесса

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

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

Как выстроить процесс от макета до кода

Разбейте работу на этапы и зафиксируйте артефакты. Например:

  • Исследование. Соберите реальные сценарии использования компонента: какие данные приходят, как меняется состояние, что видит пользователь при ошибке. Результат — короткое описание требований и примеры.
  • Проектирование. Сделайте макет с учётом всех состояний (загрузка, успех, ошибка, пусто). Не забудьте про адаптивность и тёмную тему, если она есть в системе.
  • Реализация. Здесь можно делегировать рутину агентам: сгенерировать заготовку кода по макету, написать тесты, обновить документацию. Ваша задача — проверить результат и передать фронтендерам на ревью.
  • Проверка и исправления. После ревью убедитесь, что компонент попал в Storybook, а документация соответствует реальному поведению.

Ключевой момент — не пытаться сделать всё самому. Агенты хорошо справляются с шаблонной работой, но финальное качество остаётся за вами.

Какие навыки нужны дизайнеру

Чтобы вести компонент до кода, не обязательно становиться разработчиком, но нужно понимать базовые вещи:

  • HTML/CSS. Достаточно уверенного чтения и правки, чтобы объяснить агенту задачу и проверить результат.
  • Основы JavaScript и React. Понимать, как работают пропсы, состояния, условный рендеринг — хотя бы на уровне чтения кода.
  • Инструменты вроде Storybook. Уметь добавить историю и проверить, как компонент выглядит в изоляции.
  • Работа с агентами. Чётко формулировать промпты, задавать ограничения, проверять сгенерированный код на соответствие макету.

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

Типичные ошибки и как их избежать

Вот что чаще всего мешает:

  • Игнорирование краевых случаев. Компонент красив в идеальном состоянии, но ломается при ошибке или долгой загрузке. Всегда проектируйте все состояния.
  • Отсутствие документации. Без описания пропсов и примеров использования компонент не приживётся. Обновляйте Storybook сразу.
  • Перекладывание ответственности на фронтендеров. Если вы передаёте код без проверки, ревью превращается в переписывание. Убедитесь, что заготовка соответствует макету и работает.
  • Слишком широкий охват. Не пытайтесь сразу сделать библиотеку для всех ИИ-сценариев. Начните с одного-двух компонентов, отточите процесс, затем расширяйте.

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

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

Что в итоге

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