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

Этот процесс отлично работал, когда у нас было время на тщательную разработку и создание каждого интерфейса. Но при последнем обновлении PubHub (внутреннего инструмента публикации DevNet) времени не было. Нам нужно было двигаться быстро, поэтому мы попробовали другой подход: попросили ИИ создать интерфейс напрямую на основе наших пользовательских историй (user stories) и бэкенд-API.

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

Рабочий продукт, но не то ощущение

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

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

Попытка перенести интерфейс в Figma

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

Идея была привлекательной: оставить проектную работу в Figma и использовать ИИ для воплощения этих изменений в коде. На практике возникло три проблемы.

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

Figma по-прежнему хорошо справлялась с некоторыми задачами. Это был лучший инструмент для поддержания библиотеки ассетов и точной работы с мелкими, высокодетализированными элементами UI. Но он не подходил для быстрой доработки интерфейса, который уже работал в коде в условиях жестких сроков.

Объединение дизайн-проекта с существующей реализацией

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

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

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

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

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

Новый цикл: проектный артефакт, затем реализация

Получившийся рабочий процесс носит итеративный характер:

Продуктовая команда определяет пользовательские истории и бэкенд-API.
Агент кодирования с поддержкой ИИ создает полнофункциональную версию интерфейса.
Дизайнеры проверяют работающие HTML-страницы и сценарии, а затем дорабатывают HTML-прототип с помощью ИИ-инструмента для кодирования.
Дизайнеры передают обновленный HTML-артефакт разработчикам вместе с дизайн-системой, полными сценариями для различных персон и списком изменений (changelog), описывающим то, что изменилось.
Разработчики передают их агенту кодирования, который прорабатывает и применяет изменения дизайна к реальному проекту.
Команда тестирует и оценивает результат, часто в режиме реального времени, и повторяет процесс.

Новые артефакты передачи макетов

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

HTML-прототип. Он стал центром этого цикла. Это конкретный проверяемый артефакт, который дизайнеры могут напрямую дорабатывать, а разработчики — использовать в качестве ориентира для изменений в продакшн-коде.
Встроенная дизайн-система. Цвета, типографика, компоненты и отступы находились рядом со страницами, поэтому инженеры могли ссылаться на правила, а не выводить их самостоятельно из экранов.
Переключатель персон. Наш дизайн требовал различных пользовательских сценариев для разных типов пользователей (персон). Переключая персоны с помощью элемента управления в прототипе, инженеры могут четко видеть каждый сценарий и его вариации.
Журналы изменений (Changelogs). Каждая итерация фиксировала произошедшие изменения, что позволяло инженерам применять обновления постепенно, а не сравнивать целые страницы.

Проблема: поддержание синхронизации дизайна и кода

По мере того как дизайнер итерировал проект, становилось трудно понять, что изменилось между версиями HTML. Сначала мы работали со списком задач (issue list), давая нашему агенту по кодированию по одной правке за раз, что было медленно и выполнялось вручную.

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

Чему мы научились

Самым большим изменением стало не использование ИИ для написания большего объема кода. Главное — мы сблизили циклы обратной связи по дизайну и разработке настолько, что грань между этими двумя ролями начала стираться.

Этот переход потребовал определенного обучения.

Более высокий темп изменил ритм работы команды:

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

Если ваша команда хочет опробовать этот подход, следующие практики принесли нам наибольшую пользу:

Начните с работающей сборки. Поручите ИИ-агенту сгенерировать сквозной пользовательский интерфейс на основе ваших пользовательских историй и спецификаций API, а затем проектируйте поверх него, а не с чистого листа.
Сохраняйте единый источник правки. Сделайте HTML-прототип каноничным дизайном. Используйте Figma там, где она сильна — например, для библиотек ресурсов и проработки мелких деталей, не поддерживая при этом параллельную копию каждого экрана.
Встройте передачу в разработку (handoff) в сам прототип. Включите дизайн-систему, журнал изменений для каждой итерации и способ просмотра каждой роли или вариации пользовательского сценария.
Укажите то, что агент не может додумать сам. Задокументируйте второстепенные взаимодействия и крайние случаи, иначе агент-программист придумает их сам.
Учитывайте ограничения на токены. Будьте готовы переключаться между инструментами ИИ прямо во время проекта. Поскольку HTML-артефакт хранит состояние дизайна, вся проделанная работа сохраняется.
Сократите цикл проверки. Проверяйте чаще и будьте готовы вносить правки в реальном времени вместе с инженерами.
Сохраняйте ключевую роль мнения дизайнера. ИИ быстро выдает функциональную первую версию, но он не знает вашего языка дизайна и того, какие взаимодействия ощущаются правильно.

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

Этот блог является частью серии статей «ИИ и агентные рабочие процессы в PubHub» [LINK TO PUBHUB SERIES IF ANY]. Чтобы узнать больше о том, как мы воплощаем проект PubHub в жизнь с помощью разработки при поддержке ИИ, читайте здесь.