Переработка раздела управления ML-моделями
Саммари
Переработала раздел управления ML-моделями в платформе для создания голосовых роботов. Аналитики не понимали, что происходит с моделями и при любой ошибке шли в поддержку. Разобралась в технической логике системы, переработала архитектуру раздела. Обращений в поддержку стало меньше на 60%.
Продукт
Naumen Erudite — платформа для создания голосовых и чат-ботов. Роботов настраивают аналитики внедрения: прописывают логику диалогов, настраивают сценарии, обучают ML-модели.
Модели отвечают за то, как робот понимает клиента: распознают тему обращения, извлекают данные из реплик, выбирают следующий шаг в диалоге. Когда аналитик меняет логику, модели нужно переобучить. Для этого существует раздел «Обучение».
Проблема
Раздел существовал много лет и за это время оброс решениями, которые никто не мог объяснить. Часть логики не была описана нигде.
Главная боль была в статусах. На одном экране их было три: статус ML-компонента, статус модели в списке, и маленький крестик у даты активной модели. Крестик при этом означал самое важное — «модель не готова к работе», но выглядел как декоративная иконка. В итоге ни один статус не отвечал на вопрос прямо: робот сейчас работает?
Когда обучение падало с ошибкой, аналитик не понимал что произошло и шёл в поддержку. Каждое такое обращение — это время команды поддержки и простой робота на стороне клиента.
Исследование
Я начала с погружения: читала документацию, обсуждала поведение системы с разработчиками и тестировала сценарии. В какой-то момент вызвала редкую ошибку, что чуть не уронила прод.
Параллельно провела интервью с восемью аналитиками. Разделила на опытных и новичков: опытные работают с разделом каждый день и знают обходные пути, но взгляд уже замылился и реальные проблемы не считываются. Новички показывают, что непонятно без документации и подсказок. Вместе они дали полную картину.
Главная проблема оказалась не в отдельных элементах, а в том что интерфейс не отражал как система работает. При ошибке обучения робот продолжает работать, но интерфейс никак этого не показывал.
Решение
Изначально прорабатывала варианты с похожей структурой, что сейчас в продукте: master-detail. Но они не решали главное — не открыв детали моделей, непонятно было что происходит с компонентом. И тестирование диалогов никуда логично не ложилось.
Тогда я пошла от вопроса: что аналитику нужно видеть сразу, а что можно убрать подальше. 90% времени в разделе это переобучение, поэтому разделила на два таба: «Управление обучением» и «Дополнительно». Тестирование и редкие настройки ушли на второй таб.
Карточку компонента переделала по той же логике. Она теперь сразу отвечает на вопрос: компонент работает или нет, и что с последней моделью. Раньше для этого нужно было открывать список моделей и разбираться самому.
Формулировки статусов переработали вместе с UX-райтером: убрали технические термины, заменили на язык, который отвечает на вопрос пользователя.
Валидация
Протестировала новый интерфейс на двух группах аналитиков — опытных и новичках, но уже с другими людьми. Просила пройти обычный путь: переобучить модели, разобраться с ошибкой, посмотреть статусы. Критических проблем не нашла, мелкие правки внесла до передачи в разработку.
Результат
Работа над ошибками
В табе «Дополнительно» можно запустить автоматическое тестирование диалогов. После теста у аналитика два действия: посмотреть результаты или запустить заново. Я поставила «Посмотреть результаты» на первое место. Показалось, что это главное действие после завершения.
После релиза пользователи пришли с фидбеком: по привычке нажимали не туда и случайно запускали тестирование заново.
Исправила: вернула обе кнопки на привычные места, а кнопку запуска переименовала в «Запустить ещё раз» — чтобы аналитик понимал что это повторный запуск, а не первый. Я недооценила силу позиционной привычки.
