Якоб Нильсен и Пейдж Лаубхаймер
Дата публикации: 17 февраля 2019 года
Описание: удобство использования приложений повышается, когда пользовательский интерфейс направляет и поддерживает пользователей в процессе работы.
Разработка сложных и при этом удобных приложений является непростой задачей. Создание приложений, обладающих как глубиной для поддержки сложных задач, так и интуитивностью, позволяющей понять, как выполнить эту работу, является огромной проблемой. Мы потратили целый день на эту тему в нашем курсе «Дизайн приложений для Интернета и настольных компьютеров», но мы могли бы легко потратить месяц на каталогизацию всех типов проблем, с которыми мы столкнулись в наших исследованиях пользовательских поведений.
Давать общие рекомендации по распространенным проблемам разработки приложений сложно, потому что многие из проблем, которые мы наблюдаем, зависят от конкретной области. Это было верно 11 лет назад, когда была написана первая версия этой статьи, и остается таковой сегодня.
Таким образом, наша первая рекомендация — провести исследование пользователей с вашей целевой аудиторией:
- Начните с анализа задач и полевых исследований, чтобы понять потребности и рабочие процессы именно ваших пользователей.
- Прототипируйте и тестируйте идеи с низкой точностью, чтобы приблизить основную структуру вашего приложения и его функций, не выделяя много ресурсов на идеи, которые вы будете пересматривать или отказываться от своих пользователей.
- Проектируйте итеративно и тестируйте каждое изменение с небольшим количеством пользователей. Чем больше итераций, тем лучше будет ваше приложение.
Несмотря на специфику, большинство проблем связано именно с юзабилити приложений. В этой статье мы приводим 10 распространенных ошибок, которые мы часто встречаем в разных отраслях. Пять из них (№ 1, 2, 3, 4 и 6) также были и в оригинальной статье, что доказывает неоспоримую важность этих принципов. Все 10 рекомендаций по-прежнему верны, но 5 ошибок (к счастью) сейчас уже менее распространены, чем когда-то; но они были заменены еще 5 новыми проблемами (№ 5, 7, 8, 9 и 10).
Вот актуальный список 10 ошибок проектирования приложений, которые являются вопиющими и банальными. Будем надеяться, что когда мы напишем следующую версию этой статьи через 11 лет, большинство из них будет встречаться гораздо реже.
1. Плохая обратная связь
Одним из основных принципов улучшения юзабилити приложения является четкая обратная связь:
- Покажите пользователям текущее состояние системы.
- Расскажите пользователям, как их команды и действия были интерпретированы системой.
- Расскажите пользователям, что происходит.
- Приложения, которые хранят молчание, заставляют пользователей догадываться. Чаще всего их догадки оказываются неверными.
Хорошие сообщения о многом говорят пользователям — например, правильно ли система нажала кнопку, которую нажал пользователь и будет ли система что-то делать? Что сейчас выбрано или активно?
Один из сценариев, где обратная связь становится важной, — это когда приложение переводится в режим редактирования для изменения существующей информации. Важно, чтобы пользователи имели четкое представление о том, что в данный момент редактируется, поскольку у разных приложений есть различия по объему режима редактирования — например, некоторые приложения будут включать таблицы данных, в которых редактируется одна ячейка или строка, другие будут делать всю таблицу редактируемой. Правильная, четкая обратная связь может донести до пользователей объем редактирования. Хорошая обратная связь может быть реализована различными способами: от использования другого фона для определения текущей редактируемой области до изменения кнопок, связанных с редактированием, для четкого отображения их функций.
Таблица данных с четким указанием того, что отдельная строка является редактируемой
Ушел на 15 минут, не повесив табличку
Вариант отсутствия обратной связи — это когда система не может уведомить пользователей о том, что для выполнения действия требуется много времени. Пользователи часто думают, что приложение не работает, или они начинают нажимать на другие цели.
Если вы не можете соблюдать рекомендуемые сроки ответа, скажите об этом и держите пользователей в курсе событий с помощью индикатора прогресса:
- Если команда занимает от 2 до 10 секунд, покажите анимацию ожидания, такую как «вертушка». Этот индикатор прогресса говорит пользователям «придержите лошадей» и не нажимать на что-либо еще, пока не вернется обычный курсор.
- Если команда занимает более 10 секунд, установите явный индикатор выполнения, предпочтительно в виде индикатора выполненного процента (если вы действительно не можете предсказать, сколько работы осталось до завершения операции).
2. Несоответствие
Помните правило двойного D: различия сложны (double-D rule: differences are difficult). Когда у пользователей есть ожидания относительно того, как что-то будет вести себя или где они могут получить к нему доступ, отклонения от этих ожиданий вызывают путаницу, разочарование и повышенную когнитивную нагрузку, когда люди пытаются разгадать проблему. Человеческий разум жаждет последовательности.
Существует несколько типов несоответствий, которые особенно распространены в сложных приложениях и приводят в замешательство даже опытных пользователей:
- Различные слова или команды для одного и того же действия
- Размещение элементов управления для одной и той же функции в разных местах
- Элементы управления, которые похожи друг на друга (с точки зрения пользователя), но доступны в разных местах (например, один доступен на панели инструментов, другой — в меню, а третий — глубоко в диалоге настроек)
- Подобные шаблоны рабочих процессов, которые требуют взаимодействия с очень разными разделами интерфейса
- Несовместимые правила для допустимых входных данных: иногда запись разрешена, а в других случаях она помечается как недействительная, без какой-либо обратной связи о том, почему это происходит
- Функция иногда доступна, а иногда нет (по таинственным причинам, которые не указаны явно)
- Элементы пользовательского интерфейса или элементы управления, которые перемещаются, нарушая пространственную согласованность
Архитектор в нашем исследовании, который имел многолетний опыт использования AutoCAD, изо всех сил пытался понять, когда она может или не может «стыковать» различные плавающие панели, чтобы закрепить их на одной стороне экрана. В одной и той же сессии она несколько раз пыталась заставить плавающую панель пристыковаться к левой стороне, но безрезультатно. Оказалось, что из-за скрытой установки параметров эту конкретную панель невозможно закрепить, но это ограничение не было сделано явным для пользователя. Скрытая настройка была предназначена для того, чтобы дать опытным пользователям возможность настраивать интерфейс до невероятной степени, но из-за плохой обратной связи наш участник исследования не мог понять, почему док-станция иногда работает, а иногда нет. Этот тип несоответствия является основным источником разочарования даже для опытных пользователей.
Окно AutoCAD, которое не может быть привязано к одной стороне экрана по таинственным причинам
3. Плохие сообщения об ошибках
Сообщения об ошибках — это особая форма обратной связи: они сообщают пользователям, что что-то пошло не так. Мы знаем руководящие принципы для сообщений об ошибках в течение почти 30 лет, и все же многие приложения все еще нарушают их.
Наиболее распространенное нарушение правил — когда в сообщении об ошибке просто говорится, что что-то пошло не так, без объяснения, почему и как пользователь может решить проблему. Такие сообщения оставляют пользователей в затруднительном положении.
Эта проблема усугублялась годами, в основном из-за веб-приложений: пользователям показывают, что что-то пошло не так. Попробуйте снова. Сообщение об ошибке, без подробной информации о причине ошибки или о том, как ее можно исправить. По крайней мере, родные настольные приложения прошлых лет говорили людям в чем заключалась проблема, но часто в техническом жаргоне и непрофессионалы вообще не понимали о чем идет речь.
Коллекция сообщений об ошибках «что-то пошло не так» без каких-либо подробностей
Информативные сообщения об ошибках не только помогают пользователям решить их текущие проблемы, но также могут служить обучающим моментом. Хотя люди не будут тратить время на чтение и изучение функций вашего приложения, они приложат усилия, чтобы понять ситуацию с ошибкой, если вы четко ее объясните, потому что они хотят ошибку устранить.
4. Нет значений по умолчанию
Настройки по умолчанию помогают пользователям во многих отношениях. Что наиболее важно, значения по умолчанию могут:
-
- ускорить взаимодействие, освободив пользователей от необходимости указывать значение, если значение по умолчанию приемлемо
- научить, предоставив пример типа ответа, который отвечает на вопрос пользователя
Направьте начинающих пользователей к безопасному или общему результату, позволяя им принять значение по умолчанию, если они не знают, что еще делать.
Значения по умолчанию могут сэкономить значительные пользовательские усилия в повторяющихся задачах, таких как многократное заполнение одной и той же формы. Определение ключевых значений для полей формы может повысить производительность и уменьшить разочарование пользователя. Ваша аналитика может помочь вам понять, есть ли наиболее часто выбираемый вариант для конкретной области.
В частности, выпадающие меню выигрывают от значимого значения по умолчанию. Многие приложения предоставляют выбор одного (т. е. значение не выбрано вообще) в качестве выбора по умолчанию, заставляя каждого пользователя взаимодействовать с раскрывающимся списком и выбирать значение. Если вы предварительно выберете один вариант (в идеале наиболее распространенный), по крайней мере, некоторым пользователям вообще не придется взаимодействовать с этим раскрывающимся списком.
В случае числовых полей формы, если пользователи очень мало отклоняются от общепринятых значений по умолчанию (например, для полей «Количество»), вы можете использовать шагер, чтобы позволить им корректировать число без ввода (но все же разрешать пользователям вводить другое значение при желании). Степперы имеют два преимущества: они снижают стоимость взаимодействия и дают разумную отправную точку для новых пользователей, которые все еще изучают систему.
Мастер в приложении Mint finance, который извлекает значение по умолчанию и предоставляет кнопки вверх и вниз для изменения значения по умолчанию
5. Иконки без меток
Иконки редко бывают самостоятельными, и большинство пользователей сразу же могут их понять. Даже иконки, которые могут показаться универсальными (например, меню-гамбургер), не настолько знакомы пользователям, как ожидало бы большинство практиков UX. Становится намного хуже, если в вашем приложении есть уникальные иконки; вероятность того, что пользователи поймут, что означают эти уникальные иконки, очень мала. Помните закон Якоба: «пользователи проводят большую часть своего времени на других веб-сайтах». Это означает, что большинство иконок, если рядом с ними нет текстовой метки, пользователям будет трудно или невозможно понять.
Сопряжение иконок с текстовой меткой имеет четыре преимущества:
- Это увеличивает размер цели (что, согласно закону Фитта, сокращает время, необходимое пользователям для доступа к элементу управления).
- Это уменьшает время на распознавание команды: две метки памяти (иконка и текст) лучше, чем одна.
- Относительно предыдущего, он также может облегчить изучение интерфейса (путем создания нескольких ассоциаций с одной и той же командой).
- Это может помочь пользователям визуально различать несколько команд, расположенных рядом друг с другом.
Подборка таинственных иконок без ярлыков из нескольких приложений
6. Трудно получить цели
При взаимодействии человека с компьютером все, на что можно нажать (или кликнуть), называется целью: все активные элементы пользовательского интерфейса являются целями. Чтобы пользователи могли получить цель, они должны быть в состоянии:
- Идентифицировать цель;
- Иметь 100% возможность воспользоваться ею (нажать или кликнуть, получив ответ системы).
Оба эти аспекта вызывают проблемы в современных интерфейсах приложений.
Слабые обозначения
«Доступность» — понимание того, что вы можете сделать с объектом. Например, флажок позволяет включать и выключать, а ползунок позволяет перемещаться вверх или вниз. Значения — это визуальные элементы, которые помогают вам понять преимущества, просто посмотрев на объект, прежде чем вы начнете его использовать (или почувствуете, если это физическое устройство, а не элемент пользовательского интерфейса на экране). Эти концепции обсуждаются в книге Дона Нормана «Дизайн повседневных вещей».
Значения особенно важны в дизайне пользовательского интерфейса, потому что все пиксели экрана позволяют щелкать мышью, даже если при нажатии ничего не происходит. На экране компьютера так много видимых вещей, что у пользователей нет времени на игры, в которых они ищут то, на что можно кликнуть, получив результат (исключение составляют разве что маленькие дети, которые иногда любят просматривать экраны, кликая на все подряд).
В современных приложениях одним из худших нарушителей являются ультраплоские конструкции. Многие плоские проекты имеют слабые значения для целей: люди не могут легко отличить текст от кнопок, потому что у кнопок нет традиционных 3D-подсказок.
Распространенными симптомами слабых обозначений являются:
- Вопрос пользователя: «Что мне здесь делать?»
- Пользователи ходили рядом, но так и не нашли функцию, которая могла бы им помочь.
- Обилие экранного текста в попытке решить эти две проблемы. Еще хуже — обстоятельные многоступенчатые инструкции, которые предательски исчезают после выполнения первого из нескольких действий.
Крошечные размеры области кликов
Основная проблема здесь заключается в том, что область клика настолько мала, что пользователи промахиваются и щелкают за пределами активной области. Даже если пользователь изначально правильно понял цель, промахнувшись, он начинает думать, что ошибся, потому что он ведь нажал, но ничего не произошло. Небольшие размеры области клика представляют собой особую проблему для пожилых пользователей и пользователей с ограниченными двигательными навыками.
7. Чрезмерное использование модальных окон
Многие приложения используют модальные окна для реализации взаимодействия с данными — редактирование существующего элемента, добавление нового элемента, удаление или даже чтение дополнительных сведений об элементе. Модальные окна появляются поверх текущей страницы, фоновое содержимое обычно при этом затемняется (при условии, что затемнение уменьшит отвлекающие факторы и поможет пользователям сосредоточиться на поставленной задаче). К сожалению, этот выбор дизайна уменьшает контекст для пользователей, скрывая информацию, на которую они могут ссылаться при заполнении формы.
Обратите внимание на то, что даже если страница, поверх которой появилось модальное окно не содержит информации, необходимой для редактирования, пользователи часто пытаются использовать работу, проделанную ранее, путем копирования и вставки предыдущих входных данных или даже просто используя другие записи в качестве шаблонов.
Модальное окно, перекрывающее важную информацию
8. Бессмысленная информация
Длинные строки из букв и цифр, такие как автоматически генерируемые идентификаторы в базе данных, часто используются для уникальной идентификации элемента в приложении. Эти строки совершенно бессмысленны для пользователей, но они часто отображаются в виде первого столбца таблицы, заставляя людей просматривать этот первый столбец, чтобы найти информацию, которая им действительно нужна. Хотя эти бессмысленные индексы важны для серверной части, они не должны быть основной частью информации, к которой должны обращаться пользователи. Особенно на страницах с высокой плотностью информации, необходимо в первую очередь обеспечить пользователя удобочитаемой информацией в качестве основной опорной точки и перенести идентификаторы в менее заметное место.
Широко распространенное использование закодированной информации часто встречается в медицинских приложениях, системах CRM (где пользователям часто приходится выбирать код для каждого взаимодействия продаж со своими клиентами), бухгалтерском программном обеспечении и корпоративных приложениях. Во всех этих приложениях информация, значимая для людей, обобщается с помощью короткого кода, чтобы сделать его более компактным. Короткий код может уместиться в небольшой области лучше, чем целое предложение, но создает гораздо большую когнитивную нагрузку на пользователей. Им нужно будет перевести закодированную информацию, чтобы понять ее. Даже высококвалифицированные специалисты не могут вспомнить все возможные коды, и им также потребуется много усилий, чтобы сделать этот мысленный перевод.
Таблица с закодированной информацией
9. Меню — ящик для хлама
Если ваше приложение имеет сотни или даже тысячи функций, вам нужно где-то разместить элементы управления этими функциями, и, кроме того, вам нужно расставить приоритеты и упорядочить их, чтобы пользователи могли легко находить и быстро получать доступ к наиболее важным из них. Одним из следствий этого ограничения часто является переполнение меню: наиболее часто используемые действия отображаются на панели инструментов, а последний элемент, помеченный «Дополнительные действия» или «Инструменты», или, что хуже всего «…» (многоточием) содержит все остальное, что не вошло в одну строку.
Эти ярлыки меню имеют слабый «информационный запах» и представляют собой не что иное, как ящик для хлама: место для размещения всего, что вы не можете иначе классифицировать, но не хотите выбрасывать. Они часто появляются из-за того, что команда имеет список необходимых функций, но не знает, где их разместить, или в устаревших приложениях не может удалить старые, редко используемые функции.
Проблема переполнения меню состоит в том, что, как и в случае с ящиком для хлама в вашем доме, никто не может знать, что вы могли в него положить. Другими словами, это ограничивает как возможности обнаружения, так и возможности поиска функций, поскольку у большинства пользователей нет причин искать их в этих скрытых меню.
Загадочное меню с многоточием
Меню ящика для хлама, помеченное только словом «Еще»
10. Близость разрушительных и подтверждающих действий
Помещение таких действий, как «Сохранить», рядом с действиями, которые уничтожают такие работы, такие, к примеру, как «Отмена», является обычным дизайнерским решением, которое вызывает много боли у пользователей. Хотя с логической точки зрения такое размещение часто имеет смысл (например, «Сохранить» и «Удалить» связаны с тем, что они определяют судьбу элемента), оно также позволяет легко нажимать «неправильную кнопку» или иконку — особенно когда пользователи спешат, выполняя повторяющиеся действия или имеют физические трудности. Этот тип непреднамеренной замены одного действия другим называется ошибкой.
Мастер с последним шагом, имеющим кнопки «Отмена» и «Готово», расположенные рядом друг с другом.
Кнопка «Пометить» для отслеживания почты расположена прямо рядом со значком «Удалить» в приложении электронной почты
Резюме
Приложения в значительной степени зависят от предметной области, поэтому удобное в использовании, эффективное и приятное приложение для одной отрасли может привести к полной катастрофе в другой.
Если вы хотите создать полезное приложение, будьте готовы проводить с вашими пользователями исследования, для определения их рабочих процессов, необходимых им функций, а также их умственных моделей и ожиданий.
Тем не менее, 10 ошибок приложения, изложенные здесь, представляют собой общие темы, которые мы наблюдаем в исследованиях в различных отраслях, в том числе в творческой, финансовой, предпринимательской, медицинской, инженерной и других.
Перевод: Арина Гаврилова