«Живой» интерфейс без разработки: как в Mindbox внедрили AI-first прототипирование

На связи Антон Черный, лид команды продуктового дизайна. Расскажу, как рядовая задача заставила нас пересобрать UX‑процесс и ускорить проверку гипотез с помощью AI‑first прототипирования.

До недавнего времени Figma была основным инструментом, с помощью которого мы создавали и тестировали прототипы наших продуктов. Когда решили переделывать UI конструктора email‑рассылок, мы поняли, что разработка затянется и отнимет много ресурсов. В интерфейсах такого типа слишком много состояний и сценариев, поэтому проверка гипотез превращается в бесконечный цикл «нарисовали — показали клиентам — переделали».

Мы попробовали AI‑first прототипирование: собрали рабочий прототип в Lovable и начали дорабатывать его промптами между UX‑тестами. В итоге ускорили проверку гипотез в два раза и перестроили UX‑процесс.

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

Что было не так со старым конструктором рассылок: кастомный набор блоков и ручная HTML-верстка

Mindbox — платформа автоматизации маркетинга, которая помогает маркетологам собирать данные о клиентах, сегментировать аудиторию и запускать персонализированные коммуникации в разных каналах. Один из наших ключевых инструментов — конструктор email‑рассылок, в котором маркетологи собирают письма и готовят их к отправке.

Раньше в конструкторе email‑писем можно было использовать только готовые HTML‑блоки, которые Mindbox создавал отдельно под требования каждого клиента. При создании шаблонов клиенты не могли быстро обновлять дизайн писем: поменять структуру блоков или изменить стили элементов. Например, если есть этаж с текстом слева, а иллюстрацией справа, поменять их местами было невозможно — только выбирать другой шаблонный этаж.

Можно было только вписать свой текст, изменить его стиль, вставить картинки. Для всего остального прибегали к HTML‑верстке. Из‑за этого онбординг клиентов Mindbox растягивался. Маркетологи медленно запускали кампании, например они начинали готовить рассылки о скидках за 2–3 месяца до «черной пятницы».

Конструктор email‑рассылок решили переделать так, чтобы он был удобным и понятным для клиентов‑маркетологов. И чтобы при этом не нужно было каждый раз верстать HTML‑блоки отдельно для каждого клиента.

Зачем переосмысливать UX-процесс: линейные прототипы и 1,5 месяца на проверку гипотез

До недавнего времени цикл разработки дизайна в нашей компании выглядел так:

1. Мы заранее продумывали сценарии пользовательского интерфейса.

2. Рисовали в Figma кликабельные линейные прототипы сценариев.

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

4. Собирали обратную связь и вносили изменения. Например, меняли текст на кнопке или перемещали ее на более очевидное место.

При необходимости цикл повторяли. В конце собирали чистовой прототип с комментариями и отправляли разработчикам.

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

А в конструкторе письма действий много: добавлять блоки, выбирать их тип, перетаскивать и вкладывать блоки друг в друга, делить строку на колонки, редактировать текст, применять к нему разные стили и загружать изображения. Это сложный интерфейс — чтобы его разработать, нужно проверить больше 20 гипотез вместе с клиентом. Для каждой приходится запускать весь цикл заново: отрисовывать экраны, прописывать сценарии «от клика к клику», тестировать с клиентами. Проверка всех гипотез может занимать до 1,5 месяцев.

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

Что нужно было учесть при разработке: простая блочная архитектура и гибкий интерфейс

Верстка писем отличается от верстки страниц для браузера. Для сайтов можно использовать CSS, flex, анимацию, позиционирование. В письмах же работают другие правила: ограниченный набор тэгов, табличные структуры, inline‑стили, никаких внешних CSS. Любое отклонение — и письмо криво отобразится в почтовом клиенте. Из‑за этого мы ввели ограничение для нового конструктора: шаблон письма должен легко транслироваться в HTML‑таблицу, пригодную для отправки по email. А значит, список элементов, из которых он может состоять, должен быть минимальным и уж точно не должен повторять ^[1] все пространство имен HTML.

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

Для начала мы проанализировали структуру шаблонов из email‑рассылок и выделили набор базовых элементов, с помощью которых можно построить любое письмо: блок, строка, колонка, контент. Этим набором решили ограничиться, чтобы не раздувать число сущностей в конструкторе. Блок, строка и колонка — это контейнеры. Они занимают конкретное место в структуре шаблона. Письмо состоит из блоков, блоки — из строк, строки — из колонок. Колонки могут содержать только контент — основные визуальные элементы письма, к которым относятся текст, кнопка, изображение и разделитель.

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

Как пришли к AI-first прототипированию: Lovable, ChatGPT и быстрые итерации

Учитывая, что AI сейчас повсюду, а рисовать в Figma сотни состояний — так себе план, мы решили собрать интерактивный прототип в Lovable. Это AI‑сервис, который по описанию создает работающий веб‑интерфейс, чтобы быстро прогонять UX‑сценарии без разработки.

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

Мы решили поменять стратегию и обратились к ChatGPT. Объяснили ему голосом бизнес‑задачу, а он сгенерировал готовый промпт для Lovable.

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

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

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

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

За неделю мы провели около 20 UX‑тестов и каждый раз вносили изменения через уточняющие промпты в Lovable. Таким образом, мы стали создавать прототипы для проверки гипотез в среднем в 2 раза быстрее.

Как устроен новый дизайн-процесс: ×2 к скорости и новая роль клиента

Эксперимент с Lovable показал, что рабочие прототипы можно собирать и дорабатывать в 2 раза быстрее, чем раньше.

Теперь AI‑first прототипирование стало базовым способом проверять UX‑гипотезы во всех продуктах Mindbox. Сейчас цикл разработки продуктового дизайна выглядит так:

1. Обсуждаем задачу и накидываем черновое решение «на салфетке».

2. Создаем рабочие прототипы интерфейса в Lovable.

3. Предлагаем клиентам воспользоваться ими и собираем обратную связь. 

4. Вносим изменения уточняющими промптами и тестируем снова.

5. В итоге собираем в Figma чистовой прототип с комментариями для разработчиков.

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

AI‑first подход помог увидеть реальное взаимодействие с продуктом. Как будто клиент работает с опубликованной версией на проде. Качество обратной связи выросло, а у нас появилась 100% уверенность, что в разработку отправляется прототип, который учитывает потребности ^[3] клиента.