Экран руководителя
У руководителя свой набор окон: список диспетчеров с их статусом и числом закрытых заявок, статистика. Диспетчеру важно, что требует решения сейчас, руководителю — что происходит в целом.
Задача
Москоллектор обслуживает 825 км подземных коллекторов с кабелями и теплосетями. Сейчас диспетчеры узнают о проблеме, когда датчик уже сработал. Много сигналов оказываются ложными, а оборудование обслуживают по календарю, даже если оно в порядке.
На хакатоне нужно было научиться предсказывать пожары, подтопления, загазованность и отказы оборудования. Модель строили ML-инженеры. Я отвечала за то, чтобы диспетчер понимал, почему система подняла тревогу, и мог быстро решить, что с ней делать.
По ТЗ сервис не должен принимать решения за человека. Последнее слово остаётся за диспетчером.
Исследование
Поговорить с диспетчерами не получилось: заказчик отвечал на вопросы, но обратной связи по ходу работы не давал. Я опиралась на ТЗ, видеоконференции заказчика, открытые материалы о диспетчерских системах и опыт команды. Про интерфейсы таких систем в открытом доступе почти ничего нет.
Что я выяснила
- 1Классические диспетчерские показывают много данных, но разбираться в них диспетчер должен сам.
- 2Голой цифре вероятности не доверяют. Нужно видеть, откуда она взялась.
- 3Карта показывает, где проблема, но по ней не понять, что происходит внутри объекта.
- 4Показания датчиков и действия людей лучше держать в разных местах. В одной ленте они мешают друг другу.
- 5Если любое отклонение горит красным, диспетчер перестаёт замечать действительно важное.
Из этого вырос принцип: интерфейс строится вокруг жизни проблемы, от первого сигнала до результата на объекте.
Сигнал — прогноз — проверка — решение — работа — результат
CJM и user stories
Из этих выводов я собрала CJM диспетчера по тем же шести этапам: от сигнала до результата. На каждом этапе видно, что диспетчер делает, о чём думает, как себя чувствует, что ему мешает и какое решение в интерфейсе это закрывает. Тяжелее всего на этапе решения: голой вероятности нет доверия, а ответственность за выбор лежит на диспетчере.
CJM гипотетическая: я строила её по ТЗ, видеоконференциям заказчика и открытым материалам о диспетчерских системах. Интервью с диспетчерами не было.
По болям из CJM я написала 14 user stories для трёх ролей: восемь для диспетчера, две для руководителя и четыре для выездного инженера. У каждой истории есть окно интерфейса, которое её закрывает.
Было и стало
Сначала я нарисовала привычную схему. Сверху шапка с логотипом, районом, именем диспетчера, часами и уведомлениями. Слева меню. Объект выбирался из выпадающего списка, а в правом нижнем углу всё время обновлялась таблица логов.
Команда посмотрела флоу, и мы нашли в нём проблемы. Логи постоянно дёргались в углу и занимали место. Показания датчиков и действия людей шли одной лентой. Из прогноза нельзя было перейти к действию: заявки в схеме не было вообще.
Рабочее пространство из окон
Дашборд делали почти все команды. Но у диспетчеров разные задачи, и жёсткий набор блоков заставил бы всех работать одинаково.
Я убрала шапку и превратила боковое меню в пульт, из которого открываются окна: карта, журнал прогнозов, дневник диспетчера, журнал данных, история объектов и создание заявки. Окна можно двигать, сворачивать, копировать и закрывать. Если выбрать объект на карте, его прогнозы и история подтягиваются в остальные окна. Раскладка сохраняется между сессиями.
Карточка прогноза
Карточку можно открыть из журнала прогнозов или кликом по объекту на карте.
- Что и где
- «Повреждение коллектора, пикет 24+350»
- Насколько вероятно и когда
- «34% вероятности, горизонт 24 часа» — по сроку понятно, насколько всё срочно
- Почему
- Рост температуры на датчике, давление на соседнем участке, похожий случай в прошлом
- Что сделать
- «Проверить участок 24+300–24+400 в течение 24 часов»
- Решение
- Кнопки «Отклонить» и «Взять в работу»
Система предлагает, диспетчер решает
Каждое решение диспетчера сохраняется, и потом по ним можно оценивать и дообучать модель.
Что ещё я сделала
Режим для слабых компьютеров
Окна с картой, которые свободно двигаются по экрану, нагружают старые компьютеры. В этом режиме окна встают в сетку, а число колонок задаётся переключателем.
Мобильные экраны инженера
Прототип для инженера на объекте: список заявок, карточка с картой, датчиками и контактом диспетчера, отчёт и запрос диспетчеру.
Дизайн-система
Цвета взяла с сайта Москоллектора. Окна, карточки, списки, кнопки и поля собрала сама, в светлой и тёмной теме. Разработчику передавала CSS из Figma.
Результат
Веб-интерфейс диспетчера и руководителя работает на данных модели. Есть прототип мобильных экранов инженера и дизайн-система в двух темах.
Чему я научилась
В топ-10 мы не прошли. Насколько понимаю, из-за презентации: сайт жюри даже не открывало. Презентацию я собирала практически одна и пыталась разобраться в технической части через ИИ, вместо того чтобы сесть с командой. В следующий раз я бы:
- Выделила на презентацию 3–4 дня и собирала её всей командой
- Меньше времени тратила на исследование и раньше проверяла гипотезы на прототипе
- Сначала расписала, какое окно после какого действия открывается, а уже потом рисовала экраны
- Автоматизировала сборку компонентов с помощью нейросетей и освободила время на сценарии
