Материал был опубликован на Rusbase

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

Ведущий дизайнер UX-студии Everest Рома Зорин на примере одного из проектов компании поделился своим опытом, как действовать дизайнерам при проектировании уникальной и сложной системы.

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

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

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

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

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

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

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

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

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

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

✦ Совет

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

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

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

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

1. Оператор должен контролировать стабильность каждой батареи, потому что если этого не делать, она прослужит меньше времени или в худшем случае произойдёт возгорание.

2. Одновременно нужно контролировать сразу несколько десятков или даже сотен батарей.

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

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

1. Контроль стабильности батареи.

2. Получение сообщений об ошибках.

3. Быстрое создание запроса и его получение.

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

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

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

✦ Совет

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

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

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

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

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

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

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

✦ Совет

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

Что в итоге

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

1. Разобраться, кто будет пользоваться продуктом — определить ЦА и пообщаться с этими людьми.

2. Определить, как им будут пользоваться — сформировать ключевые сценарии.

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

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

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