Система управления умными счётчиками ЖКХ для Связь инжиниринг М

Целью проекта была разработка интерфейса для одного из устройств мониторинга (УМ-31 Смарт). Оно подключается к счетчикам многоквартирных домов, собирает и хранит показания, а затем передает сводные данные на центральный пульт.

С прибором и его интерфейсом работают несколько сотрудников компании: при первичном подключении и запуске — монтажники и пусконаладчики, а затем операторы. Также с ним взаимодействуют частные клиенты, например СНТ.

Ранее для настройки этих устройств использовались приложения-конфигураторы, устанавливаемые на компьютер. А несколько лет назад для «УМ-31 Смарт» был реализован веб-интерфейс. Однако он не решал весь спектр задач и имел ряд ошибок и нарушений по части логики и юзабилити.

Нашей задачей была разработка нового интерфейса с улучшением всех этих параметров.

Проект стартовал в августе 2021 года. Над ним начали работу UX-дизайнер, бизнес-аналитик и менеджер проекта.

После онлайн-знакомства с заказчиком наша команда начала изучать информацию о проекте: техническое описание устройства, руководство пользователя конфигуратора, текущий веб-интерфейс.

На первом интервью удалось больше узнать об устройстве и принципах его работы, изучить существующий веб-интерфейс и выявить требования, которые необходимо учесть при создании нового. Также получили больше информации о пользователях и выявили из них ключевых: пусконаладчик, настраивающий устройство при подключении, и оператор, работающий с общим массивом данных.

Для более глубокого погружения в проект мы посетили офис компании в Москве. UX-дизайнер пообщалась с разработчиком устройства и руководителем, увидела работу сотрудников в реальном времени и провела с ними интервью. Все это помогло точнее определить требования к интерфейсу.

По результатам интервью были составлены протоколы. Их взяли в дальнейшую работу UX-дизайнер и бизнес-аналитик. Они тесно взаимодействуют на протяжении всего проекта: дизайнер держит фокус на пользователях, аналитик — на процессах сервиса. Такой подход снижает вероятность ошибок, так как специалисты могут перепроверять друг друга.

Существующий интерфейс имел множество логических противоречий. Чтобы их устранить, нужно было лучше понять сценарии работы пользователей и определить необходимые разделы, экраны и функции. Для этого были созданы схемы ключевых сценариев.

На каждом шаге мы фиксировали всю важную информацию и комментарии заказчика, чтобы точнее прорабатывать сценарии.

Всего выделили 5 ключевых сценариев, которые объединили в единую схему. Это помогло перейти к созданию информационной архитектуры, определить главные и второстепенные разделы, продумать переходы и взаимодействия между ними.

Аналитик подробно изучил бизнес-процессы компании, чтобы выявить связь между целями бизнеса и пользователя, так как они непосредственно влияют на интерфейс.

Эти данные легли в основу концептуальной карты — схемы, которая позволяет понять бизнес-цели пользователей.

На ее основе строились первичные варианты использования — use cases. Для этого проекта они были основной формой фиксации требований к функциональности будущего сервиса.

Проведенная аналитика позволила сделать первый вариант информационной архитектуры, которую предварительно утвердили.

Но в силу сложности сервиса было необходимо дорабатывать и корректировать ее в процессе проектирования, при более глубоком рассмотрении каждого шага.

В результате были выделены 3 раздела — исходя из задач сотрудника: работа с устройством (настройка), работа с данными и работа с передачей данных.

Проектирование начали со сценария первичной пусконаладки устройства, так как в этом процессе участвуют оба ключевых пользователя и он задействует максимальное количество функций и разделов (которые есть и в других сценариях).

На этом этапе работы в фокусе держали 2 цели:

• Упростить работу сотрудников, особенно пусконаладчика. Во-первых, потому что он работает не в самых комфортных условиях, а во-вторых, выполняет одну из важнейших задач — подключение устройства и его настройку для корректной удаленной работы.
• Обеспечить обмен только необходимыми данными между устройством и интерфейсом.

Настройка устройства чаще всего происходит в максимально некомфортных условиях: плохо освещенные помещения, подвалы, чердаки и так далее. Было важно предусмотреть эту особенность и сделать сервис простым и понятным, чтобы задача решалась быстро.

При этом в интерфейс нужно было включить большое количество функций и информации. Чтобы избежать перегруженности, создали боковые меню для настроек, которые нужны не регулярно, и группировку настроек по блокам.

Одна из ключевых задач сотрудника — проверка корректности работы устройства и, в случае обнаружения сбоев, выявление места ошибки.

Вариантов сбоев большое множество, и информация о них сосредоточена в разных разделах. С помощью нового элемента «шапки», куда выводятся ключевые характеристики о состоянии устройства, специалисты смогут сразу понять, все ли в порядке.

Одним из важнейших этапов была работа с таблицами. Основная сложность заключалась в том, что в пространство экрана было необходимо заложить большое количество функций.

Для этого придумывали новые решения. Например, в таблице считывания показаний счетчиков создали многоуровневый фильтр выбора параметров, распределили данные по страницам и предусмотрели разные состояния таблиц для работы с фильтрами и сортировкой.

На видео ниже показано, как происходит фильтрация данных, которые пользователь хочет получить: в меню выбирается тип счетчиков (вода, электричество или другие), тип данных (текущие или архивные) и конкретные параметры. После считывания показаний выводятся только выбранные данные.

Второй пример. Считывание информации из устройства в интерфейс занимает некоторое время, поэтому появляется прогресс-бар, показывающий процесс загрузки. Действие можно прервать при необходимости. По окончании считывания в интерфейсе отображается таблица с данными.

Ряд разделов оказались более простыми в реализации.

Необходимо было предусмотреть все те же действия, что и везде, соблюдая консистентность в добавлении, записи и удалении новых элементов, структуре таблиц и других аспектах.

Финальной страницей был дашборд. Это новый раздел, который в итоге стал одним из ключевых, так как позволяет пользователю в сжатом и визуально простом виде получить всю необходимую информацию о работе устройства.

С каждого блока дашборда есть возможность перехода в соответствующий раздел.

В первую очередь был подготовлен стайлборд: референсы актуальных интерфейсов, варианты формирования таблиц и графиков навигации. Это помогло определить визуальный стиль элементов: основной и дополнительные цвета, типографика, иконки, вид инпутов, подсказок и тегов.

Дизайн создавали, учитывая специфику проекта. Так как это сервисный интерфейс, в нем не должно быть ничего лишнего, что отвлекало бы от функционала. При этом было важно правильно расставить акценты.

В завершение реализовали темную тему, чтобы сделать работу инженеров более комфортной, так как монтаж оборудования часто происходит при плохом освещении.