Из дизайнера в инженеры: как спроектировать сложный интерфейс, если никто не знает, что должно получиться в итоге
Когда дизайнер проектирует несложный сервис вроде службы доставки или типовой интернет-магазин, он опирается на уже сложившийся User Experience в определенной отрасли. Но бывает такое, что клиенты приходят с задачами, где очень мало вводных. Например, новый продукт, стартап или сложный сервис, у которого нет аналогов.
На примере одного из проектов нашей студии — Системы удалённого мониторинга BMS — разберёмся, как действовать дизайнерам при проектировании уникальной и сложной системы, у которой нет аналогов.
Контекст и задача
К нам обратился стартап, который занимается производством BMS (Battery Management System) для танкеров и стационарных точек по всему миру. В судовых электростанциях батареи нужны на случай отключения генераторов, чтобы обеспечивать аварийное освещение, связь и питание ключевых систем.
Многие промышленные предприятия сталкиваются с жёсткими ограничениями на выбросы CO2 и токсичных газов, и для них батареи — это возможность не производить никаких выхлопов и соблюдать экологическую повестку.
Чтобы батарея прослужила дольше, необходимо защищать её от повреждений, следить, чтобы она вовремя перезаряжалась и всегда работала в границах безопасной рабочей зоны. С этим как раз помогают BMS — электронные системы управления аккумуляторными батареями.
Состояние батарей отслеживают через веб-систему — AYK Cloud System. Нашей задачей стала разработка интерфейса этой системы, чтобы инженеры могли проводить мониторинг и контролировать стабильность программного и аппаратного обеспечения.
Первый этап. Аналитика
Такой продукт ранее не имел аналогов, поэтому нельзя провести бенчмаркинг. Кроме того, у заказчика не было понимания, как интерфейс должен выглядеть в итоге. Всё, что было известно, — это функциональные требования, которые мы детализировали на встречах со стейкхолдерами, и информация о том, что конечные пользователи продукта — инженеры.
Но, к сожалению, те самые инженеры никогда ранее не работали с подобного рода системами и не могли сформировать чётких требований к интерфейсу.
Поэтому первым делом мы выяснили, как инженер контролирует стабильность каждой батареи. Потом представили, как этот процесс будет работать с большим количеством батарей — ведь независимо от их числа инженер должен оперативно выявлять проблемы и устранять неполадки.
Попутно разбираясь в обширной технической документации, аналитики определили перечень ключевых функций интерфейса: получение и обработка сообщений об ошибках, анализ работы батареи за час и за сутки, поиск батарей по проектам и их владельцам и другие.
Второй этап. Проектирование
Когда разобрались, кто и как будет пользоваться системой, переходим к наброскам интерфейса — на этом этапе фиксируется расположение элементов и логика работы.
В функционал интерфейса мы постарались заложить несколько принципов:
1. Оператор должен контролировать стабильность каждой батареи, потому что если этого не делать, она прослужит меньше времени или в худшем случае произойдёт возгорание.
2. Одновременно нужно контролировать сразу несколько десятков или даже сотен батарей.
3. Каждая батарея принадлежит какому-то клиенту, поэтому инженеру нужна возможность их быстрого поиска и фильтрации, чтобы видеть только нужную информацию.
На этапе проектирования мы определились с ключевыми функциями системы. В прототип же вынесли три самых важных:
1. Контроль стабильности батареи.
2. Получение сообщений об ошибках.
3. Быстрое создание запроса и его получение.
При получении запроса инженеру может выпасть огромный массив данных — около 2400 элементов формируют десятки показателей каждую секунду. Поэтому мы создали фильтрацию по многоуровневой структуре и разработали навигацию по всем уровням элементов.
Чтобы обрабатывать разные показатели и сравнивать их поведение, инженер вручную настраивает параметры и выводит данные в график. Для удобства мы перевели разные метрики, например, вольтаж и температуру, в процентные соотношения, где 0% — минимальное значение за период, а 100% — максимальное.
Чтобы сделать навигацию удобной, мы вынесли поиск батарей по клиентам в отдельную вкладку — таблицу с раскрывающимися списками. Клиентов может быть несколько сотен, поэтому батареи вложены в проекты. Сначала инженер видит общее количество проектов, батарей и их статус. Если показатели батарей какого-то проекта вызывают у него сомнения, он раскрывает необходимую ячейку таблицы.
Чтобы предложить удобные решения для веб-интерфейса, разберитесь с особенностями и ограничениями системы — в том числе и техническими. Например, если вы имеете дело с сенсорным экраном прибора, который физически ограничен высокой рамкой, не стоит располагать элементы интерфейса по краям — иначе им просто невозможно будет пользоваться в полной мере.
Третий этап. Дизайн
Создание и утверждение дизайн-концепции мы начали со сбора мудбордов — визуалов со схожей стилистикой и функциями. Сюда вошли примеры того, как можно оформить интерфейс в целом, а также предложения по основным элементам (таблицам, сложным фильтрам и графикам).
У заказчика ранее уже был разработан дизайн интерфейса экрана BMS для аккумуляторного блока. Чтобы продукты были выполнены в одной стилистике и выглядели как часть одной большой системы, мы решили сохранить преемственность элементов.
Интерфейсы создавали так, чтобы их можно было легко изменить после того, как продукт пройдет тестирование на реальных пользователях.
Например, через дашборд инженер может переходить по вложенным разделам и попадать на нужные ему страницы. При этом блоки дашборда — это свободная сетка, в которой можно убрать некоторые элементы или добавить новые.
Помним, что основная работа инженера в интерфейсе — это настройка фильтров и построение графиков, поэтому прорабатываем их функциональность, добавляем ручное регулирование и отображаем так, чтобы инженер мог легко в них ориентироваться.
Создавая дизайн сложного интерфейса, важно двигаться последовательно. Не забывайте про UI-kit, общую преемственность и простоту всего визуала. Отдельное внимание уделите таким элементам, как масштабируемые графики, фильтры, сортировки и другим «гибким» блокам — и помните про функциональные ограничения устройств, если они есть.