Кейс: сложные интерфейсы для промышленного оборудования и дизайн-система за 7 месяцев

Дизайнеры FINIK Design Lab (входит в Лигу Цифровой Экономики) разработали интерфейсы для охлаждающего оборудования дата-центров. Рассказываем, какие дизайнерские задачи решили в проекте и почему отказались от Scrum. Статья будет полезна всем, кто создает сложные интерфейсы: производителям оборудования, разработчикам ПО и, конечно, дизайнерам.

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

Нашей задачей было создать несколько интерфейсов:

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

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

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

Реализация заняла 7 месяцев — за этот срок были достигнуты ключевые результаты. Над дополнительными задачами работали еще несколько месяцев.

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

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

Команда несколько раз выезжала на производство к заказчику, чтобы:

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

В этом проекте было решено отказаться от Scrum и Agile. Несмотря на известную эффективность, эти методики управления не подходили из-за сложной структуры согласований. Задачи могли проходить несколько раундов обсуждений, иногда нужно было возвращаться к сделанному или, напротив, отказываться от отдельных идей. Команда составляла план на ближайшие недели и двигалась от одной задачи к другой, иногда на ходу меняя сроки и приоритеты. Гибкое планирование в итоге прекрасно показало себя.

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

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

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

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

Для облачного сервиса собирали другие компоненты, поскольку в десктопной версии размеры элементов меньше. Были необходимы экраны, которые удобно ресайзить под разные устройства. Исходили из ширины 1440 и 1920 пикселей, а в технических условиях указали, какие разрешения лучше использовать.

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

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

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

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

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

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

Горизонтальное размещение требовало больше полезного пространства, а при вертикальном расположении приходилось уменьшать кегль до 10–11, что неудобно для восприятия. Вокруг этого и велись споры, а прийти к правильному выводу помогло AB-тестирование, провести которое предложила команда заказчика. Итоговым решением стало вертикальное расположение с возможностью скрывать описание в выпадающей панели. Таким образом получилось сэкономить пространство и увеличить кегль описания для большего удобства пользователей. Крупные кнопки тоже упрощают считывание и использование.

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

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

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

Александр Зерин, руководитель лаборатории продуктового дизайна FINIK Design Lab: