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

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

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

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

тут содержательная, но достаточно длинная вводная часть (можно пропустить, если мало времени)

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

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

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

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

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

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. Следует учитывать ситуативно, в зависимости от системы

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

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

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

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

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