Основная задача
Провести аудит, выявив проблемные разделы совместно с командой продукта. Приоритезировать по важности и по скорости выполнения задачи аналитиками и клиентами. Далее улучшать и тестировать пользовательский опыт в текущих разделах и проектировать новые решения.
Целевая аудитория
Целевая аудитория делилась на две группы: внутренние (внутри компании) и внешние, но специализация одинаковая, и чаще всего это были аналитики, пресейлы, SOC, отдел расследования. Тем не менее, у каждой специальности были свои потребности, боли и поведенческие паттерны, которые необходимо было изучить.
Если раздел используют аналитики, выявил благодаря общению и интервью основные цели и выполнение задач внутри раздела, определял принципы и сценарные решения в проектировании.
Если раздел был универсальным, т.е. использовали все, то находил общий знаменатель в сценарии. Понятное дело, без тестирования этого не узнать, поэтому проводились тесты для выявления ошибочных гипотез и решений, по итогу которых понимали, куда двигаться для решения проблем.
Проектирование
Перед тем, как начать «рисовать» макет, необходимо было выявить самое главное — потребность пользователя. На примере раздела с бот-активностью (рисунок ниже), я построил базовую карту User Story, по которой определял важность функций и приоритеты.
Были определены действия: просмотр общей статистики по ботам и их детали, идентификация и классификация ботов, настройка определённых правил для дальнейшего обнаружения ботов и т.д.
После выявления разбил на истории (по этой причине методика User Story): пользователь хочет видеть активность за последний час\неделю\месяц, анализ IP по провайдеру, сети, стране, детали бота и информация по нему.
Такие детали сразу дают понять, что из чего строится, осталось применить компоненты, собрать прототип и тестировать.
Тестирование
Собранный кликабельный прототип тестировался на фокус-группе(как внутри команды, так и с клиентами). Определялись проблемные места, новые паттерны, проверка гипотез. Одновременно применялась метрика TSR (Task Success Rate), из которой можно было выявить, просто переведя с английского, успешное выполнение заданной задачи.
Метрика позволяла понять правильные приоритеты в действиях и ошибочные гипотезы. Поэтому не раз сталкивался с тем, что выявив большое количество функций, приоритеты могли быть нарушены, тем самым пользователь не мог выполнить задачу или слишком долго.
Теперь чуток про тестирование со стороны разработки. Как я писал выше, целевая аудитория состояла из двух групп, поэтому среда разработки также делилась на две группы, не считая сам прод(production).
Alpha — среда, в которой тестировались все внутренние команды. Можно было обнаружить как новые задачи, так и баги.
Beta — среда, в которой были и внутренние, и внешние команды. Клиенты, у которых был доступ, могли уже выполнять задачи и тестировать.
Результат
За 2 года проведен аудит, выявлены ключевые проблемы и приоритеты. Разработаны и протестированы решения для улучшения работы пользователей. Оптимизированы функции и сценарии взаимодействия.