Из дизайнера в инженеры: как спроектировать сложный интерфейс, если никто не знает, что должно получиться в итоге

Из дизайнера в инженеры: как спроектировать сложный интерфейс, если никто не знает, что должно получиться в итоге

Рома
Рома
UI-дизайнер
1 декабря 2022

Когда дизайнер проектирует несложный сервис вроде службы доставки или типовой интернет-магазин, он опирается на уже сложившийся User Experience в определенной отрасли. Но бывает такое, что клиенты приходят с задачами, где очень мало вводных. Например, новый продукт, стартап или сложный сервис, у которого нет аналогов.

На примере одного из проектов нашей студии — Системы удалённого мониторинга BMS — разберёмся, как действовать дизайнерам при проектировании уникальной и сложной системы, у которой нет аналогов.

Контекст и задача

К нам обратился стартап, который занимается производством BMS (Battery Management System) для танкеров и стационарных точек по всему миру. В судовых электростанциях батареи нужны на случай отключения генераторов, чтобы обеспечивать аварийное освещение, связь и питание ключевых систем.

Многие промышленные предприятия сталкиваются с жёсткими ограничениями на выбросы CO2 и токсичных газов, и для них батареи — это возможность не производить никаких выхлопов и соблюдать экологическую повестку. 

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

Состояние батарей отслеживают через веб-систему — AYK Cloud System. Нашей задачей стала разработка интерфейса этой системы, чтобы инженеры могли проводить мониторинг и контролировать стабильность программного и аппаратного обеспечения.

Схема передачи данных на веб-интерфейс через AYK
Схема передачи данных на веб-интерфейс через AYK

Первый этап. Аналитика

Такой продукт ранее не имел аналогов, поэтому нельзя провести бенчмаркинг. Кроме того, у заказчика не было понимания, как интерфейс должен выглядеть в итоге. Всё, что было известно, — это функциональные требования, которые мы детализировали на встречах со стейкхолдерами, и информация о том, что конечные пользователи продукта — инженеры.

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

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

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

Наш совет
Когда вы проектируете сложный интерфейс, которому нет аналогов, начинайте с вопроса — кто будет пользоваться системой и какие потребности мы закрываем? Изучать документацию, конечно, важно — но попробуйте встретиться и пообщаться с конечными пользователями. Проводите интервью, задавайте вопросы и даже ставьте себя на их место — задайте вопрос себе как инженеру: «Какую задачу я решаю? Для чего я это делаю?»

Второй этап. Проектирование

Когда разобрались, кто и как будет пользоваться системой, переходим к наброскам интерфейса — на этом этапе фиксируется расположение элементов и логика работы.

В функционал интерфейса мы постарались заложить несколько принципов:

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

На этапе проектирования мы определились с ключевыми функциями системы. В прототип же вынесли три самых важных: 

1. Контроль стабильности батареи.
2. Получение сообщений об ошибках.
3. Быстрое создание запроса и его получение.

Прототипы MVP-версии
Прототипы MVP-версии

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

Многоуровневая архитектура элементов BMS
Многоуровневая архитектура элементов BMS
Страница выбранных фильтров
Страница выбранных фильтров

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

Экран дашборда и отфильтрованный график Trace Log
Экран дашборда и отфильтрованный график Trace Log

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

Страница батарей по всем проектам
Страница батарей по всем проектам
Наш совет

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

Третий этап. Дизайн

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

Мудборд
Мудборд

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

Экраны для первой версии MVP
Экраны для первой версии MVP

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

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

Дашборд
Дашборд

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

Наш совет

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

Фрагмент UI-кита
Фрагмент UI-кита

Материалы по теме

Everest на РИФ-2019
4 Ноября 2019
Everest на РИФ-2019
Обсудить проект