Кого я изучала
Tesla, Waymo, Cruise, Zoox, Samsara и «ГдеМои» — продукты, где оператор следит за большим парком машин
Перезагрузка LiDAR…
Задача
Спроектировать сервис мониторинга беспилотного транспорта для инженеров центра мониторинга
Сервис должен помогать:
- – Отслеживать состояние автомобилей
- – Выявлять проблемы
- – Быстро реагировать на инциденты
- – Принимать решение о дальнейших действиях
Исследование
Первым делом я решила изучить, кто же такие инженеры центра мониторинга, из чего состоит их работа, с какими задачами они сталкиваются каждый день и какая информация нужна им, чтобы быстро понимать, что происходит с автомобилем
Пообщаться с реальными специалистами не удалось, поэтому я изучала целевых пользователей через вакансии и описания профильных специальностей в вузах и колледжах
Следующим шагом я посмотрела, как похожие задачи решают другие продукты, и собрала бенчмарки. Мне было важно понять, как в таких системах показывают большое количество данных, выделяют проблемные состояния и помогают пользователю быстро перейти от общей картины к конкретной ситуации
Как выглядит рабочее место оператора
Вопрос по ситуации, фрагмент с камеры и один понятный ответ — без лишних элементов
WaymoЦентр удалённой помощиИсточник ↗
TeslaДанные с автомобиляИсточник ↗
CruiseМониторинг паркаИсточник ↗
ZooxУдалённые подсказки машинеИсточник ↗Как это делают роботакси
Четыре подробных разбора — нажми на карточку, чтобы открыть источник
Подробности — на втором уровне. Подробная информация нужна уже после того, как проблема найдена. На первом уровне достаточно самого важного: что произошло, с какой машиной и насколько это критично
Проектирование
Гипотезы
Если показывать проблемные машины выше остальных, то оператор быстрее заметит инцидент, потому что ему не придётся искать его среди нормальных.
Если оставить на первом экране только суть, а детали открывать по клику, то оператор не потеряется в данных, потому что поймёт, что случилось, ещё до деталей.
Если состояние машины читается по цвету и иконке, то оператор распознает его без чтения текста, потому что статус виден периферийным зрением.
Данных в сервисе много, поэтому сначала я разложила их по группам и по вопросам, которые оператор задаёт по порядку: что за машина, что с поездкой, что сломалось. Так стало видно, что показывать сразу, а что убрать на второй уровень.
Потом прошла путь оператора по шагам и нашла места, где ему нужно выбрать: помогла ли перезагрузка, есть ли в машине пассажир. Из этих развилок получились действия в карточке машины.
Решение
Решение построено вокруг одной задачи: оператор должен быстро понять, что случилось, и безопасно действовать, не теряя фокус. Гипотезы выше я пока не проверяла на пользователях — это принципы, на которых построен интерфейс. Ниже весь сценарий целиком.
Сводная панель
Мониторинг парка в реальном времени
Следующий этап
Интерфейс пока не проверялся на людях, а гипотезы остаются предположениями. Чтобы понять, работает ли решение, я бы заранее определила метрики и то, что считать успехом.
Метрики:
- – Время реакции: сколько проходит от появления алерта до первого действия оператора.
- – Время до решения: сколько нужно, чтобы дойти от алерта до нужного действия, например перезапуска датчика.
- – Ошибки: как часто оператор выбирает не то действие или возвращается назад за данными.
- – Понимание состояния: что оператор успевает понять за пять секунд на экране.
Критерии успеха:
- – Критичный инцидент замечают быстрее, чем в списке без приоритетов.
- – Первое решение принимают на карточке, не открывая полный экран инцидента.
- – Опасное действие невозможно сделать случайно: каждый шаг подтверждается осознанно.
- – Состояние машины верно называют почти все участники теста.
Конкретные целевые значения я бы задала вместе с командой, когда появятся данные по текущему процессу. По результатам поправила бы порядок данных на экранах и приоритеты в списке инцидентов.