Кейс от 2021 года
Верификация пользователей (часть 1)
Задача:
Радикально сократить количество не валидных документов, которые загружаются пользователями (либо не читабельные документы, скриншоты, смазанные фотографии и т.д.).
Проблемы в текущей реализации:
- Пользователь не видит, какую фотографию он сейчас загружает. (Пользователь может ошибиться при выборе фотографии, он не видит требования, которые мы предъявляем к документам)
- Если не загружена ни одна фотография, пользователь все равно можно нажать кнопку Send, страница выдаст ошибку и подсветит поля.
- После того, как пользователь нажимает на кнопку «Submit request», интерфейс не подает никаких знаков, сразу кидает на страницу с таблицей где пользователь ждет, примут его заявку или нет.
- Запрашиваем подтверждение второго документа.
Расход времени KYC (из расчета X150 заявок в смену на оператора, среднее время обработки заявки, которая будет одобрена 2,5 - 3 минуты) С 1 ноября по 9 декабря приходило от 452 до 918 заявок 26.263 тыс всего 691 в день среднее число
Анализируем конкурентов
Skrill
Как верификация работает в Skrill:
- Есть превью документа который пользователь хочет загрузить.
- Есть шаги, сначала загрузи одну сторону документа, потом другу..
- Последний шаг это сделать селфи где должно присутствовать надпись «Skrill и актуальная на момент съемки дата»
IQ optional
Как верификация работает в IQ optional:
- Перед загрузкой документов можно посмотреть видео инструкцию, так же есть описание что должно находится на документе
- Используются систему NETVERIFY
- На странице верификации можно посмотреть историю подачи документов.
ePayments
В веб верификация у них сложная. Они просят подиверждение личности и подтверждение адреса.
Мобильная версия ePayments
- Используют рамку в которую надо разместить документ
- Есть подсказка какие документы они не принимают ( эту идею мы переиспользовали у нас)
- Показывают отдельный экран где пользователь может выбрать документ по которому он хочет провести верификацию ( мне кажется, что это удобно)
Хорошую статью скинул Саша Хромов, в которой дизайнер описывает подход к проектированию флоу верификации. Слава Кривоносов и Павел Кошелев подсказали приложения в которых есть хорошие интерфейсные паттерны.
БЫСТРЫЕ РЕШЕНИЯ
После встречи с командой саппорта была выдвинута гипотеза, что убрав Proof of address мы уменьшим время обработки заявок.
Гипотеза: Убрав верификацию по второму документу, мы уменьшим время модерации заявки
Изучив конкурентов, заметили, осталось мало сервисов, которые требуют подтверждения адреса проживания.
Единственное, что нашли в договорах с платежками про KYC:
Единственное, что нашли в договорах с платежками про KYC:
Client warrants that they shall be solely responsible and liable for the Know-Your-Customer (KYC) and Know-Your-Customer Business (KYB) details of all clientele it introduces to the Platform and that in the event of fraud or where DusuPay is called upon in any issue regarding any fraudulent Card transaction or other transaction(s) of any clientele, Client shall at the request of DusuPay irrevocably and unconditionally indemnify and defend DusuPay and/or pay any damages, charges, fees and/or costs awarded against DusuPay in a resulting final judgment (including reasonable legal fees) arising out of or resulting from any claim, action or demand (collectively a “Claim”) from any clientele or Third Party
Также еще одна из гипотез: Не давать возможность пользователям загружать .png, оставить только .jpg. Возможность загрузить PDF оставляем только для Индии, т.к у них Aadhaar card, котрое государство присылает в электронном виде
Гипотеза: Сократив количество загружаемых файлов, мы сократим время обработки заявок.
Пример как выглядит Aadhaar cart
Немного статистики про соотношение форматов файлов, загруженных в заявки на верификацию за последний год: В реджектнутых заявках: 85% - JPG, 6,5% - PNG, 8,5% - PDF В одобренных: 93% - JPG, 1,2% - PNG, 5,7% - PDF
После всех изменений упали отказы по сканам с 30% до 13%.
БЫСТРЫЕ РЕШЕНИЯ
После встречи с командой саппорта была выдвинута гипотеза, что убрав Proof of address мы уменьшим время обработки заявок.
GENERAL APP
После того, как в General App появилась возможность верифицироваться, количество заявок перераспределилось. Если раньше пользователи могли загружать неподходящие фотографии только через веб версию, то сейчас начали это делать и через мобильное приложение.
Гипотеза: Если при загрузке документов через мобильное приложение выводить камеру, то это повысит качество отправляемых запросов на верификацию.
Для того, чтобы новый функционал заработал у нас, пришлось прикрутить специальный модуль камеры. Добавили рамку, в которую нужно поместить документ, а также возможность выбрать фотографии из галереи (случается, что у пользователя нет документов под рукой, но есть фотография)
После релиз камеры в General APP - 86% юзеров верифаятся с первой попытки (декабрь)
После того, как пользователь сделал фотографию, мы показываем ему экран, где спрашиваем «все нормально? она подходит под наши параметры?» Если фотография удовлетворяет заявленным нами требованиям, пользователь нажимает «Checked» и переходит на следующий шаг. В противном случае он может сделать новое фото, нажав «Retake».
Также в процессе обсуждения пришла идея показывать подсказку, какие варианты фотографий мы можем отбраковать (в первый релиз данный функционал не вошел).
Дальше флоу верификации в мобильном приложении мы не меняли. И данное поведение мы еще перенесем в приложение CopyTrade. Остается только смотреть на метрики и отзывы пользователей.
Идеи, которые можно будет реализовать позже:
- Следующим шагом после того, как пользователь загрузил фотографию паспорта, предложить ему загрузить селфи
- Анализ фотографии на пересвет и т.д
- Подключить специализированный софт, который позволяет определять селфи пользователя с документами, которые он отправил.
WEB и MOBILE
Актуальный путь верификации имеет ряд проблем, исправив которые мы повысим конверсию в прохождению верификации и разгрузим поддержку.
Актуальный путь верификации имеет ряд проблем, исправив которые мы повысим конверсию в прохождению верификации и разгрузим поддержку.
- Пользователь не видит, какую фотографию он загружает.
- Лишняя кнопка Hide, которую пользователи жмут (Если пользователю дать кнопку, он на нее нажмет, чтобы посмотреть что произойдет)
- Главная проблема в том, что пользователи присылали фотографии плохого качества, что является одной из топовых причин отклонения заявок на верификацию.
И посмотрев на пользователей наших, глазами «бога»,
Что дает возможно документы загружать.
Увидел я и не поверил взору.
Что если дать возможно что-то скрыть, на кнопочку нажать.
И пользователь нажмет, не зная толку, зачем? и для чего?
Но цель одна у них на тот момент, нажать и посмотреть.
Так же не видя, что он загружает и не отдав себе отчет, он отправляет селфи-фотографии которые приводят в ужас саппорт наш.
Всему этому надо положить конец.
Улучшить пользователя путь. И саппорт наш спасти от угнетения и печали.
Что дает возможно документы загружать.
Увидел я и не поверил взору.
Что если дать возможно что-то скрыть, на кнопочку нажать.
И пользователь нажмет, не зная толку, зачем? и для чего?
Но цель одна у них на тот момент, нажать и посмотреть.
Так же не видя, что он загружает и не отдав себе отчет, он отправляет селфи-фотографии которые приводят в ужас саппорт наш.
Всему этому надо положить конец.
Улучшить пользователя путь. И саппорт наш спасти от угнетения и печали.
Варианты документов, которые могут загрузить пользователи.
Также становится понятно с какими проблемами может столкнуться пользовать, когда проходит этап верификации на нашем сайте.
Одна из идей-гипотез заключается в том, что если пользователь будет видеть, какую фотографию он загружает, это повысит прозрачность и уменьшит количество некачественных фотографий. Также мы не даем пользователю возможно нажать на кнопку "Submit request", пока он не загрузит фотографию. Тем самым мы уменьшаем количество ошибочных нажатий.
Одна из идей-гипотез заключается в том, что если пользователь будет видеть, какую фотографию он загружает, это повысит прозрачность и уменьшит количество некачественных фотографий. Также мы не даем пользователю возможно нажать на кнопку "Submit request", пока он не загрузит фотографию. Тем самым мы уменьшаем количество ошибочных нажатий.
- Сделали кнопку Submit request не активной, до тех пор пока пользователь не загрузил фотографию. (Синяя кнопка действия смущала бы пользователей и они при нажатии получали ошибку, этого можно избежать)
- Убрали возможно сворачивать блок, на котором изображена подсказка
- Добавили подсказу для чего пользователю вообще нужно верифицировать аккаунт (раньше чтобы найти эту информацию надо было лезть в FAQ на сайте).
После того как пользователь нажал Upload front side/main page и выбрал фотографию, появляется поп-ап с просмотром того файла, который будет загружаться. Это нужно для того, чтобы пользователь еще раз убедился, что именно эту фотографию он хочет загрузить, плюс требование к фотографии.
Чему я научился
Пройдя долгий путь по выполнению этой интересной работы, я сделал несколько выводов для себя, которые, надеюсь, будут полезны и вам:
Находи вдохновение.
Не бойтесь предлагать новые идеи. Погружаться в задачу, изучить тематику, посмотреть, что делают конкуренты. Используйте все наилучшее, что имеется в источниках, например: удачные решения, тексты, иконки, какие уже есть решения в схожей проблеме, и превратите все эти кусочки пазла во что-то цельное и полезное.
Принимай критику … большую часть времени.
В большинстве случаев критика благоприятно играет на продвижение и качество работы. Мы все люди, все устаем и перестаем думать и видеть трезво. Задавай конкретные вопросы. Получая ответы, начинаешь размышлять, куда теперь двигаться дальше. Отслеживай метрики, узнавать об изменениях после реализации всех идей. Что думают пользователи? Улучшилась ли жизнь саппорта?
Что будет дальше?
Кроме решения прямых проблем, поставленных в задаче, необходимо понимать, почему возникли эти потребности, например: будет ли дизайн в дальнейшем масштабироваться, будут ли увеличиваться требования к элементам? Какие планы на развитие этого функционала дальше? Какие трудности могут возникнуть с дизайном?
Смотрю сейчас на макеты и вижу, что можно улучшить в приложении и в веб версии. Но это уже другая история. В фигме есть концепты, которые можно будет доработать позже, либо по прошествию времени выкинуть в ведро.
Что можно улучшить в работе:
- Вовлекать команду в проектирования. Причем не просто скидывать им макеты на "посмотреть", а вот именно начинать с ними прорабатывать флоу, экраны и т.д., так как во время обсуждения рождаются интересные мысли.
- Ввести в практику тестирование новых сценариев на пользователях. Сервис, который это позволяет сделать (ссылка)
- Начал использовать плагин для фигмы TODO который позволяет составлять чеклист который хорошо помогает в процессе проектирования чтобы не забыть какие-то состояния.
- Канал #pre-release не работает. Было очень мало фидбека - печально.
- Коридорное тестирование позволяет выявить явные косяки еще на первых прототипах.
- Начать использовать ProtoPie. Это поможет собрать интерактивный прототип и его помощью можно протестировать паттерны которые сложно показать статичными макетами.
- ТЕСТИРОВАТЬ,ТЕСТИРОВАТЬ, ТЕСТИРОВАТЬ.