Все кейсы Кейс 01 — Qonversion
No-Code Builder в продуктовом стартапе
No-Code Builder — это инструмент, которым мобильные команды собирают и публикуют свои экраны подписки без разработчика: продукт внутри продукта. Я получила его первую версию и пересобрала её. Из той же работы выросли ещё две вещи, на которых держится продукт, — его дизайн-система и онбординг, и обе стали главами этого кейса.
- ~3 недели — полный редизайн редактора, светлая и тёмная темы одновременно
- Редизайн разблокировал разработку — команда снова смогла выпускать фичи
- AI-генерация изображений внутри билдера, с историей промптов, спроектирована мной
- Один продукт, три главы — редизайн редактора, дизайн-система под ним и онбординг
- продукт
- No-Code Builder — конструктор пейволлов внутри Qonversion (B2B SaaS, инфраструктура подписок для мобильных приложений)
- роль
- Продуктовый дизайнер — ведущий дизайнер интерфейсов продукта
- команда
- Head of Product, тимлид разработки, CEO, фронтенд-инженеры
- сроки
- Редизайн сдан за ~3 недели, затем год фичевых флоу
- что сделано
- Редизайн редактора в двух темах, собственный UI-кит билдера, галерея шаблонов, multi-page editing, платежи, генерация изображений нейросетью
- результат
- 26+ флоу выпущено за год
Глава 01
Редизайн редактора
Билдер, который я получила, и что изменили три недели редизайна.
Первая версия была тёмной, визуально сырой и явно собранной в спешке. Но под этой поверхностью лежала по-настоящему проработанная система состояний компонентов — типы действий, навигация, покупка и восстановление покупок, всё описано. Поверхность сохранять не стоило. Логику — стоило.
Поэтому редизайн не был перекраской. Я пересобрала редактор целиком и рисовала светлую и тёмную темы одновременно: каждый компонент сразу рождался в двух видах, и разработчикам не приходилось додумывать второй. Это заняло около трёх недель.
AI внутри продукта: генерация изображений
Задачу на генерацию изображений принёс Head of Product, а проектировала её я: пользователь получает арт для пейволла по промпту, а билдер хранит историю промптов, чтобы результат можно было найти снова и доработать. Проектировать генеративную функцию — значит в основном проектировать неопределённость: ожидание, ошибку, версии и момент, когда человек хочет вернуть предыдущую попытку.
С кем работала
- Head of Product — ревью макетов, маркетинговая аналитика решений
- Тимлид разработки и фронтенд-инженеры — брейнстормы по реализации фичей, обсуждение лучших решений
- CEO — приносил идеи фич
Файл хранит следы этой работы: секции со сверенными текстами, страницы ready-for-dev и датированные логи обновлений за весь год.
Глава 02
Дизайн-система под ним
Библиотека, из которой собран билдер и остальной продукт: семантические токены, компоненты в двух темах, 275 иконок.
- 2 темы — каждый компонент рисовался светлым и тёмным одновременно
- Storybook — библиотеку внедрила команда разработки
- Датированные changelog-страницы — систему вели, а не сдали один раз
- продукт
- Qonversion — B2B SaaS, инфраструктура подписок для мобильных приложений
- роль
- Продуктовый дизайнер — вела дизайн-систему целиком
- команда
- Head of Product, тимлид разработки, CEO, фронтенд-инженеры
- что сделано
- Семантические цветовые токены, библиотека компонентов в светлой и тёмной темах, типографический кит, 275 иконок, паттерны модалок и навигации
- передача
- Внедрена разработчиками в Storybook
- жизнь системы
- Позже команда перешла на shadcn/ui, и система выдержала этот переход
Основа системы — цвет, и хранится он не палитрой, а токенами по смыслу: Background, Surface, Content, Border, Action. У каждого токена два значения, для светлой темы и для тёмной, поэтому компонент ссылается на токен и ему не нужно знать, какая тема включена сейчас — тему переключает система.
Токены группы Action идут дальше и несут свои состояния: initial, hover, pressed, disabled. Именно это отличает лист с цветами от системы, которую разработчик может внедрить, не задавая отдельный вопрос про каждое взаимодействие.
Компоненты собраны поверх этого слоя, и каждый выходит сразу со всеми вариантами и состояниями, которые понадобятся в продакшене. Кнопка — это не один прямоугольник: это размер, иерархия, слоты под иконки, загрузка, disabled — и всё это дважды, потому что светлая и тёмная темы рисовались вместе, а не переносились задним числом.
Система, которая осталась живой
В файле лежат датированные страницы changelog — обновления компонентов и цветов записаны тогда, когда происходили. Это и отличает дизайн-систему от UI-кита: кто-то должен продолжать отвечать на вопросы о ней спустя месяцы. Когда команда разработки позже перешла на shadcn/ui, у системы уже был словарь токенов и компонентов — и переход оказался миграцией, а не стартом с нуля.
С кем работала
- Head of Product — ревью макетов, маркетинговая аналитика решений
- Тимлид разработки и фронтенд-инженеры — внедрение библиотеки в Storybook, брейнстормы по реализации и обсуждение лучших решений
- CEO — приносил идеи фич
Библиотеку не рисовали в вакууме и не передавали через стену: реальные страницы дашборда затаскивались обратно в файл, чтобы сверить систему с тем, что уже вышло в продакшен.
Глава 03
Онбординг для билдера
Задача звучала просто: собрать онбординг для продукта. Прежде чем рисовать первый экран, я разобрала онбординги четырёх конкурентов — и потом опиралась на этот разбор, когда защищала решения.
- Регистрация и настройка пересобраны — OAuth как полноценный вход, настройка спрашивает по одному шагу за раз
- Все состояния нарисованы — ошибки, пустые состояния, загрузка, ожидание подтверждения
- Передано в разработку готовым, в той же библиотеке, что и остальной продукт
- продукт
- Регистрация и первичная настройка Qonversion — онбординг B2B SaaS
- роль
- Продуктовый дизайнер
- команда
- Head of Product, фронтенд-инженеры
- что сделано
- Конкурентный ресёрч по 4 продуктам, новые флоу регистрации и настройки с полным покрытием состояний
- метод
- Сначала аналитика, потом разбор конкурентов, и только потом дизайн
Задача была собрать онбординг для No-Code Builder: путь от первой регистрации до продукта, который реально настроен и подключён. Урон в этом пути наносят два места — подтверждение почты, которое тихо останавливает человека ещё до старта, и сама настройка, которая просит всё сразу.
Эти находки и задали принципы дизайна. Сделать OAuth полноценным равным входом, чтобы письмо с подтверждением перестало быть шлагбаумом. Применить progressive disclosure, чтобы настройка спрашивала по одной вещи за раз, а не выкатывала стену полей. И считать привязку приложения и установку SDK настоящей целью онбординга — потому что именно в этот момент, если верить цифрам, пользователь становится платящим.
Параллельно я разобрала четыре конкурирующих продукта — Adapty, RevenueCat, AppHud и Purchasely — по одной и той же методике: sign in, sign up, dashboard. Сравнение одних и тех же трёх моментов в четырёх продуктах делает различия аргументом, а не украшением.
Новая регистрация ставит OAuth рядом с формой почты, а не прячет за ней, оставляет в форме только действительно нужные поля и несёт свои состояния ошибок и валидации как нарисованные экраны, а не как записку для разработки.
С кем работала
- Head of Product — ревью макетов, маркетинговая аналитика решений
- Фронтенд-инженеры — брейнстормы по реализации: что регистрация реально умеет и какие состояния им нужны от меня
Анализ писался в первую очередь для продуктовой команды: кейс существует потому, что аргумент был сделан внутри компании раньше, чем в портфолио.
Связаться
Открыта к ролям продуктового дизайнера: удалённо в Европе и Евразии или гибрид в Сербии. Быстрее всего написать на почту или в телеграм.