ВТБ Подарочные сертификаты
📲 Mobile APP & WEB
Частые действия без выхода из банка
Найти программу, понять условия, выбрать категории и увидеть результат в привычном контексте ДБО.
00:00
Mar 29, 2026
Спроектировала ключевые сценарии программы лояльности внутри мобильного банка
Основные функции программы находились во внешнем кабинете партнёра. Задача — вернуть наиболее востребованные действия в привычный контекст приложения, не дожидаясь полного переноса процессинга.
Category:
📲 Mobile App, Loyalty
/* Problem */
Программа ощущалась как отдельный от банка сервис
Единственную точку входа было сложно заметить, внешний кабинет менял навигацию и разрывал путь, а информации о категориях, MCC и механике бонусов не хватало для уверенного действия.
Как перенести ключевую ценность программы в ДБО, не дожидаясь полного переноса процессинга?
/* Task framing */
Разложила задачу на ценность, ограничения и критические вопросы
До перехода к макетам я зафиксировала, что должно измениться для клиента, какую пользу ждёт бизнес и где проходит техническая граница первой версии.
Поддержать карточную активность
Сделать ценность программы заметнее, улучшить клиентский путь и повысить частоту взаимодействия с ДБО.
Не ждать полной миграции процессинга
Ключевая логика оставалась у внешнего партнёра, а полный перенос затрагивал несколько банковских систем.
Найти достаточную границу первой версии
Выбрать сценарии, которые уже дают клиенту ценность и при этом реалистичны для частичной интеграции.
/* Primary research */
Собрала общую картину продукта до проектирования интерфейса
Исследование шло от центральной задачи к четырём слоям: поведению клиентов, проблемам текущего пути, рыночным паттернам и реальным ограничениям интеграции.
Продуктовые данные
Три месяца статистики помогли сравнить востребованность ключевых сценариев.
Usability и обращения
Проблемы сгруппировали по встречаемости и критичности.
Лояльность внутри ДБО
Какие действия стоит перенести первыми, чтобы убрать главный разрыв пути?
Конкурентный CJM
Сравнили точки входа, подачу выгоды и раскрытие условий программы.
Правила и архитектура
Сопоставили AS IS и TO BE, зависимости систем и контур партнёра.
/* Evidence */
Что подтвердили данные и исследование
Команда сопоставила продуктовую статистику за декабрь, январь и февраль, обращения клиентов и сотрудников, конкурентный CJM-анализ, usability-тестирование, правила программы и интеграционные ограничения.
- месяца продуктовых данных
- 3
- UX-проблем оценены по встречаемости и критичности
- 9
- инициатив сформированы
- 7
Самая частая проблема в материалах usability.
Возврат из кабинета партнёра разрывал путь.
Клиентам не хватало объяснения получения и траты бонусов.
Сценарий переставал ощущаться частью мобильного банка.
Числа показывают встречаемость проблемы в материалах usability, а не количество уникальных пользователей.
Главный вывод
Выбор категорий оказался самым востребованным из рассматриваемых сценариев. Поэтому именно он стал ядром первого релиза.
/* Hypotheses */
Какие гипотезы следовали из исследования
Каждая гипотеза связывала наблюдаемую проблему с изменением поведения и конкретной частью будущего интерфейса.
Две точки входа повысят заметность
Если показать программу на главном экране и в профиле карты, клиенту будет проще найти её в нужном контексте.
Выбор категорий стоит перенести в ДБО
Если самый востребованный сценарий останется внутри банка, путь станет короче и перестанет зависеть от внешней навигации.
Условия нужны в момент выбора
Если рядом со ставкой показать срок, ограничения и MCC, пользователю будет легче принять решение до подтверждения.
Состояния лимита защитят от ошибок
Если интерфейс объясняет неполный выбор и блокирует лишние категории, правила программы становятся предсказуемыми.
Deeplink сохранит полезный объём первой версии
Если второстепенные функции оставить во внешнем контуре, ключевой сценарий можно спроектировать без полной миграции процессинга.
/* Validation */
Сопоставила гипотезы с данными, usability и ограничениями системы
Пять источников дали разные типы свидетельств: продуктовые сигналы, наблюдаемое поведение и техническая реализуемость должны были указывать в одну сторону.
Категории важнее обмена бонусов для первой версии
Масштаб использования выбора категорий заметно выше сценария обмена. Это стало аргументом в пользу H02.
Заметность и возврат требуют отдельного решения
Скрытый вход и разрыв при возврате получили наибольшую встречаемость. Это поддержало H01 и H02.
Условия нельзя прятать от сценария
Вопросы о категориях, MCC и механике бонусов стали аргументом в пользу H03.
Контекстные точки входа уже стали рыночным паттерном
Сценарии конкурентов поддержали размещение программы на главном экране и в профиле продукта.
Частичная интеграция реалистичнее полной миграции
AS IS и TO BE показали зависимости от партнёрского процессинга и обосновали H05.
/* Competitor review */
Взяла из рынка работающие паттерны, а не готовый интерфейс
Конкурентный CJM помог понять, где клиенты ожидают увидеть лояльность и как банки объясняют выгоду. В решение перенесла принципы, которые отвечали проблемам Уралсиба.
Главный экран и профиль продукта
Несколько точек входа сокращают поиск. Для Уралсиба этот паттерн стал ответом на самую частую UX-проблему.
Единая рамка «Выгода»
Бонусы понятнее, когда связаны с пользой для клиента, а не показаны как отдельный технический сервис.
Кешбэк в общей ценности отношений с банком
Категории и начисления поддерживают карточный контекст, а не уводят пользователя в отдельный продукт.
MCC доступен по запросу
Документация или информационный слой помогают не перегружать список категорий и сохраняют детали рядом с выбором.
/* User flow */
Собрала основной путь и развилки до отрисовки экранов
Flow отделяет действия клиента от решений системы. Так в макеты сразу попали eligibility, разные периоды, лимит выбора и передача данных партнёру.
Главный экран или профиль карты
Пользователь открывает программу в контексте ДБО.
Проверка участия и офера
Доступность зависит от статуса клиента и набора продуктов.
Бонусный раздел
Баланс, период, условия и следующее доступное действие.
Категории и детали
Ставка, ограничения, MCC и дата начала действия.
Проверка лимита
До лимита выбор можно продолжить, после него остальные категории блокируются.
Фиксация выбора
Пользователь подтверждает набор и не может изменить его после отправки.
Передача партнёру и успех
Система сохраняет выбор и показывает активные категории.
На узком экране схему можно прокрутить по горизонтали.
При прекращении участия пользователь видит объяснение вместо выбора.
С 27-го числа могут быть доступны предложения на текущий и следующий месяц.
После достижения доступного лимита остальные категории становятся недоступны.
Функции вне первой версии продолжаются по предсказуемому deeplink.
/* Metrics */
Определила, как проверять эффект после запуска
Фактические продуктовые показатели после запуска в доступных материалах не зафиксированы. Поэтому здесь показан план измерения: основная метрика, её драйверы и защитные показатели.
Завершение выбора категорий
Доля подтверждённых выборов среди начатых сценариев.
Подтверждения / начала выбора
Заметность и понятность пути
CTR двух точек входа, открытия среди eligible-клиентов, просмотр условий, время до подтверждения и выходы по шагам.
Стабильность интеграции
Ошибки получения офера, сбои передачи выбора партнёру, непреднамеренные выходы и обращения по условиям.
Baseline и целевые значения можно зафиксировать после настройки событий и первого стабильного периода наблюдения.
Как выбрали границу первой версии
Полный перенос процессинга затрагивал несколько систем и требовал отдельного проекта. Два направления сравнили по пользовательской ценности, интеграционной сложности и возможности вывести первую версию без полной миграции.
Обновить внешний кабинет
Приблизить интерфейс партнёра к дизайн-системе банка и добавить новые точки входа.
Направление исправляло локальные UX-проблемы, но сохраняло главный разрыв: частые действия оставались во внешнем продукте.
Частично интегрировать программу
Перенести частые сценарии в мобильный банк, не дожидаясь полной миграции процессинга.
Это направление стало основой production-экранов. Партнёрские функции остались во внешнем контуре, чтобы не блокировать первую версию.
Превратила выбранную стратегию в production-экраны
Я спроектировала пользовательские сценарии и состояния, подготовила макеты в светлой и тёмной темах, собрала интерактивные прототипы, представила концепцию бизнесу и доработала её по обратной связи.
Каждое решение отвечает на найденную проблему
Незаметный вход, недостаток условий программы и зависимость от внешнего контура получили отдельный ответ в целевом пользовательском пути.
/* Discoverability */
Сделала программу заметной в контексте карты
На главном экране и в профиле карты появились две точки входа. Внутри раздела объединены бонусный баланс, начисления, условия периода, прогресс и подсказки следующего действия.
/* Core scenario */
Выбор категорий стал ядром первого релиза
Пользователь выбирает категории в пределах доступного лимита на текущий или следующий месяц, видит ставку, условия, ограничения и MCC, а затем подтверждает выбор. Я проработала неполный и подтверждённый набор, блокировку после достижения лимита и детали в bottom sheet без выхода из сценария.
/* Key constraint */
Провела понятную границу между системами
История бонусных операций, компенсация покупок, путешествия и партнёрские сервисы зависят от внешней платформы и остаются доступны по deeplink. Так первая версия не пытается сразу перенести весь продукт, но делает переход между системами предсказуемым.
Состояния важнее happy path
Production-экраны учитывают изменения данных и условий программы, а не только основной путь.
Периоды
Текущий и следующий месяц могут отображаться одновременно.
Сегменты
Новый и действующий клиент получают разные предложения.
Выбор
Неполный набор, подтверждение и блокировка после лимита.
Начисления
Предварительные и окончательные значения разделены.
Eligibility
Учтены изменение продуктов и отсутствие подходящей карты.
Внешний контур
Функции вне MVP сохраняют понятный переход по deeplink.
/* Outcome */
Что было готово по итогам работы
Я собрала согласованную продуктовую концепцию, production-экраны и интерактивные прототипы для ключевых сценариев программы.
- точки входа
в программу - 2
- групп продуктовых
состояний - 6
- темы интерфейса
проработаны - 2
Сфокусировала первый релиз
Выбор категорий стал ядром первой версии, а бонусы и прогресс — следующим этапом развития.
Собрала ключевые сценарии в ДБО
Спроектировала две точки входа и связала бонусный баланс, категории, условия программы и подсказки следующего действия.
Проработала сложные состояния
Учла шесть групп состояний: периоды, сегменты, выбор, начисления, eligibility и внешний контур.
Согласовала продуктовую концепцию
Подготовила production-экраны в светлой и тёмной темах, собрала прототипы и доработала решение по обратной связи бизнеса.
/* Takeaway */
