Оптимизация управления правами требования в магазине скупки долгов
Проблема
Администраторы МСД (магазина скупки долгов) тратили много времени на поиск и обработку прав требований, проданных платформе.
UX research
Контекст
МСД — внутренний инструмент для работы с правами требования (ПТ), которые были выкуплены платформой напрямую у клиентов.
Администраторы ежедневно работают с большим объемом данных:
Администраторы ежедневно работают с большим объемом данных:
- отслеживают статусы ПТ;
- проверяют владельцев;
- анализируют суммы сделок;
- ищут конкретные права требования;
- переходят к Лотам, в состав которых входят ПТ
Цель исследования
Понять, насколько существующая таблица помогает администраторам быстро находить нужные записи и принимать решения при работе с большим объемом данных
UX-аудит
Провела анализ текущего интерфейса по следующим критериям:
- визуальная иерархия данных;
- сканируемость таблицы;
- доступность ключевых действий;
- эффективность поиска информации;
- соответствие сценариям работы администратора.
Анализ пользовательских сценариев
Были выделены основные задачи пользователей:
- Найти конкретное право требования.
- Найти ПТ определенного статуса.
- Определить владельца права требования.
- Найти самые крупные сделки.
- Перейти к связанному лоту.
- Открыть карточку для редактирования.
Выводы:
Выявлены следующие проблемы в прохождении сценариев:
Высокий приоритет
1. Статусы сложно отследить
Статус является ключевым атрибутом ПТ, однако расположен в середине таблицы и визуально недостаточно выделен. Это увеличивает время поиска проблемных и требующих внимания ПТ.
2. Нет визуального приоритета данных
Статусы, суммы ПТ и владельцы визуально не отличаются от второстепенной информации. Админам сложнее быстро оценивать записи и принимать решения.
3. Таблица не поддерживает основные рабочие сценарии
Для анализа одной записи админу необходимо последовательно просматривать практически всю строку. Это увеличивает когнитивную нагрузку и замедляет работу с большим объемом данных.
4. Неочевидная сортировка
Сортировка не позволяет быстро понять порядок отображения записей, что затрудняет поиск актуальных, приоритетных или финансово значимых ПТ.
Средний приоритет
1. Навигация между связанными сущностями (ПТ и Лотами) недостаточно понятна
Ссылки на ПТ, лоты и владельцев оформлены одинаково и не формируют предсказуемый пользовательский сценарий, что увеличивает время перехода к нужной информации.
2. Действия над записью плохо заметны
Основное действие представлено небольшой иконкой редактирования в конце строки, до которой еще нужно добраться с помощью полосы прокрутки. Из-за этого админы тратят больше времени для совершения операций с ПТ.
3. Информация о владельцах воспринимается разрозненно
Первичный и текущий владельцы отображаются как независимые колонки, хотя являются частью одного бизнес-процесса. Это усложняет отслеживание передачи ПТ.
4. Неочевидная сортировка
Сортировка не позволяет быстро понять порядок отображения записей, что затрудняет поиск актуальных, приоритетных или финансово значимых ПТ.
Низкий приоритет
1. Названия ответчиков обрезаются
Длинные наименования отображаются не полностью, может понадобиться отдельный переход в карточку ПТ для уточнения данных.
2. Данные не сгруппированы визуально
Колонки не объединены по смысловым блокам и воспринимаются как равнозначные. Если админ долго работает с таблицей, это снижает скорость ее сканирования.
Высокий приоритет
1. Статусы сложно отследить
Статус является ключевым атрибутом ПТ, однако расположен в середине таблицы и визуально недостаточно выделен. Это увеличивает время поиска проблемных и требующих внимания ПТ.
2. Нет визуального приоритета данных
Статусы, суммы ПТ и владельцы визуально не отличаются от второстепенной информации. Админам сложнее быстро оценивать записи и принимать решения.
3. Таблица не поддерживает основные рабочие сценарии
Для анализа одной записи админу необходимо последовательно просматривать практически всю строку. Это увеличивает когнитивную нагрузку и замедляет работу с большим объемом данных.
4. Неочевидная сортировка
Сортировка не позволяет быстро понять порядок отображения записей, что затрудняет поиск актуальных, приоритетных или финансово значимых ПТ.
Средний приоритет
1. Навигация между связанными сущностями (ПТ и Лотами) недостаточно понятна
Ссылки на ПТ, лоты и владельцев оформлены одинаково и не формируют предсказуемый пользовательский сценарий, что увеличивает время перехода к нужной информации.
2. Действия над записью плохо заметны
Основное действие представлено небольшой иконкой редактирования в конце строки, до которой еще нужно добраться с помощью полосы прокрутки. Из-за этого админы тратят больше времени для совершения операций с ПТ.
3. Информация о владельцах воспринимается разрозненно
Первичный и текущий владельцы отображаются как независимые колонки, хотя являются частью одного бизнес-процесса. Это усложняет отслеживание передачи ПТ.
4. Неочевидная сортировка
Сортировка не позволяет быстро понять порядок отображения записей, что затрудняет поиск актуальных, приоритетных или финансово значимых ПТ.
Низкий приоритет
1. Названия ответчиков обрезаются
Длинные наименования отображаются не полностью, может понадобиться отдельный переход в карточку ПТ для уточнения данных.
2. Данные не сгруппированы визуально
Колонки не объединены по смысловым блокам и воспринимаются как равнозначные. Если админ долго работает с таблицей, это снижает скорость ее сканирования.
User Flow & Conversion Analysis
Текущий флоу с точками потери конверсии
Improved Flow с дизайн-решениями проблем
Final UI
Поля перегруппированы по порядку заполнения.
Сценарий выстроен сверху вниз без возвратов между блоками.
Важные действия перенесены в конец формы.
Сценарий выстроен сверху вниз без возвратов между блоками.
Важные действия перенесены в конец формы.
Старая форма
Новая форма
Стало:
Было:
Шаг 2. Выбор места публикации Лота
Шаг 1. Заполнение карточки Лота
Новая карточка Лота
Старая карточка Лота
- Добавлен контекст публикации через заголовок с номером Лота;
- Настройки привязаны к сценариям через заголовок с чекбоксом;
- Есть возможность изменения даты публикации на цифровой витрине;
- Используется единое поле с data picker;
- Уменьшена насыщенность второстепенных данных и обводки полей filled;
- CTA активна;
- Удалена кнопка «Отправить в МСД».
- При выборе дополнительной публикации на цифровой витрине нужные данные подставляются в форму автоматически из полей выше.
- Нет заголовка — неочевидный контекст действия;
- Непонятно, какие поля относятся к какому сценарию публикации;
- Невозможно выбрать разные даты публикации для сценариев;
- Для ввода даты используются два отдельных действия;
- Отсутствует типографическая иерархия;
- Disabled CTA создает ложное ощущение недоступности функции;
- Кнопка «Отправить в МСД» затрудняет прохождение по сценарию;
- При выборе публикации на цифровой витрине все данные нужно было вводить вручную.
Стало:
Было:
- Вертикальный сценарий;
- Четко обозначены поля для заполнения;
- Прямая публикация;
- Поля валидируются;
- CTA активна, добавлена кнопка сброса;
- Добавлен data picker;
- Срок действия проставляется автоматически;
- Визуальные акценты перераспределены за счёт изменения размеров шрифта
- Горизонтальная логика;
- Непонятно, какие поля редактируются;
- Лишний шаг сохранения;
- Нет состояния ошибки;
- Неактивная CTA, нет сброса формы;
- Ручной ввод даты;
- Срок действия вводится вручную;
- Заголовок и данные в полях имеют слишком высокий визуальный вес.
Тестирование финального решения
После завершения редизайна я собрала интерактивный прототип и провела немодерируемое юзабилити-тестирование с пользователями платформы TST. Респонденты самостоятельно прошли сценарий публикации Лота с использованием обновленного интерфейса.
Тестирование показало, что пользователи успешно выполняли ключевые задачи без дополнительных инструкций и не сталкивались с критическими проблемами в процессе публикации. Новая структура формы и упрощенный сценарий взаимодействия сделали процесс публикации более понятным и предсказуемым.
Также тестирование выявило дополнительные точки роста продукта:
Тестирование показало, что пользователи успешно выполняли ключевые задачи без дополнительных инструкций и не сталкивались с критическими проблемами в процессе публикации. Новая структура формы и упрощенный сценарий взаимодействия сделали процесс публикации более понятным и предсказуемым.
Также тестирование выявило дополнительные точки роста продукта:
- Пользователям не хватало пояснений и подсказок для некоторых полей формы.
- Пользователи хотели бы получить возможность редактировать сумму исковых требований непосредственно из карточки Лота.
- При досрочном снятии Лота с аукциона накладывается штраф. Следует добавить предупреждение об этом при публикации Лота.
Результаты
После внедрения обновлённого интерфейса конверсия публикации Лотов за первый месяц выросла с 2,0% до 2,3%.
Несмотря на ограничения на этапе исследования (слишком мало респондентов), редизайн позволил упростить ключевой сценарий публикации Лота, снизить количество лишних действий и сделать процесс более прозрачным и понятным.
Несмотря на ограничения на этапе исследования (слишком мало респондентов), редизайн позволил упростить ключевой сценарий публикации Лота, снизить количество лишних действий и сделать процесс более прозрачным и понятным.