Logo
  • Кейсы
  • Работы
  • Обо мне
  • Процесс
  • Принципы
  • Связаться

Sunlight

Aximetria

SnapSpace

Factorin

Feedback framework

Design Meetup

My resume

Logo

Кейсы

Работы

Обо мне

Процесс

Принципы

Связаться

© 2026 nnadzharov.pro

TelegramLinkedInWhatsApp
Aximetria

Aximetria

Редизайн верификации в Aximetria

Обновленные экраны сценария верификации
Обновленные экраны сценария верификации
Aximetria – финансовый сервис со швейцарской лицензией, предоставляющий криптоуслуги для частных и корпоративных клиентов в Европе и некоторых странах Азии.
  • Product Design
  • User testing
  • CJM / Userflow / Wireframes
  • Fintech
  • Размер проекта: средний
  • Mobile / B2C

Контекст

Аналитика показывала низкую конверсию при прохождении из зарегистрированных пользователей в верифицированных, и необходимо было расширить эту воронку. Также нужно было проверить, насколько хорошо реализованы в приложении остальные сценарии.

Воронка в виде «бокала мартини» — признак проблем в юзерфлоу
Воронка в виде «бокала мартини» — признак проблем в юзерфлоу

Бизнес-цели

  • Повысить конверсию в верифицированных пользователей.
  • Улучшить остальные сценарии.
  • Успеть внедрить редизайн к полноценному публичному запуску сервиса на широкую аудиторию (🤯 т.е. уже через две недели).

Дизайн-задачи

  • Выявить все UX-проблемы в реализованных сценариях.
  • Спроектировать решение, устраняющее UX-проблемы и пользовательские барьеры.
  • Собрать впечатления пользователей и уточнить их ожидания от приложения.

Я решил, что лучше всего справиться с этими задачами поможет модерируемое UX-тестирование на потенциальных пользователях сервиса. Оно позволит увидеть вживую, как люди взаимодействуют с приложением и с какими трудностями при этом сталкиваются.

Ожидаемый результат

Я хотел, чтобы результатом работ был не только отчет о проведенном тестировании или красивая презентация (с которыми потом непонятно, что делать, как это обычно бывает, когда UX-тесты проводит стороннее агентство), а размещенный в бэклоге набор задач на ближайшие спринты, который давал бы команде разработчиков четкие ответы на вопросы, какие проблемы нужно решать, как именно, и в каком порядке:

Проекция ожидаемого результата — спланированный список задач в таск-трекере
Проекция ожидаемого результата — спланированный список задач в таск-трекере

UX-тестирование

Из шести реализованных в приложении сценариев три оказались легкими (не было заметных трудностей при их прохождении), два проблемными (респонденты испытывали очевидные трудности, но справились с ними сами и в результате дошли до цели) и один — блокирующим (часть респондентов не смогла пройти его ни с первого, ни со второго раза, а те, кто смог, все равно испытали по пути много боли).

#
Сценарий
Критичность
1

Регистрация

Легкий
2

Верификация

Блокирующий
3

Создать кошелек

Легкий
4

Пополнить кошелек фиатом с карты

Проблемный
5

Отправить адрес с кошелька

Легкий
6

Отправить валюту на другой кошелек

Проблемный

Блокирующим, как и ожидалось, оказался самый важный сценарий — верификация, без успешного прохождения которого нельзя было начать получать ценность от сервиса. UX-тестирование наглядно показало, почему.

«Тепловая карта» пользовательского пути. Красным отмечена проблемная зона сценария
«Тепловая карта» пользовательского пути. Красным отмечена проблемная зона сценария

Барьеры верификации

Форма верификации была спроектирована самым, казалось бы, простым способом — единым экраном с полями ввода, разбитыми на 3 группы:

  1. About you (личная информация),
  2. ID Document type (документы, удостоверяющие личность),
  3. Residence Address (место проживания).
Форма верификации As Is. Какие ux-проблемы вы видите на этих экранах?
Форма верификации As Is. Какие ux-проблемы вы видите на этих экранах? Это вопрос с подвохом — невозможно узнать обо всех проблемах, просто разглядывая экраны.

Пользователь должен был последовательно заполнить поля в каждом блоке, после чего отправить данные на проверку и ожидать сообщения о завершении процедуры. Казалось бы, что здесь может пойти не так? Однако «не так» пошло много чего.

Часть респондентов не смогла пройти верификацию с первой попытки. Они повторяли процедуру, пока в конце концов не прошли ее, что было уместно в рамках теста, но менее вероятно в реальной жизни.

Попытки пройти верификацию, по респондентам
Попытки пройти верификацию, по респондентам
  • С первой попытки верификацию прошли четыре из восьми респондентов
  • Со второй попытки ее прошел только один
  • С третьей — два
  • Один вообще не смог пройти сценарий, как ни пытался

Zoom In

‣
Трудности, с которыми столкнулись респонденты (раскрыть список):
Проблема / затруднение
Частота
Критичность

Не очевидна ценность верификации

3
Затруднение

Сценарий проходит дольше и сложнее, чем ожидалось

8
Проблема

Сообщение о необходимости верификации в слепой зоне

4
Блокер

Запрашивается избыточная информация, вынуждая респондентов совершать лишние действия

8
Блокер

Не понятно, что нужно делать из-за невнятных названий полей ввода

7
Блокер

Делают непригодные фотографии документов, не понимая этого

6
Блокер

Опасаются делиться личными данными с малоизвестным сервисом, считая это небезопасным

3
Проблема

Не понимают, сколько ждать аппрува после отправки данных на проверку

5
Затруднение

Проблемы поэкранно

icon
Кроме проблем, оказавшимися блокерами для прохождения сценария, тестирование помогло обнаружить несколько неудобств, которые в сумме добавляли красок в общее впечатление от работы с приложением и негативно влияли на удовлетворенность и отношение к продукту в целом.

Сводная таблица с проблемами во всех сценариях →

Проектируем решение

Все найденные проблемы можно условно объединить в три группы: «Непонятно», «Небезопасно» и «Неудобно». Что со всем этим можно сделать?

‣
Сделать понятнее
  • Скорректировать нейминг элементов формы
  • Сопроводить пользователя внятными инструкциями с примерами «Правильно — Неправильно»
  • Оставить только обязательные для заполнения поля, без которых действительно невозможно обойтись
  • Дать возможность проверить результат выполнения шага по чек-листу перед тем, как пользователь сохранит документ
  • При непройденной верификации разбирать ошибки, объясняя, как их можно исправить
‣
Сделать «безопаснее»
  • Дать возможность пройти верификацию с помощью стороннего сервиса, имеющего большее доверие пользователей (напр., Яндекс-Деньги или Telegram Passport)
  • Рассказать об используемых сервисом международных стандартах безопасности хранения информации
‣
Сделать удобнее
  • Устранить лишние шаги. По возможности, сократить пользовательский путь
  • Сделать так, чтобы в любой точке сценария человек понимал, какие шаги им уже пройдены и сколько еще осталось
  • Устранить возможность совершения человеческой ошибки на уровне ОС (там, где есть техническая возможность)
  • Исправить остальные найденные минорные неудобства работы с формой

Картируем текущий путь

Составляем CJM текущего сценария и добавляем на него все найденные на тестировании барьеры, гипотезы по их преодолению и возможные фичи, которые могут реализовать эти гипотезы в коде.

Конкретизируем решения, группируя барьеры, идеи и фичи на каждом шаге текущего сценария

Корректируем сценарий

Как видно на CJM, идей получилось много — больше, чем барьеров. Реализовать их все сразу точно не получится (да это и не надо). Чтобы решить, какие берем в реализацию, а какие пока откладываем, необходимо совместно с командой расставить им приоритеты. Для этого раскладываем их по матрице Impact/Effort — выбираем идеи, которые лучше всего балансируют между простотой реализации и эффективностью:

В работу идут идеи из правого верхнего участка

Теперь обновим сам сценарий: нарисуем скорректированный юзерфлоу, разложим выбранные идеи по преодолению барьеров на соответствующих шагах. Эта схема процесса послужит нам гидом для последующей проработки экранов обновленного сценария.

Логика перемещения между шагами и экранами, с отображаемыми параметрами на каждом экране

Визуализируем интерфейс

Схема готова, а это значит, что основная, самая трудная часть работы сделана! Осталось приятное — покрыть экранами с финальным дизайном все шаги нового юзерфлоу и показать логику переходов между ними:

Поэкранная схема переходов в финальном дизайне

Zoom In: экраны

Финальные экраны перепроектированного сценария
Финальные экраны перепроектированного сценария

Измеряем результат

К чему в итоге привел редизайн:

Итоги и метрики
Итоги и метрики

Выводы

💪 На этом проекте я понял, что мы способны силами внутренней команды проводить пользовательские тестирования продуктов быстрее и дешевле, чем стороннее агентство, в условиях отсутствия в компании постоянного выделенного ресурса UX-исследователя.

😍 Мне удалось погрузить команду Aximetria в пользовательский контекст и таким образом вырастить эмпатию.

🤝 Удалось повысить кредит доверия дизайн-команды билдера (от других продактов портфельных компаний сразу посыпались запросы на проведение пользовательских тестирований для их продуктов).

🧠 Этот опыт стал первым в последующем регулярном обучении сотрудников билдера основам ux-исследований и положил начало системному развитию Т-образных навыков внутри команды.

← Назад

Мобильный каталог в Sunlight

Вперед →

Онлайн-сервис Snapspace

В этом кейсе

  • Редизайн верификации в Aximetria
  • Контекст
  • Бизнес-цели
  • Дизайн-задачи
  • Ожидаемый результат
  • UX-тестирование
  • Барьеры верификации
  • Zoom In
  • Проектируем решение
  • Картируем текущий путь
  • Корректируем сценарий
  • Визуализируем интерфейс
  • Zoom In: экраны
  • Измеряем результат
  • Выводы