Веб-интерфейс Fraud Protection
Защита бизнеса и клиентов от всех видов цифровых рисков, предотвращение мошенничества в режиме реального времени и защита цифровой личности пользователя.
Основные задачи
Провести аудит, выявив проблемные разделы совместно с командой продукта. Приоритезировать по важности и по скорости выполнения задачи аналитиками и клиентами. Далее улучшать и тестировать пользовательский опыт в текущих разделах и проектировать новые решения.

Проектирование
Перед тем, как начать «рисовать» макет, необходимо было выявить самое главное — потребность пользователя. На примере раздела с бот-активностью (рисунок ниже), я построил базовую карту User Story, по которой определял важность функций и приоритеты.
Были определены действия: просмотр общей статистики по ботам и их детали, идентификация и классификация ботов, настройка определённых правил для дальнейшего обнаружения ботов и т.д.
После выявления разбил на истории (по этой причине методика User Story): пользователь хочет видеть активность за последний час\неделю\месяц, анализ IP по провайдеру, сети, стране, детали бота и информация по нему.
Такие детали сразу дают понять, что из чего строится, осталось применить компоненты, собрать прототип и тестировать.

Тестирование
Собранный кликабельный прототип тестировался на фокус-группе(как внутри команды, так и с клиентами). Определялись проблемные места, новые паттерны, проверка гипотез. Одновременно применялась метрика TSR (Task Success Rate), из которой можно было выявить успешное выполнение заданной задачи.
Метрика позволяла понять правильные приоритеты в действиях и ошибочные гипотезы. Поэтому не раз сталкивался с тем, что выявив большое количество функций, приоритеты могли быть нарушены, тем самым пользователь не мог выполнить задачу или слишком долго.
Теперь чуток про тестирование со стороны разработки. Как я писал выше, целевая аудитория состояла из двух групп, поэтому среда разработки также делилась на две группы, не считая сам прод(production).
Alpha — среда, в которой тестировались все внутренние команды. Можно было обнаружить как новые задачи, так и баги.
Beta — среда, в которой были и внутренние, и внешние команды. Клиенты, у которых был доступ, могли уже выполнять задачи и тестировать.

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