Гайд по принципам и адаптации практик разработки UX/UI для промышленного ПО

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

В условиях неопределенности на этапе проектирования интерфейса возникли споры о том, каким он должен быть. Чтобы максимально подробно сформулировать требования к дизайну, решили провести исследование: пообщались с дизайнерами, изучили литературу, проанализировали личный опыт. В итоге сформировали нечто, что позже, возможно, станет основой для корпоративного стандарта требований для UX/UI промышленного ПО. Результаты легли в основу этого поста.

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

Проблемы UX/UI-дизайн промышленных приложений

Представьте себе, что вы разработчик, создающий интерфейс для сложных промышленных систем, таких как SCADA, АСКУЭ, корпоративные хранилища данных, системы управления данными (DSS), АСУ ТП и т.д. Ваша задача — сделать его не только функциональным, но и удобным для конкретной категории пользователей — инженеров, операторов, прочих тех спецов, пользовательский опыт которых (это особенно актуально в российских реалиях) связан часто с архаичными системами, с не менее архаичными пользовательскими интерфейсами. При этом важно сделать какой-то задел на перспективу, т.е. сделать его действительно удобным, безопасным и снижающим риски.  

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

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

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

1. Перегруженность интерфейса

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

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

2. Недостаточная адаптация к условиям эксплуатации 

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

Пример: Инженер на производстве использует планшет с приложением для мониторинга оборудования. Из-за плохого освещения и мелкого шрифта он не может быстро прочитать данные. Или, в мобильном приложении “электронный наряд-допуск”, небольшие кнопки, которые невозможно нажать в диэлектрических перчатках, которые требует техника безопасности от сотрудника находящегося на объекте.

3. Отсутствие обратной связи

Проблема: Пользователи должны получать своевременную и понятную обратную связь о своих действиях.

Пример: Оператор системы АСУ ТП выполняет команду на остановку оборудования, но не получает подтверждения о выполнении действия. Он не уверен, была ли команда выполнена, и повторяет ее несколько раз.

Проблема: Промышленные приложения должны быть понятными для неопытного пользователя и требовать минимально возможную длительного обучения.

Проблема: Непоследовательность в дизайне интерфейса может запутать пользователей и увеличить вероятность ошибок.

Фрустрация: Не последовательный интерфейс вызывает фрустрацию у пользователей, что снижает их удовлетворенность и производительность.

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

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

Минимализм и фокус на ключевых функциях

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

Решение: Используйте минималистичный дизайн, выделяйте ключевые функции и убирайте все лишнее. Например, в SCADA-системах отображайте только те данные, которые необходимы для текущей задачи, и предоставляйте возможность быстро переключаться между различными режимами отображения. В DSS создайте не один дашборд, а четыре или дайте возможность пользователю кастомизировать размещение блоков информации.

Адаптация к условиям эксплуатации

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

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

Обратная связь и подтверждение действий

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

Риск: Дублирование действий и увеличение нагрузки на систему.

Решение: Внедрить механизмы обратной связи, такие как всплывающие уведомления звуковые сигналы и визуальные индикаторы. Например, в SCADA и системах телеуправления отображается подтверждения успешного выполнения команд и предупреждения о возможных ошибках.

Интуитивность и простота обучения

Принцип: Интерфейс должен быть интуитивно понятным и не требовать длительного обучения.

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

Последовательность и предсказуемость

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

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

Применение законов Яблонски в дизайне промышленных приложений

Джон Яблонски в своей книге “Законы UX-дизайна” описывает несколько ключевых принципов, которые могут значительно улучшить пользовательский опыт. Рассмотрим, как эти законы можно адаптировать для промышленных приложений, таких как SCADA, DSS и системы управления данными.

Закон Якоба

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

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

Закон Фиттса

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

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

Закон Хика

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

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

Закон Миллера

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

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

Закон Постеля

Принцип: Будьте консервативны в том, что вы делаете, и либеральны в том, что вы принимаете от других. Это как вежливый собеседник, который понимает вас даже с ошибками в речи.

Адаптация: В промышленных приложениях это означает, что интерфейсы должны быть устойчивыми к ошибкам пользователей и предоставлять гибкие способы ввода данных. Например, система должна принимать различные форматы ввода данных и корректно обрабатывать их. Это не всегда применимо в промышленных протоколах, там, где есть жесткое ограничение по типу сигнала, например int или flou для телеизмерений в МЭК-104 или обязательные текстовые поля для Namespace OPC UA.

Закон Теслера

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

Адаптация: В промышленных приложениях важно распределять сложность между системой и пользователем. Например, автоматизируйте рутинные задачи и предоставляйте пользователям инструменты для быстрого выполнения сложных операций.

Эффект фон Ресторфф

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

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

Особенности восприятия инженеров

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

Восприятие инженеров

1. Техническая грамотность и опыт

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

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

2. Фокус на функциональности

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

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

3. Высокая толерантность к сложности

Инженеры могут справляться с более сложными интерфейсами, поскольку они привыкли к работе с техническими системами. Они могут легко переключаться между различными режимами и функциями, не теряя при этом эффективности. Именно эта особенность - причина того, что многие вендоры промышленных систем успешно экономят на создании приличного UX/UI и злоупотребляют толерантностью пользователей к сложности, действуя по принципу "и так сойдёт", фокусируются на всем, кроме user friendly интерфейса своего ПО. Тоже касается кастомных корпоративных утилит, когда разработчикам в ИТ-подразделениях промышленных компаний банально не выделяют бюджет на дизайнера, полагая, что они "и так отлично справятся", и исповедуя догму "пользователи у нас не тупые, разберутся если что".

Специфика

1. Поддержка сложных функций

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

2. Высокая степень кастомизации

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

3. Логирование и обратная связь

Инженеры нуждаются в постоянной обратной связи о состоянии системы и выполнении команд. Важно предоставлять подробные логи и уведомления о всех действиях и изменениях. Например, в системах АСУ ТП отображается детализированные логи операций и предупреждения о возможных ошибках.

3. Минимизация когнитивной нагрузки

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

Иерархия принципов создания интерфейса

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

1. Обязательно учесть (несоблюдение может приводить к критическим последствиям и актуализирует серьёзные риски - всегда используется как требование)

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

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

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

1. Обязательно учесть

• Индикация критически значимых процессов

• Уведомления и обратная связь

• Окна подтверждения действий

• Соответствие стандартам 

2. Крайне важно учесть

• Закон Якоба

• Закон Фиттса

• Закон Миллера

• Принцип последовательности и предсказуемости

• Минимализм и фокус на ключевых функциях

3. Желательно учесть

• Закон Постеля

• Закон Теслера

• Эффект фон Ресторфф

• Интуитивность и простота обучения

4. Следует учитывать ситуативно, в зависимости от системы

• Высокая степень кастомизации

• Документация и отчетность

• Принцип адаптации к условиям эксплуатации

В качестве заключения

Букв получилось много.  Надеюсь вы нашли для себя что-то полезное. Вероятно, я описал не всё, т.к. мой опыт и опыт коллег ограничен интерфейсами продуктов, с которыми мы сталкивались. Я всегда рад обсуждению поста и живой дискуссии в комментах, буду рад если комьюнити дополнит описанные принципы практики и особенности тем, что я упустил.