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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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