Редизайн верификации* в Aximetria
*Верификация — процедура подтверждения личности. Широко используется в любых сервисах, связанных с необходимостью совершения денежных операций.
Aximetria – финансовый сервис со швейцарской лицензией, предоставляющий криптоуслуги для частных и корпоративных клиентов в Европе и некоторых странах Азии.
- Product Design
- User testing
- CJM / Userflow / Wireframes
- Fintech
- Размер проекта: средний
- Mobile / B2C
Контекст
Фаундер стартапа Aximetria незадолго до публичного запуска сервиса на широкую аудиторию обратился ко мне с запросом на улучшение основных пользовательских сценариев (уже реализованных в MVP). Аналитика показывала плохую конверсию при прохождении из зарегистрированных пользователей в верифицированных, и гипотеза состояла в том, что можно расширить эту воронку средствами дизайна. Также нужно было проверить, насколько хорошо реализованы в приложении остальные сценарии.
Бизнес-цели
- Повысить конверсию в верифицированных пользователей.
- Улучшить остальные сценарии.
- Успеть внедрить редизайн к полноценному публичному запуску сервиса на широкую аудиторию (🤯 т.е. уже через две недели!).
Дизайн-задачи
- Выявить все UX-проблемы в реализованных сценариях.
- Спроектировать решение, устраняющее UX-проблемы и пользовательские барьеры.
- Собрать впечатления пользователей и уточнить их ожидания от приложения.
Я решил, что лучше всего справиться с этими задачами поможет модерируемое UX-тестирование на потенциальных пользователях сервиса. Оно позволит увидеть вживую, как люди взаимодействуют с приложением и с какими трудностями при этом сталкиваются.
Ожидаемый результат
Я хотел, чтобы результатом работ был не только отчет о проведенном тестировании или красивая презентация (с которыми потом непонятно, что делать, как это обычно бывает, когда UX-тесты проводит стороннее агентство), а размещенный в бэклоге набор задач на ближайшие спринты, который давал бы команде разработчиков четкие ответы на вопросы, какие проблемы нужно решать, как именно, и в каком порядке:
UX-тестирование
Из шести реализованных в приложении сценариев три оказались легкими (не было заметных трудностей при их прохождении), два проблемными (респонденты испытывали очевидные трудности, но справились с ними сами и в результате дошли до цели) и один — блокирующим (часть респондентов не смогла пройти его ни с первого, ни со второго раза, а те, кто смог, все равно испытали по пути много боли).
Блокирующим оказался самый важный сценарий — Верификация, без успешного прохождения которого нельзя было начать получать ценность от сервиса. UX-тестирование наглядно показало, почему.
Барьеры верификации
Форма верификации была спроектирована самым, казалось бы, простым способом — единым экраном с полями ввода, разбитыми на 3 группы:
- About you (личная информация),
- ID Document type (документы, удостоверяющие личность),
- Residence Address (место проживания).
Пользователь должен был последовательно заполнить поля в каждом блоке, после чего отправить данные на проверку и ожидать сообщения о завершении процедуры. Казалось бы, что здесь может пойти не так? Однако «не так» пошло много чего.
Часть респондентов не смогла пройти верификацию с первой попытки. Они повторяли процедуру, пока в конце концов не прошли ее, что было уместно в рамках теста, но менее вероятно в реальной жизни.
- С первой попытки верификацию прошли четыре из восьми респондентов
- Со второй попытки ее прошел только один
- С третьей — два
- Один вообще не смог пройти сценарий, как ни пытался
Zoom In
Проблемы поэкранно
Проектируем решение
Все найденные проблемы можно условно объединить в три группы: «Непонятно», «Небезопасно» и «Неудобно». Что со всем этим можно сделать?
Картируем текущий путь
Составляем CJM текущего сценария и добавляем на него все найденные на тестировании барьеры, гипотезы по их преодолению и возможные фичи, которые могут реализовать эти гипотезы в коде.
Конкретизируем решения, группируя барьеры, идеи и фичи на каждом шаге текущего сценария
Корректируем сценарий
Как видно на CJM, идей получилось много — больше, чем барьеров. Реализовать их все сразу точно не получится (да это и не надо). Чтобы решить, какие берем в реализацию, а какие пока откладываем, необходимо совместно с командой расставить им приоритеты. Для этого раскладываем их по матрице Impact/Effort — выбираем идеи, которые лучше всего балансируют между простотой реализации и эффективностью:
В работу идут идеи из правого верхнего участка
Теперь обновим сам сценарий: нарисуем скорректированный юзерфлоу, разложим выбранные идеи по преодолению барьеров на соответствующих шагах. Эта схема процесса послужит нам гидом для последующей проработки экранов обновленного сценария.
Логика перемещения между шагами и экранами, с отображаемыми параметрами на каждом экране
Визуализируем интерфейс
Схема готова, а это значит, что основная, самая трудная часть работы сделана! Осталось приятное — покрыть экранами с финальным дизайном все шаги нового юзерфлоу и показать логику переходов между ними:
Поэкранная схема переходов в финальном дизайне
Zoom In: экраны
Измеряем результат
К чему в итоге привел редизайн:
Выводы
💪 На этом проекте я понял, что мы способны силами внутренней команды проводить пользовательские тестирования продуктов быстрее и дешевле, чем стороннее агентство, в условиях отсутствия в компании постоянного выделенного ресурса UX-исследователя.
😍 Мне удалось погрузить команду Aximetria в пользовательский контекст и таким образом вырастить эмпатию.
🤝 Удалось повысить кредит доверия дизайн-команды билдера (от других продактов портфельных компаний сразу посыпались запросы на проведение пользовательских тестирований для их продуктов).
🧠 Этот опыт стал первым в последующем регулярном обучении сотрудников билдера основам ux-исследований и положил начало системному развитию Т-образных навыков внутри команды.
← Назад
Вперед →