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

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

В исходном варианте процесс состоял из трех шагов:

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

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

3. Необходимо щелкнуть по одной из двух кнопок внизу дисплея: либо «Отменить заказ», либо «Подтвердить заказ».

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

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

Часть решения заключалась в том, чтобы разместить список товаров наверху окна заказа. Таким образом, пользователь мог начать с выделения нужных товаров. А список отделов, который раньше не имел никаких надписей, получил заголовок в форме вопроса: «В какой отдел следует доставить заказанные товары?»

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

Все другие отделы, расположенные в алфавитном порядке, составляли остальную часть списка. Рядом с каждым отделом находился флажок. При установке флажка появлялось сообщение: «Отмеченные товары заказаны», которое исчезало сразу после любого действия пользователя.

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

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

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

Элемент интерфейса можно считать видимым, если он либо в данный момент доступен для органов восприятия человека (обычно это глаза, но здесь также рассматриваются и другие сенсорные модальности), либо он был настолько недавно воспринят, что еще не успел выйти из кратковременной памяти пользователя. Если элемент интерфейса не видим, то мы говорим, что он невидимый. Для нормальной работы интерфейса «должны быть видимы только необходимые вещи – те, что идентифицируют части работающих систем, и те, что отображают способ, которым пользователь может взаимодействовать с устройством. Видимость отображает связь между предпринимаемыми действиями и их реальной отдачей» (Norman, 1988, с. 8).[16] Если интерфейс вынуждает вас запоминать существование того или иного его элемента, это означает, что этот элемент является невидимым. Если вы вынуждены углубляться в недра интерфейса, чтобы случайно или в результате собственной настойчивости натолкнуться на последовательность действий, которая активизирует какой-то его элемент, то этот элемент является невидимым. Если вам приходится обращаться за помощью к справочной системе для того, чтобы узнать, как выполнить то или иное действие, это означает, что методы выполнения этого действия невидимы. Многие компьютерные игры являются, по сути дела, недокументированными интерфейсами, в которых способы управления или пути достижения желаемых результатов невидимы. Стоит добавить к этим играм документацию, и они станут неинтересными. Однако большинство людей не хотят играть в игры, когда им требуется выполнить свою работу, поэтому перед разработчиком интерфейсов стоит задача сделать каждый элемент своего продукта видимым.

Если в интерфейсе соблюдается принцип видимости, то каждая функция и способ ее использования для большинства людей из той культуры, на которую этот интерфейс ориентирован, становятся очевидными только лишь по одному виду. Элемент управления, который имеет такое свойство, стали называть состоятельным (affordance) (Norman, 1988, с. 123). «Состоятельность является хорошим средством для связки элемента интерфейса с его целью. Ручки используются для настройки; гнезда – для вставки чего-то; мячи – для их бросания или пинания» (Norman, 1988, с. 9). Если вы как разработчик помещаете в какой-то продукт ручку, подобную тем, с помощью которых регулируется громкость, пользователи будут пытаться ее крутить. Если вы поместите что-нибудь, наподобие кнопки, пользователи будут пытаться на нее нажимать. То, какую состоятельность будет иметь элемент интерфейса, зависит от опыта и знаний пользователя, а также от контекста, в котором он этот элемент встречает.

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