О продукте
Виджет вывода средств это часть инструментария B2B кабинета: главный интерфейс для основных финансовых операций с криптой и фиатом. Тулза на каждый день наших пользователей – мерчантов.
Задача
•
Увеличить скорость прохождения кейса
•
Снизить риск неправильной отправки
•
Снизить обращения в саппорт:
«Почему не могу включить авто выводы?»
•
Доработать текущие сценарии
•
Перевести виджет на компоненты дизайн системы
Критерии успеха
•
Рост метрики время до цели
•
Снижение количества обращений в саппорт, связанных с авто выводами
•
Снижение процента ошибок
•
Рост метрики ТТМ
Моя роль
•
Провёл ревью текущей версии
•
Подготовил гипотезы
•
Спроектировал первую версию
•
Собрал обратную связь
•
Спроектировал вторую версию
•
Подготовил компоненты для дизайн системы для новой реализации
•
Повысил эффективность и показатели продукта
Результаты
Время до цели
-32%
Новый UI (TTM)
-20%
Обращения с ошибками
-28%
Обращения в саппорт
-72%
по поводу автовыводов
Проблемы
AS IS версия работала в попапе, её основной недостаток был в том, что окно не помещалось в экран по высоте. Команда не хотела менять текущее решение т.к. это означало, долгий срок релиза. Я тщательно изучил текущую версию и собрал все боли в репорт.
Боли
V 1.0
Юзерам сложно вносить данные: окно
не влезало в экран и прыгало в высоту
при смене стейтов. Это приводило к потере фокуса, увеличивало время прохождения, плодило ошибки и жалобы в саппорт
Не было иконок монет это плодило риски неверной отправки
Виджет лимитов работал не достоверно:
показывал всегда заполненный прогресс
бар – это путало юзеров и плодило вопросы
в саппорт
Юзеры не понимали, что им мешает включить авто-выводы, т.к. сценарии на бою были
не доработаны: это нагружало саппорт
Устаревший UI: слабая контрастность шрифтов, грязные тени, не ритмичные отступы, грязный непривлекательный интерфейс
Виджет вывода средств
Было
Обновления
Дизайн система
Поскольку кабинет всё равно надо было переводить на новые компоненты, а дизайн система была прописана в роуд мапе продукта, вместе с этим кейсом мы решили запускать MVP
ДСки и последующими итерациями редизайнов наращивать компонентную базу
Итерация 01
V 1.5
В первой версии отложили поля ввода, потому что это могло вызвать большой регресс, но я добился комитмента, что апдейтом их внедрят.
Виджет вывода средств v 1.5
Стало
Решение
01
Окно перестроили в две колонки, чтобы оно влезало по высоте, а композицию полей выстроили таким образом, чтобы они последовательно продолжали друг друга – это ускорило ввод
02
Добавили иконки монет и сети это снизило обращения с ошибками
03
Починили виджет лимитов – юзеры перестали задавать вопросы:
«Как это работает?»
04
Добавили подсказки
05
Добавили сценарий авто-выводов
(об этом подробнее ниже)
Показатели
Время до цели: -39%
Обращения с ошибками: -13%
Доработка сценариев
Стало
Сценарии блокеры
Spend control
Auto Exchange
Решение
01
В первой версии не были обработаны сценарии блокеры: такие сценарии
не позволяли активировать авто-вывод
02
Управление отключением блокер опций не было связано в интерфейсе напрямую с виджетом. Как следствие большое количество вопросов
со стороны юзеров и нагрузка
на саппорт. Я выпрямил сценарии, добавив уведомление и контрол управления внутрь самого виджета.
Показатели
Обращения в саппорт
по поводу «Почему не могу включить авто выводы?»: -61%
Бейджик auto на плашке аккаунта
Решение
01
В первой версии после активации
авто-выводов интерфейс никак
не подсвечивал юзеру, что выбранная монета теперь подключена к авто-выводу. Разумеется, это плодило вопросы и ошибки.
02
Добавили бейджик на плашку, выбранной монеты и снизили процент ошибок и нагрузку на саппорт
Результат: успешные изменения,
основные показатели успеха и боли закрыты, но на конечное решение
повлиял внешний фактор, в лице
новых требований регулятора...
Показатели
Обращения с ошибками: -10%
Новые вызовы
V 1.6
Усиленные требования регулятора
Внесли свои корректировки в текущую версию, обязывая нас собирать данные о получателях это означало, что количество полей сильно увеличится!
Боли
Версия оказалась хорошей в текущей реализации, но к сожалению, плохо масштабируемой. Никто не ждал, что
полей может стать в несколько раз больше!
В первой срочной итерации был добавлен попап поверх текущего окна: костыль был вынужденным, потому что от скорости зависила лицензия и репутация компании
Итерация 02
V 2.0
После имплементации промежуточной версии надо было пересобрать сценарий с учётом всех новых вводных, чтобы флоу не получился слишком длинным и сложным, мы с командой приняли решение использовать drawer
Стало
Про решение
01
Drawer обладал рядом преимуществ перед попапом: он использовал всю высоту экрана
02
Предсказуемый объём работы для юзера. После прокрута вниз сразу было понятно сколько полей надо заполнить
03
Полей можно было добавлять сколько угодно (drawer удобно скролить)
04
Мы отказались от разделения на шаги, чтобы юзера понимали взаимосвязь выбора и переключений разных UI контроллов в моменте
05
Предыдущая версия дала нам понять, что вертикальное заполнение полей некоторым юзерам казалось удобней. Поэтому мы вернулись к одной колонке!
06
Drawer хорошо подходил для других подобных кейсов, поскольку остальные окна в кабинете не были переделаны под новый формат. Решение можно было масштабировать
Показатели
Время до цели: -32% (показатель стал чуть хуже поскольку добавились новые поля)
Обращения с ошибками: -28%
Обращения в саппорт по поводу «Почему не могу включить авто выводы?»: -72%
Новый UI (TTM): -20%
Результаты
После завершения вёрстки, мы быстро собрали группу из 8 респондентов и дополнительно проверили наше решение с помощью коридорных исследований.
Это позволило нам улучшить тексты в интерфейсе
и дополнительно удостовериться, что данное решение действительно лучше предыдущего
V 1.5
Показатели
Время до цели: -39%
Обращения с ошибками: -23%
Обращения в саппорт по поводу
«Почему не могу включить авто выводы?»: -61%
V 2.0
Показатели
Время до цели: -32%
Обращения с ошибками: -28%
Обращения в саппорт по поводу
«Почему не могу включить авто выводы?»: -72%
Новый UI (TTM): -20%
Метрики успеха
Время до цели
-32%
Новый UI (TTM)
-20%
Обращения с ошибками
-28%
Обращения в саппорт
-72%
по поводу автовыводов
Выводы
Этот кейс подчёркивает то, как важно учитывать
внешние факторы при проектировании и не забывать,
что масштабируемость очень важное качество интерфейса даже в тех кейсах, где это кажется
не таким важным!
Командная работа и измеримые показатели вместе
с качественными исследованиями помогли нам добиться улучшения опыта юзеров, а так же результатов, направленных на развитие бизнеса
