Резюме: При каждом взаимодействии пользователи должны преодолевать две проблемы: понимать текущее состояние системы и выяснять, как его изменить. Дизайнеры могут поддержать их, зная об этих пропастях и преодолевая их с помощью прозрачной концептуальной модели.
На прошлой неделе я купил отличную новую Bluetooth—гарнитуру, а затем, к сожалению, потратил более часа на безуспешные попытки подключить ее к своему компьютеру. Несмотря на обещания, данные как в руководстве по эксплуатации гарнитуры, так и на сайте компьютерной поддержки, гарнитура не подключалась к компьютеру автоматически. Перечитав инструкции, убедившись, что оба устройства включены, просмотрев обзоры гарнитуры, чтобы подтвердить, что она совместима с моим компьютером, и даже протестировав гарнитуру, синхронизировав ее с другим компьютером, я был почти готов сдаться и вернуть проклятую вещь, когда обнаружил случайныйстраница справки (от совершенно другого производителя оборудования), которая все изменила.
На этой новой странице справки показан фактический снимок экрана, показывающий, как выглядит переключатель настроек Bluetooth Windows 10, когда он включен. Взглянув на этот снимок экрана, я сразу понял свою ошибку: экран настроек Bluetooth, на который я смотрел в течение последнего часа, на самом деле показывал мне, что Bluetooth на моем компьютере отключен.
Этот переключатель подключения Bluetooth имеет круг, который можно перемещать из стороны в сторону, чтобы изменить состояние на Выкл (слева) или вкл (справа). Метка отражает текущее состояние элемента управления, а не то, что произойдет, когда переключатель будет перемещен вправо. (В отличие от метки для значка плюса, которая объясняет, что произойдет при нажатии на нее.)
Я почувствовал себя довольно глупо, когда понял свою ошибку. Но моя неспособность понять текущее состояние устройства на самом деле является чрезвычайно распространенной проблемой юзабилити — настолько распространенной, что видимость состояния системы является самой первой в знаменитых 10 эвристиках юзабилити Якоба Нильсена.
Глядя на этот дизайн, становится ясно, что создатели знали, что важно сделать статус видимым: они даже включили явную метку состояния "Выкл." рядом с переключателем управления.
Индикаторы, проверки и уведомления
Так что же пошло не так? Чтобы понять, нам нужно копнуть глубже.
Две из многих проблем, которые люди должны преодолеть, чтобы успешно взаимодействовать с технологиями::
Эти проблемы описываются как “пропасть оценки” и “пропасть исполнения”, поскольку без эффективных элементов дизайна для поддержки пользователей они могут стать непреодолимыми барьерами между пользователями и их целями.
Термины "пропасть оценки" и "пропасть исполнения" были изобретены в 1986 году Эдом Хатчинсом, Джимом Холланом и Доном Норманом, когда они писали о преимуществах прямых манипуляций, помогающих пользователям преодолеть эти пропасти. (Их работа была опубликована в книге “Проектирование систем, ориентированных на пользователя” под редакцией Нормана и Дрейпера, в которой впервые был использован термин "дизайн, ориентированный на пользователя", задолго до того, как Дон присоединился к Якобу Нильсену, чтобы основать Nielsen Norman Group). Книга Дона “Дизайн повседневных вещей” рассказывает историю заливов и подробно описывает их важность в процессе проектирования. Тридцать лет спустя две пропасти по-прежнему являются важными понятиями в нашей области.
Пропасть оценки и пропасть исполнения описывают две основные проблемы, которые пользователи должны преодолеть, чтобы успешно взаимодействовать с любым устройством. Как показано на рисунке, пользователи застряли в (почти) бесконечном цикле, чередующем эти две проблемы: после выполнения вы должны оценить результат, спланировать выполнение следующего шага, оценить этот результат и так далее, пока не достигнете желаемой конечной цели и не уйдете.
Кроме того, обе эти проблемы состоят из подзадач, которые должны выполнить пользователи. Например, успешная оценка требует не только восприятия индикатора состояния системы, но и интерпретации того, что он означает. Аналогично, выполнение требует как планирования действия, основанного на понимании того, как работают элементы управления, так и фактического управления элементами управления. Этот тип детального, конкретного анализа взаимодействия важен, потому что успех в одной подзадаче не обязательно означает успех в других.
Определение того, включено или выключено что-либо, является классическим примером пропасти оценки; для этого переключателя Bluetooth было легко увидеть и переключатель, и метку, но видимость этих элементов не обязательно означала, что они могут быть правильно интерпретированы.