Автоплатежи и автопереводы в Райффайзен Банк
Как были спроектированы сценарии регулярных платежей, чтобы пользователи могли автоматизировать рутину, но не теряли ощущение контроля над деньгами.
Задача
Проект выполнен для мобильного приложения Райффайзен Банка.
На момент работы над проектом функциональность автоплатежей уже существовала в веб-версии банка, но отсутствовала в мобильном приложении. Из-за этого пользователям приходилось выполнять регулярные операции вручную или переходить в веб-версию.
Задача проекта — спроектировать удобный сценарий автоплатежей и автопереводов в мобильном приложении: от подключения и настройки до уведомлений и управления созданными платежами.
Что было сделано
- Анализ текущего функционала автоплатежей в веб-версии Райффайзенбанка;
- Конкурентный анализ веб-версий и мобильных приложений банков: Сбер, Тинькофф, Альфа-банк;
- Изучение фидбека пользователей банков-конкурентов из открытых источников;
- Проведение глубинного интервью с пользователями для выявления их потребностей и трудностей, проверка гипотез;
- Проектирование user-flow пользователя и дальнейшая отрисовка готовых макетов;
- Создание прототипа для тестирования макета, доработка дизайна согласно полученному фидбеку.
Проблема
1. Регулярные платежи приходилось выполнять вручную
Пользователи регулярно оплачивают одни и те же услуги: мобильную связь, интернет, коммунальные платежи, подписки или переводы на накопительные счета.
Без автоплатежей эти операции приходилось держать в голове и выполнять вручную. Это создавало риск забытых платежей, просрочек, отключения услуг или потери бонусов.
Для банка отсутствие такой функции в мобильном приложении снижало удобство продукта: пользователь мог выполнять основные операции с телефона, но регулярные сценарии всё ещё оставались неполными.
2. Снижение конкурентоспособности продукта
На момент работы над проектом автоплатежи и автопереводы были доступны только в веб-версии банка. При этом всё больше пользователей переходили на мобильное приложение и ожидали, что смогут выполнять в нём все основные финансовые операции без необходимости использовать дополнительные каналы.
Из-за отсутствия функции в мобильном банке пользователям приходилось переключаться между приложением и веб-версией, а продукт уступал конкурентам, которые уже поддерживали управление регулярными платежами со смартфона. Поэтому задача заключалась не просто в переносе существующей функциональности, а в проектировании полноценного мобильного сценария.
Исследование
Чтобы понять, как спроектировать функцию, я использовал несколько источников данных:
- Анализ веб-версии;
- Конкурентный анализ;
- Отзывы пользователей;
- Интервью.
Цель исследования — понять не только какие поля нужны в форме, но и какие сомнения возникают у пользователя до, во время и после подключения автоплатежа.
Анализ веб-версии
Сначала я изучил существующую логику автоплатежей в веб-версии банка. Это помогло понять, какие сущности уже есть в продукте, какие типы платежей нужно поддержать и какие сценарии важно сохранить при переносе в мобильное приложение.
При этом мобильный сценарий нельзя было просто скопировать из веба: на телефоне выше требования к скорости, ясности и компактности интерфейса.
Конкурентный анализ
Я провел анализ функций автоплатежей и автопереводов в мобильных и веб-приложениях ведущих российских банков:
- Сбер Банк;
- Тинькофф Банк;
- ВТБ;
- Альфа-банк.
Анализ отзывов пользователей
В ходе исследования я изучил отзывы у конкурентов на площадках Отзовик, Банки.ру и Сравни.ру, а также в Play Market и App Store.
С одной стороны, пользователи ценят автоплатежи, потому что они экономят время и помогают не забывать о регулярных расходах.
С другой стороны, негативные отзывы чаще всего были связаны с ошибками, недостатком прозрачности и сложностью управления: платёж не сработал, уведомления не было, изменить сумму или дату оказалось трудно, отключение было спрятано слишком глубоко.
Это подтвердило, что доверие к функции зависит не только от успешного создания автоплатежа, но и от дальнейшего контроля.
Интервью с пользователями
Я провёл 8 интервью. Средняя длительность интервью — около 25 минут. В интервью я выяснял:
- Какие регулярные платежи пользователи совершают чаще всего;
- Используют ли они автоплатежи сейчас;
- Где ожидают найти такую функцию в приложении;
- Чего боятся при подключении автоматических списаний;
- Какие уведомления считают важными;
- Как хотели бы редактировать или отключать автоплатежи.
Интервью помогли увидеть, что пользователи в целом готовы доверять банку регулярные операции, но только если интерфейс заранее объясняет условия, показывает будущие списания и даёт простой способ управлять платежами.
Проектирование
Гипотезы
- Если уведомлять пользователей о предстоящих списаниях за сутки, то это даст им больше контроля над автоплатежами и улучшит управление финансами, потому что они смогут заранее спланировать свой бюджет и отменить ненужные платежи.
- Если сделать настройку расписания автоплатежей более гибкой (минимальный остаток, график списаний), то пользователи смогут подключать больше автоплатежей, потому что это позволит им лучше адаптировать расходы под свои финансовые потребности.
- Если разместить информацию об автоплатежах на главной странице, то это увеличит количество пользователей, подключающих автоплатежи, потому что они быстрее заметят эту функцию и смогут легко ознакомиться с ее возможностями.
- Если добавить возможность просматривать список всех автоплатежей и автопереводов, то это улучшит управление пользователем своими списаниями и усилит его чувство контроля, потому что он сможет заранее планировать бюджет и отменять неактуальные автоплатежи.
- Если отправлять уведомления о неудачном списании автоплатежа, то это повысит лояльность и доверие пользователей к сервису, потому что они смогут оперативно решить проблему и избежать штрафов, потери бонусов или задержек в оплате.
- Если предоставить возможность отмены автоплатежа в течение 15 минут после списания средств, то это повысит доверие к автоплатежам и увеличит количество пользователей, потому что они будут уверены, что могут вернуть деньги, если случайно забыли о платеже или передумали.
User Flow
Для проектирования был построен User Flow, который помог увидеть полный путь пользователя: от первого контакта с функцией до управления уже созданными платежами.
Это позволило не ограничиваться формой создания и заранее учесть весь жизненный цикл автоплатежей и автопереводов.
Решение
Точки входа
Чтобы функция не потерялась внутри приложения, я предусмотрел 2 точки входа.
Первая — через истории на главном экране. Этот формат подходит для знакомства с новой функцией и объяснения пользы простым языком.
Вторая — через раздел «Переводы и платежи», где пользователи ожидают найти регулярные финансовые операции.
Раздел автоплатежей и автопереводов
Этот раздел предоставляет возможность настроить автоплатежи и автопереводы, а также содержит их краткое описание. Также тут есть возможность перейти к списку автоплатежей и автопереводов.
Цель раздела — быть не просто точкой создания, а центром управления регулярными финансовыми действиями.
Создание автоплатежа по балансу
Автоплатёж по балансу нужен для сценариев, где важно пополнять счёт при снижении остатка. Например, мобильная связь: если баланс становится ниже заданной суммы, банк автоматически пополняет его на выбранную сумму.
Я добавил преднастроенные суммы, чтобы ускорить заполнение, и финальный экран проверки, чтобы пользователь мог ещё раз увидеть условия перед подключением.
Создание автоплатежа по расписанию
Автоплатёж по расписанию подходит для регулярных платежей с понятной датой: например, раз в месяц, раз в неделю, ежедневно или в последний день месяца.
В этом сценарии особенно важно заранее показать дату ближайшего списания, потому что пользователь должен понимать, когда автоматизация начнёт работать.
Создание автоперевода
Автоперевод решает другую задачу: не оплату услуги, а регулярное перемещение денег между счетами.
Логика сценария сохранена общей с автоплатежами, чтобы сценарии были предсказуемыми: выбор параметров → проверка условий → подтверждение → экран успеха.
Экран успеха
Экран успеха дополнил сценарий ключевой информацией о подключённом платеже: условием списания, ближайшей датой и возможностью дальнейшего управления.
CTA-кнопка была переименована, чтобы пользователь понимал следующий шаг, а отдельная кнопка ведёт к списку автоплатежей и автопереводов.
Список автоплатежей и автопереводов
Список объединяет активные и отключённые автоплатежи и автопереводы, показывает ключевую информацию по каждому сценарию и общую сумму регулярных списаний за месяц.
Пользователь может быстро перейти в детали платежа, изменить условия, отключить, восстановить или удалить его, а также создать новый сценарий через CTA-кнопку.
Bottom sheet
Для пользователей, которые регулярно совершают одинаковые платежи или переводы, предусмотрено диалоговое окно с предложением подключить автоплатёж или автоперевод.
Оно появляется в контексте повторяющегося действия и помогает пользователю быстрее перейти от ручной операции к автоматическому сценарию.
Stories
Для знакомства с новой функцией на главном экране предусмотрены stories.
Они коротко объясняют пользу автоплатежей и автопереводов, показывают основные сценарии использования и помогают привлечь внимание к разделу без перегрузки интерфейса.
Push-уведомления
Push-уведомления помогают пользователю оставаться в контексте после подключения автоплатежа или автоперевода.
Они заранее предупреждают о списании, сообщают об успешных действиях и помогают быстро заметить проблему, если платёж не прошёл.
Тестирование
После проектирования было проведено коридорное тестирование основного сценария — создания автоплатежа. В тестировании приняли участие 8 человек. Участникам предлагалось самостоятельно подключить автоплатеж и объяснить, как они будут управлять им после создания.
Все участники успешно справились с задачей.
Итог
В рамках проекта был спроектирован полный сценарий автоплатежей и автопереводов для мобильного банка: от знакомства с функцией и её подключения до уведомлений и управления регулярными операциями.
Основной акцент был сделан на балансе между автоматизацией и контролем. Пользователь может избавиться от рутинных действий, сохраняя при этом прозрачность всех операций и возможность быстро изменить настройки.
Решение прошло коридорное тестирование, подтвердило понятность основного сценария и готово к передаче в разработку.