Внедрение ИИв работу дизайн-команды

Контекст

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

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

Макеты остаются обязательной частью процесса. Я ищу способы лучше проверить решение до разработки и передать его дальше.

Первый работающий прототип

При работе над пользовательским меню я предложил попробовать Figma Make. Концепцию и макеты мы разрабатывали вместе с продуктовым дизайнером, а интерактивный прототип я собрал и довёл сам.

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

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

Позже код прототипа меню передали фронтенду и использовали как основу каркаса реализации. Подробнее о задаче с меню →

Подготовить основу для повторного использования

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

Моя задача состояла в том, чтобы компоненты точно передавали устройство и внешний вид нашего продукта. Я организовал последовательные проверки и передачу исправлений. Замечания фиксировал своим расширением, а изменения в компоненты вносились с помощью ИИ. Так мы доводили библиотеку в Storybook до нужного качества.

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

Как мы готовили документацию → · Как устроено моё ревью →

Проектировать в работающем интерфейсе

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

Последние задачи мы проходим так:

1. Готовим черновые макеты, чтобы задать структуру и замысел.
2. Собираем прототип на компонентах продукта и дорабатываем его в действии: проверяем данные, поведение и визуальные решения.
3. Через MCP поручаем агенту собрать результат в Figma по нашим шаблонам и правилам. Он использует компоненты дизайн-системы и создаёт локальные компоненты там, где они нужны.
4. Проверяем макеты. Они проходят установленный процесс согласования и остаются основой для аналитики. Прототип и описание поведения готовим к передаче фронтенду.

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

Помочь команде перестроиться

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

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

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

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

Обновлять накопленные макеты

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

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

Это ещё один способ использовать накопленные знания о продукте: объяснить правила агенту и применять их к повторяющейся работе.

Что уже изменилось

Следующий шаг

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

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