Элементы управления

Вести океанское исследовательское судно или марсианский исследовательский шаттл дело серьёзное. Остаётся надеяться, что приборная панель будет высшего качества. Ширина в два шипа, уклон в 45, распространённая деталь из Lego 2x2 decorated slope это интерфейс этого игрового набора, связывающий его с внешним видом.

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

Добро пожаловать в мир пользовательского восприятия от Lego.

Организованный хаос

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

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



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

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

Давайте подробнее разберёмся с ответами на эти вопросы в Lego.

Различаем устройства ввода

Из-за чего 400 пилотов во время Второй Мировой войны стали бы убирать шасси на бомбардировщике Б-17 перед самой посадкой? Что это катастрофическая ошибка человека или нечто более фундаментальное?

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


Севший на брюхо Б-17 и кодирование функций формой, позволившее избежать проблем

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

Сравним три интерфейса, показанных ниже, чтобы увидеть, как это работает. Не обращайте внимания на общую схему расположения элементов сейчас для нас важны отдельные кнопки. Представьте, что вы пытаетесь нащупать одну из них, не глядя. При работе с левой панелью, Slope 45 2 x 2 with 12 Buttons, понадобится чёткая координация рук и глаз. На правой панели, Aircraft Multiple Flight Controls, проводится чёткое различие между рычагом управления (размашистое вертикальное движение по прямой), переключателями (круглые вертикальные тумблеры) и кнопками (квадратики).


Слева направо: ужасное, плохое и неплохое различие между элементами управления

Подобная дифференциация и по сей день остаётся серьёзной проблемой. В 2015 году Ford отозвала 13 500 кроссоверов Lincoln MKC, поскольку водители, двигаясь с большой скоростью по шоссе, по ошибке постоянно отключали двигатель, пытаясь активировать спортивный режим. Сможете ли вы понять, отчего так происходило?


Панель управления Ford Lincoln MKC до того, как кнопку запуска/останова двигателя перенесли.

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


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

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

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

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


Шесть различных типов кодирования в интерфейсах Lego (слева направо, сверху вниз): размер, форма, цвет, текстура, расположение, метод работы.

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

Организация устройств ввода

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


Базовая дифференциация методом группировки

Довольно просто. Но как нам решить, какие устройства ввода нужно группировать?

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



Такие панели я назвал бы консолидированным интерфейсом. Все элементы ввода и обратной связи собраны на одной панели. Такой подход избрал Дайсон для своего автомобиля. Теперь представьте себе противоположный пример мы перенесли все эти переключатели и лампочки на места расположения реальных клапанов на фабрике. Звучит смехотворно однако эти решётки вентиляции на Audi TT показывают, что распределённый подход тоже может прекрасно подойти пользователям. Я подробно писал о распределённых интерфейсах в прошлом году.


Панели от машин Lego: распределённый интерфейс (слева) против консолидированного (справа)

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

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


Интерфейсы Insectoid и UFO от Lego. Интересно, за что конкретно отвечают эти кнопки?

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


Аппарат искусственной вентиляции лёгких при коронавирусе от компании Cambridge Consultants с явной организацией по функциональным особенностям.

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



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

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


Боб и Даг в капсуле SpaceX Dragon

В Lego мы встречаемся с организацией на базе функциональных особенностей на панели Monitor with -19 pattern. Две явных группы элементов управления возможно, для контроля температуры и для отслеживания показателей жизнетеятельности. Не знаю, что делают все эти переключатели на второй панели, однако они явно сгруппированы по методу работы, а не по функциональности.

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


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

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

Представьте, что рабочие ежедневно с утра прибывают на фабрику Lego, где сканируют людей. Группировка элементов управления по задачам (подготовка машины, загрузка тела, запуск сканирования) предполагает разнесение кнопок облучения и сканера по многим участкам панели. Для компьютера это будет сложнее, а для оператора удобное. Только разработчик и пользователи будут решать, что им лучше подойдёт.

Но какой же интерфейс лучше?

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

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

Всем привет, меня зовут Миша Хананашвили, я автор канала UXHorn и работаю исследователем в Сбере.

Перевести статью ребят из NN-Group сподвигла потребность дать простую и понятную инструкцию для дизайнеров из продуктовых команд, к которой можно обращаться при необходимости. Так как статья вышла на днях, решил перевести и заодно поделиться со всеми полезным материалом. Спасибо Юре Ветрову за наводку. Оригинал статьи можно найти тут

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

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

Вот скриншот:



Панель управления для приложения WebEx для настольных ПК:
Вверху Без звука;
Внизу Заглушенное состояние


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

Я много раз видел, как пользователи становились жертвами этой проблемы. Mute кнопка используется для переключения между двумя состояниями системы (Mutes и UnMuted), но проблема в том, что пользователи не могут легко сказать какое сейчас текущее состояние и на которое переходя (Кроме того, вопреки лучшим практикам в дизайне значков, в реализации WebEx отсутствует текстовая метка для кнопки отключения звука).

Два элемента информации, два элемента управления

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

1. Текущее состояние системы Вкл или Выкл; в примере с микрофоном Mute или UnMute;
2. Что произойдет, если пользователь нажмёт на кнопку то есть следующее состояние, которое может быть Выкл или Вкл, в зависимости от текущего состояния (в примере микрофона Unmute или Mute).

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

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


Tesla для iPhone:
(Слева) Значок над кнопкой разблокировки служит индикатором состояния; кнопка Unlock это кнопка переключения состояния, на которой четко указано, что произойдет, если пользователи нажмут ее.
(Справа) Состояние и метка кнопки изменяются, когда пользователь разблокирует автомобиль.

Два состояния информации, один элемент управления

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

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

Иногда состояние можно легко определить по другим сигналам. Например, в проигрывателе видео есть только один элемент управления (кнопка Play), которая указывает будущее состояние. Однако сигналов достаточно, чтобы понять, что видео воспроизводится пользователь может слышать аудио или видеть изменения картинки на экране.


YouTube: значок воспроизведения заменяется на паузу при воспроизведении видео. Значок указывает на состояние, в которое система перейдет при нажатии кнопки.

Если вам нужно использовать один элемент управления для обозначения состояния и того, что будет дальше, как следует его обозначить?

В этой ситуации можно рассмотреть две альтернативы:

1. Метка кнопки сообщает состояние, в которое система перейдет, если эта кнопка будет нажата, то есть он сообщает пользователю, что произойдет дальше.
   
   Это стандартная рекомендация для дизайна кнопок. В частности, кнопка регистрации на сайте будет называться Зарегистрироваться, а кнопка отправки для формы проверки электронной торговли будет называться Покупка или Разместить заказ.
   
   Если кнопка используется для переключения между двумя состояниями, чтобы следовать этой рекомендации, она также должна изменить метку, как в примере Tesla выше или в примере OBS ниже.
   
   
   OBS Studio: кнопка Start Recording соответствует классическим рекомендациям по именованию и переключает метку на Stop Recording после начала записи.
   
   Если текстовой метки нет (предположительно, потому что значок достаточно четкий), значок должен меняться в зависимости от состояния, в которое он перемещает систему. Классическим примером является взаимодействие между значками воспроизведения и паузы, показанное в приведенном выше примере YouTube и присутствующее в большинстве видеоплееров.
2. Кнопка сообщает об активном состоянии с помощью тени.
   
   Вот что действительно происходило с кнопками включения/выключения: при нажатии на них они не меняли ярлык, а опускались вниз. Чтобы уловить эту метафору, в дизайне пользовательского интерфейса дизайнеры обычно добавляют тень, чтобы указать, что кнопка была нажата и теперь она активна.
   
   
   
   В Word значок B для полужирного (слева) приобретает тень при выборе (справа), чтобы указать, что вы используете полужирный режим, а не обычный. В этой реализации кнопка не меняет метку при нажатии пользователем.

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

• Красный цвет используется в интерфейсе произвольно например, кнопка X (Exit) тоже красная, и это не может означать, что она активна. (Если красный цвет представляет активное состояние, что будет означать красный крестик? Что я уже покинул собрание?)
• Другой цвет (синий) используется для обозначения активного состояния других кнопок, таких как Видео и Чат (т. е. Синий значок видео сигнализирует о том, что видео включено).

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

Кстати, приложение Телефон на iPhone использует ту же реализацию, с той лишь разницей, что оно более согласованно, чем WebEx, и использует белую заливку для обозначения активного состояния. Даже с этими настройками трудно определить активное состояние кнопки.



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

Рекомендации

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

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

1. Текстовая метка, указывающая, что произойдет, если пользователь нажмет на этот элемент управления.
2. Значок, указывающий текущее состояние системы

Щелчок по любому из них изменит состояние.



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

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

• Текущее состояние
• Что будет, если они нажмут этот элемент управления

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

Очевидно ли, что это два противоположных состояния?

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

Существуют ли внешние сигналы (например, шумы, визуальные изменения в окружающей среде), которые могут помочь пользователям определить текущее состояние?

• Если нет, то используйте дизайн с двумя элементами управления, с индикатором состояния (чтобы четко передать текущее состояние) и кнопкой для переключения состояния.
• Если да, то можно рассмотреть один элемент дизайна кнопку переключения состояния.

Потребуется ли пользователям быстро определять состояние и изменять его (как в случае с кнопкой Mute)?

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

Спасибо за время и подписывайтесь на тг канал UXHorn, там я стабильно размещаю самые интересные статьи по теме UX и исследований.