Система управления умными счётчиками ЖКХ для Связь инжиниринг М
О клиенте
АО «Связь инжиниринг М» — разработчик и производитель автоматизированных систем коммерческого учета энергоресурсов и систем мониторинга удаленных объектов.
Более 15 лет продукция компании успешно применяется в промышленности, электроэнергетике, железнодорожной сфере, жилищно-коммунальном хозяйстве, на объектах операторов связи и в других отраслях.
На счету компании более 100 000 специализированных систем, которые используются в 72 регионах РФ и странах СНГ.
Проект
Целью проекта была разработка интерфейса для одного из устройств мониторинга (УМ-31 Смарт). Оно подключается к счетчикам многоквартирных домов, собирает и хранит показания, а затем передает сводные данные на центральный пульт.
С прибором и его интерфейсом работают несколько сотрудников компании: при первичном подключении и запуске — монтажники и пусконаладчики, а затем операторы. Также с ним взаимодействуют частные клиенты, например СНТ.
Ранее для настройки этих устройств использовались приложения-конфигураторы, устанавливаемые на компьютер. А несколько лет назад для «УМ-31 Смарт» был реализован веб-интерфейс. Однако он не решал весь спектр задач и имел ряд ошибок и нарушений по части логики и юзабилити.
Нашей задачей была разработка нового интерфейса с улучшением всех этих параметров.
Предпроектная аналитика
Проект стартовал в августе 2021 года. Над ним начали работу UX-дизайнер, бизнес-аналитик и менеджер проекта.
После онлайн-знакомства с заказчиком наша команда начала изучать информацию о проекте: техническое описание устройства, руководство пользователя конфигуратора, текущий веб-интерфейс.
На первом интервью удалось больше узнать об устройстве и принципах его работы, изучить существующий веб-интерфейс и выявить требования, которые необходимо учесть при создании нового. Также получили больше информации о пользователях и выявили из них ключевых: пусконаладчик, настраивающий устройство при подключении, и оператор, работающий с общим массивом данных.
Для более глубокого погружения в проект мы посетили офис компании в Москве. UX-дизайнер пообщалась с разработчиком устройства и руководителем, увидела работу сотрудников в реальном времени и провела с ними интервью. Все это помогло точнее определить требования к интерфейсу.
По результатам интервью были составлены протоколы. Их взяли в дальнейшую работу UX-дизайнер и бизнес-аналитик. Они тесно взаимодействуют на протяжении всего проекта: дизайнер держит фокус на пользователях, аналитик — на процессах сервиса. Такой подход снижает вероятность ошибок, так как специалисты могут перепроверять друг друга.
Пользовательские сценарии
Существующий интерфейс имел множество логических противоречий. Чтобы их устранить, нужно было лучше понять сценарии работы пользователей и определить необходимые разделы, экраны и функции. Для этого были созданы схемы ключевых сценариев.
На каждом шаге мы фиксировали всю важную информацию и комментарии заказчика, чтобы точнее прорабатывать сценарии.
Всего выделили 5 ключевых сценариев, которые объединили в единую схему. Это помогло перейти к созданию информационной архитектуры, определить главные и второстепенные разделы, продумать переходы и взаимодействия между ними.
Аналитик подробно изучил бизнес-процессы компании, чтобы выявить связь между целями бизнеса и пользователя, так как они непосредственно влияют на интерфейс.
Эти данные легли в основу концептуальной карты — схемы, которая позволяет понять бизнес-цели пользователей.
На ее основе строились первичные варианты использования — use cases. Для этого проекта они были основной формой фиксации требований к функциональности будущего сервиса.
Проведенная аналитика позволила сделать первый вариант информационной архитектуры, которую предварительно утвердили.
Но в силу сложности сервиса было необходимо дорабатывать и корректировать ее в процессе проектирования, при более глубоком рассмотрении каждого шага.
В результате были выделены 3 раздела — исходя из задач сотрудника: работа с устройством (настройка), работа с данными и работа с передачей данных.
Прототипирование
Проектирование начали со сценария первичной пусконаладки устройства, так как в этом процессе участвуют оба ключевых пользователя и он задействует максимальное количество функций и разделов (которые есть и в других сценариях).
На этом этапе работы в фокусе держали 2 цели:
- Упростить работу сотрудников, особенно пусконаладчика. Во-первых, потому что он работает не в самых комфортных условиях, а во-вторых, выполняет одну из важнейших задач — подключение устройства и его настройку для корректной удаленной работы.
- Обеспечить обмен только необходимыми данными между устройством и интерфейсом.
Настройка устройства чаще всего происходит в максимально некомфортных условиях: плохо освещенные помещения, подвалы, чердаки и так далее. Было важно предусмотреть эту особенность и сделать сервис простым и понятным, чтобы задача решалась быстро.
При этом в интерфейс нужно было включить большое количество функций и информации. Чтобы избежать перегруженности, создали боковые меню для настроек, которые нужны не регулярно, и группировку настроек по блокам.
Одна из ключевых задач сотрудника — проверка корректности работы устройства и, в случае обнаружения сбоев, выявление места ошибки.
Вариантов сбоев большое множество, и информация о них сосредоточена в разных разделах. С помощью нового элемента «шапки», куда выводятся ключевые характеристики о состоянии устройства, специалисты смогут сразу понять, все ли в порядке.
Одним из важнейших этапов была работа с таблицами. Основная сложность заключалась в том, что в пространство экрана было необходимо заложить большое количество функций.
Для этого придумывали новые решения. Например, в таблице считывания показаний счетчиков создали многоуровневый фильтр выбора параметров, распределили данные по страницам и предусмотрели разные состояния таблиц для работы с фильтрами и сортировкой.
На видео ниже показано, как происходит фильтрация данных, которые пользователь хочет получить: в меню выбирается тип счетчиков (вода, электричество или другие), тип данных (текущие или архивные) и конкретные параметры. После считывания показаний выводятся только выбранные данные.
Второй пример. Считывание информации из устройства в интерфейс занимает некоторое время, поэтому появляется прогресс-бар, показывающий процесс загрузки. Действие можно прервать при необходимости. По окончании считывания в интерфейсе отображается таблица с данными.
Ряд разделов оказались более простыми в реализации.
Необходимо было предусмотреть все те же действия, что и везде, соблюдая консистентность в добавлении, записи и удалении новых элементов, структуре таблиц и других аспектах.
Финальной страницей был дашборд. Это новый раздел, который в итоге стал одним из ключевых, так как позволяет пользователю в сжатом и визуально простом виде получить всю необходимую информацию о работе устройства.
С каждого блока дашборда есть возможность перехода в соответствующий раздел.
UI-дизайн
В первую очередь был подготовлен стайлборд: референсы актуальных интерфейсов, варианты формирования таблиц и графиков навигации. Это помогло определить визуальный стиль элементов: основной и дополнительные цвета, типографика, иконки, вид инпутов, подсказок и тегов.
Дизайн создавали, учитывая специфику проекта. Так как это сервисный интерфейс, в нем не должно быть ничего лишнего, что отвлекало бы от функционала. При этом было важно правильно расставить акценты.
В завершение реализовали темную тему, чтобы сделать работу инженеров более комфортной, так как монтаж оборудования часто происходит при плохом освещении.
Над проектом работали




