Аннотация: Удобство использования приложений становится выше, когда пользовательский интерфейс направляет пользователей и помогает им в процессе работы.
Разработка сложных приложений является задачей не из легких. Создание приложений, обладающих как глубиной для поддержки сложных задач, так и интуитивностью, является огромной проблемой.
Сложно давать общие рекомендации по распространенным проблемам разработки приложений, потому что многие из проблем, которые мы наблюдаем, зависят от конкретной области. Это было правдой еще 11 лет назад, когда была написана первая версия этой статьи, и это до сих пор актуально.
Таким образом, наша первая рекомендация - провести исследование пользователей с вашей целевой аудиторией:
- Начните с анализа задач и полевых исследований, чтобы понять потребности ваших пользователей и рабочие процессы.
- Прототипируйте и тестируйте идеи низкого качества, чтобы проработать основную структуру вашего приложения и его функции. Не выделяйте много ресурсов на идеи, которые вы будете пересматривать или от которых вовсе откажетесь, узнав отношение пользователей.
- Проектируйте итеративно и тестируйте каждое изменение с небольшой аудиторией. Чем больше итераций, тем лучше будет ваше приложение.
Несмотря на конкретные проблемные отрасли у большинства юзабилити приложений, здесь описаны 10 распространенных ошибок, которые мы часто встречаем в разных отраслях. Пять из этих вопросов (№ 1, 2, 3, 4 и 6) также были включены в первоначальную статью, что показывает, каковы принципы долговременного использования. Все 10 первоначальных руководств по-прежнему верны, но 5 ошибок (к счастью) уже менее распространены и их заменили на 5 более актуальных проблем (# 5, 7, 8, 9 и 10).
Вот наш текущий список -топ 10 ошибок в разработке приложений, которые одновременно являются как вопиющими, так и обычным явлением.
1. Плохая обратная связь
Одним из основных принципов повышения юзабилити приложения является предоставление четкой обратной связи:
- Показывать пользователям текущее состояние системы
- Расскажите пользователям, как были интерпретированы их команды и действия
- Сообщайте пользователям, что происходит
Приложения, которые молчат - заставляют пользователей угадывать, что происходит. Часто они предполагают неправильно.
Хорошая обратная связь говорит пользователям многое - к примеру, кнопка, которую они кликнули правильно интерпретируются системой как «клик» и реагирует ли система? Что сейчас выбрано или активно?
Один из случаев, где обратная связь становится важной, - это когда приложение переводится в режим редактирования для изменения существующей информации. Важно, чтобы пользователи чётко понимали, что в настоящее время редактируется, поскольку приложения будут различаться по объему режима редактирования - например, некоторые приложения будут включать таблицы данных, в которых редактируется одна ячейка или строка, другие будут делать редактируемой всю таблицу.
Правильная, четкая обратная связь может донести до пользователей объем редактирования; Хорошая обратная связь может быть реализована различными способами, от использования другого фона для определения текущей редактируемой области до изменения кнопок, связанных с редактированием, чтобы четко показать их функцию.
В режиме редактирования это приложение от Telerik.com добавляет серый фон в строку таблицы, которая в данный момент редактируется, изменяет ячейки так, чтобы они выглядели как поля формы, и изменяет кнопки «Изменить» и «Удалить» на «Обновить» и «Отмена» с другим макетом. Изменение расположения и цвета кнопок является дополнительным, важным сигналом в этой обратной связи, так как снижает вероятность того, что пользователи нажмут неправильную кнопку после редактирования, если они не обращают внимания и полагаются на мышечную память. Этот уровень обратной связи четко указывает на что происходит с системой и как она реагирует на ввод пользователя.
1.a. "Выход на обед" без индикатора прогресса
Вариант отсутствия обратной связи - это когда система не может уведомить пользователей о том, что для выполнения действия требуется много времени. Пользователи часто думают, что приложение не работает или начинают нажимать на другие кнопки.
Если вы не можете соблюдать рекомендуемое время отклика, скажите об этом и держите пользователей в курсе событий с помощью индикатора прогресса:
- Если команда занимает от 2 до 10 секунд, покажите анимацию ожидания, в виде спинера. Индикатор прогресса этого типа говорит пользователям "придержать своих лошадей" и не нажимать на что-либо еще, пока не вернется обычный курсор.
- Если команда занимает более 10 секунд, установите явный индикатор выполнения, предпочтительно в виде индикатора процента выполненных работ (если вы действительно не можете предсказать, сколько понадобится времени до завершения операции)
2. Несоответствие
Помните правило двойного D: различия сложны (differences are difficult). Когда у пользователей есть ожидания относительно того, как что-то будет работать или где они могут получить доступ, отклонения от этих ожиданий вызывают путаницу, разочарование и повышенную когнитивную нагрузку, когда люди пытаются решить проблему. Человеческий разум жаждет последовательности.
Существует несколько типов несоответствий, которые особенно распространены в сложных приложениях и приводят в замешательство даже опытных пользователей:
- Разные слова или команды для одного и того же действия
- Размещение элементов управления для одной и той же функции в разных местах
- Элементы управления, которые похожи друг на друга (с точки зрения пользователя), но доступны в разных местах (например, один доступен на панели инструментов, другой - меню, а третий - глубоко в диалоге настроек)
- Подобные структуры рабочего процесса, которые требуют взаимодействия с самыми разными разделами интерфейса
- Несовместимые правила для допустимых входных данных: иногда запись разрешена, а в других случаях она помечается как недействительная, без какой-либо обратной связи о том, почему это происходит
- Функция иногда доступна, а иногда нет - по таинственным причинам, которые не указаны
- Элементы пользовательского интерфейса или элементы управления, которые перемещаются, нарушая пространственную согласованность
Архитектор в нашем исследовании, имевшая многолетний опыт использования AutoCAD, изо всех сил пыталась понять, когда она может или не может «стыковать» различные плавающие панели, чтобы закрепить их на одной стороне экрана. В одной и той же сессии она несколько раз пыталась заставить плавающую панель пристыковаться к левой стороне, но безрезультатно.Оказалось, что из-за скрытой установки параметров эту конкретную панель невозможно закрепить, но это ограничение не было явно показано пользователю. Скрытая настройка была предназначена для того, чтобы дать опытным пользователям возможность настраивать интерфейс до невероятной степени, но из-за плохой обратной связи наш участник исследования не мог понять, почему док-станция иногда работает, а иногда нет. Этот тип несоответствия является основным источником разочарования даже для опытных пользователей.
AutoCAD не всегда позволял нашему участнику исследования «закреплять» панели на одной стороне экрана. Даже опытный пользователь не может определить, почему эта функция работает на некоторых панелях, а на других нет. (Оказалось, что для этой панели скрытый параметр отключен.)
3. Некачественные сообщения об ошибках
Сообщения об ошибках - это особая форма обратной связи: они сообщают пользователям, что что-то пошло не так. Мы знаем руководящие принципы для сообщений об ошибках почти 30 лет, и все же многие приложения все еще нарушают их.
Наиболее распространенное нарушение правил - когда в сообщении об ошибке просто говорится, что что-то не так, без объяснения, почему и как пользователь может решить проблему. Такие сообщения оставляют пользователей в замешательстве.
Эта проблема усугублялась годами, в основном из-за веб-приложений: пользователям показывают, что что-то пошло не так. Попробуйте снова - сообщение об ошибке, без подробностей о причине ошибки или о том, как ее можно исправить. По крайней мере, десктопные приложения прошлого года сообщали людям (часто в техническом виде и непрофессионалы не могли понять ), в чем заключалась проблема.
Набор расплывчатых сообщений «Что-то пошло не так» от Quicken (вверху слева), Dropbox (вверху справа), IBM Verse (внизу): ни одно из них не описывает суть проблемы, подробности о том, как ее решить, и была ли работа пользователя потеряна в процессе.
Информативные сообщения об ошибках не только помогают пользователям решить свои текущие проблемы, но также могут служить обучающим моментом. Хотя люди не будут тратить время на чтение и изучение функций вашего приложения, они попытаются понять ситуацию с ошибкой, если вы четко объясните ее, потому что они хотят её решить.
4. Отсутствие значений по умолчанию
Настройки по умолчанию помогают пользователям во многих отношениях. Самое главное, значения по умолчанию могут:
- ускорить взаимодействие, освободив пользователей от необходимости указывать значение, если значение по умолчанию приемлемо
- научить, предоставляя пример типа ответа, который подходит для вопроса
- направить начинающих пользователей к безопасному или общему результату, позволив им принять значение по умолчанию, если они не знают, что еще делать
Значения по умолчанию могут сэкономить усилия в повторяющихся задачах - многократное заполнение одной и той же формы. Определение ключевых значений для полей формы может повысить производительность и уменьшить разочарование. Анализ может помочь вам понять, есть ли наиболее часто выбранный вариант для конкретной области.
В частности, выпадающие меню выигрывают от значимого значения по умолчанию. Многие приложения предоставляют выбор одного (т. е. значение не выбрано вообще) в качестве выбора по умолчанию, заставляя каждого пользователя взаимодействовать с раскрывающимся списком и выбирать значение. Если вы предварительно выберете один вариант (в идеале наиболее распространенный), по крайней мере, некоторым пользователям вообще не придется взаимодействовать с этим раскрывающимся списком.
С числовыми полями формы, если у пользователей незначительные отклонения от общего значения по умолчанию (например, по количеству полей), то можете использовать степпер, чтобы позволить им регулировать число без ввода (но все же позволяя пользователям вводить другое значение, если это необходимо). Степперы имеют два преимущества: они снижают количество взаимодействия и дают разумную отправную точку для новых пользователей, которые все еще изучают систему.
Mint, приложение для личных финансов, имеет функцию, которая помогает пользователям найти кредитные карты, которые соответствуют их потребностям. Этот мастер использовал хорошие значения по умолчанию, автоматически импортируя средние ежемесячные расходы пользователей на кредитные карты и предоставляя пользователю простой способ изменить это число, набрав или используя кнопки увеличения / уменьшения.
5. Значки без меток
Иконки редко не чем не подкреплены, но большинство пользователей сразу же могут их понять. Даже значки, которые могут показаться универсальными (например, меню гамбургеров), не настолько знакомы пользователям, как ожидало бы большинство практиков UX. Становится намного хуже, если в вашем приложении есть уникальные значки; вероятность того, что пользователи поймут, что означают эти уникальные значки, очень мала. Помните закон Якоба: «пользователи проводят большую часть своего времени на других веб-сайтах». Это означает, что большинство значков без текстовой метки, пользователи не смогут понять.
4 преимущества сопряжений значков с текстовой меткой:
- Увеличивает размер значка (что, согласно Закону Фиттса, сокращает время, необходимое пользователям для доступа к элементу управления).
- Это сокращает время распознавания команды: две метки (значок и текст) лучше, чем одна.
- Относительно предыдущего, это также может облегчить изучение интерфейса (путем создания нескольких ассоциаций с одной и той же командой).
- Это может помочь пользователям визуально различать несколько команд, расположенных рядом друг с другом.
В наших недавних исследованиях представлены значки без меток из различных приложений для десктопных устройств: все значки - нестандартные, которые не указывают четко их назначение. Можете ли вы угадать, что они обозначают? Наши участники исследования не могли.
6. Трудно достичь цели
При взаимодействии человека с компьютером все, на что можно нажать, называется целью: все активные элементы пользовательского интерфейса являются целями. Чтобы пользователи могли получить цель, они должны быть в состоянии (1) идентифицировать цель; (2) нажать на нее. Оба эти аспекта вызывают проблемы в современных интерфейсах приложений.
6а. Слабые сигнификаторы
«Доступность» означает, что вы можете сделать с объектом. Например, флажок позволяет включать и выключать, а ползунок - перемещаться вверх или вниз. Сигнификаторы - это визуальные элементы, которые помогают вам понять преимущества, просто посмотрев на объект, прежде чем вы начнете его использовать (или почувствуете, если это физическое устройство, а не элемент пользовательского интерфейса на экране). Эти концепции обсуждаются в книге Дона Нормана «Дизайн повседневных вещей».
Сигнификаторы особенно важны в дизайне пользовательского интерфейса, потому что все пиксели экрана позволяют щелкать мышью, даже если при нажатии ничего не происходит. На экране компьютера есть так много видимых вещей, что у пользователей нет времени на раздумья, они клацают на всё, пытаясь найти что-то действенное. (Исключение: маленькие дети иногда любят просматривать экраны, нажимая на всё вокруг.)
В современных приложениях одним из худших нарушителей являются ультраплоские конструкции. Многие плоские конструкции имеют слабые значения для целей: люди не могут легко отличить текст от кнопок, потому что у кнопок нет традиционных 3D-подсказок.
Распространенными признаками слабых сигнификаторов являются:
- Пользователи говорят: «Что я здесь делаю?»
- Пользователи не приближаются к функции, которая поможет им.
- Обилие экранного текста пытается преодолеть эти две проблемы. (Еще хуже многоступенчатые инструкции, которые исчезают после выполнения первого из нескольких действий.)
6b. Крошечный размер цели для нажатия
Проблема заключается в том, что размеры целей настолько малы, что пользователи пропускают и щелкают за пределами активной области. Даже если они изначально поняли, куда нужно нажать, пользователи могли изменить свое мнение и начать верить, что объект не работает, ведь после их клика ничего не произошло.
(Крошечные размеры целей представляют собой особую проблему для пожилых пользователей и пользователей с инвалидностью.)
7. Злоупотребление модальных окон
Многие приложения используют модальные окна для реализации взаимодействия с данными - редактирование существующего элемента, добавление нового элемента, удаление или даже чтение дополнительных сведений об элементе. Модалы появляются в верхней части текущей страницы, а фоновое содержимое обычно тусклое (при условии, что затемнение уменьшит отвлекающие факторы и поможет пользователям сосредоточиться на поставленной задаче). К сожалению, этот выбор дизайна уменьшает контекст для пользователей, скрывая информацию, на которую они могут ссылаться при заполнении формы. (Обратите внимание, что даже если закрытое окно не содержит информации, необходимой для редактирования, пользователи часто пытаются использовать работу, которую они сделали ранее, копируя и вставляя предыдущие входные данные, или даже просто используя другие записи в качестве шаблонов для того, чтобы думать о текущей задаче.)
8. Бессмысленная информация
Длинные строки букв и цифр, такие как автоматически генерируемые идентификаторы в базе данных, часто используются для уникальной идентификации элемента в приложении. Эти строки абсолютно бессмысленны для пользователей, но они часто отображаются в виде первого столбца таблицы, заставляя людей просматривать этот первый столбец, чтобы найти информацию, которая им нужна. Хотя эти бессмысленные индексы важны для серверной части, они не должны быть основной частью информации, к которой должны обращаться пользователи. Особенно в экранах с высокой плотностью информации, предоставлять удобочитаемую информацию в качестве основной и убрать идентификаторы в менее заметное место.
Широко распространенное использование закодированной информации часто встречается в медицинских приложениях, системах CRM (где пользователям часто приходится выбирать код для каждого взаимодействия продаж со своими клиентами), бухгалтерском программном обеспечении и корпоративных приложениях. Во всех этих приложениях информация, значимая для людей, обобщается с помощью короткого кода, чтобы сделать её более компактной. Короткий код может уместиться в небольшой области лучше, чем целое предложение, но возлагает гораздо большую когнитивную нагрузку на пользователей. Им нужно будет перевести закодированную информацию, чтобы понять ее, и наша рабочая память ограничена с самого начала. Даже высококвалифицированные специалисты не могут вспомнить все возможные коды, и им по-прежнему требуется много усилий, чтобы сделать этот мысленный перевод.
Эта таблица содержит бессмысленную идентификационную информацию в качестве первого столбца; поля Net Code и Location Code также включают в себя закодированную информацию, предназначенную для представления сложной информации в компактном пространстве. Имя местоположения - единственный столбец, который имеет смысл для пользователей; чтобы расшифровать остальные, люди должны либо полагаться на свою память, либо обращаться к списку кодовых ключей.
9. Меню как мусорный бак
Если ваше приложение имеет сотни или даже тысячи функций, вам нужно где-то разместить элементы управления этими функциями. Кроме того, вам нужно расставить приоритеты и упорядочить их, чтобы пользователи могли легко находить и быстро получать доступ к наиболее важным. Одним из следствий этого ограничения часто является переполнение меню: наиболее часто используемые действия отображаются на панели инструментов, а конечный элемент, помеченный «Дополнительные действия» или «Инструменты», или, что хуже всего, содержит все остальное, что не подходит.
Эти ярлыки меню имеют слабый информационный "запах" и представляют собой не что иное, как ящик для мусора: место для всего, что вы не можете классифицировать иначе, но не хотите выбрасывать. Они часто появляются из-за того, что команда имеет список необходимых функций, но не знает, где их разместить. Или же в устаревших приложениях не может удалить старые, редко используемые функции. Проблема с переполнением меню состоит в том, что, как и в случае с мусорным ящиком в вашем доме, никто не может знать, что вы могли в него положить. Другими словами, это ограничивает как возможности обнаружения, так и возможности поиска функций, поскольку у большинства пользователей нет причин искать эти меню.
10. Близкое расположение отменяющих и подтверждающих действий
Помещение таких действий, как «Сохранить», рядом с действиями, которые уничтожают работы, как «Отмена», является обычным дизайнерским решением, которое вызывает много горя у пользователей. Хотя с логической точки зрения такое размещение часто имеет смысл (например, «Сохранить» и «Удалить» связаны с тем, что они решают судьбу элемента), но оно также позволяет легко нажимать неправильную кнопку или значок - особенно когда пользователи спешат, выполняя повторяющиеся действия. Этот тип непреднамеренной замены одного действия другим называется ошибкой.
Veeam, корпоративное программное обеспечение для резервного копирования, содержит многошаговый мастер для настройки нового задания резервного копирования. В нашем исследовании пользователь потратил почти 20 минут, чтобы пройти через этот мастер, и почти нажал кнопку «Отмена», а не «Готово» на последней странице сводной информации из-за близости двух кнопок. Если бы этот пользователь нажал «Отмена», работа за 20 минут была бы потеряна.
Microsoft Outlook размещает кнопку «Отметить для продолжения» рядом со значками «Архивировать» и «Удалить». Эти значки служат противоположным намерениям пользователя, тем не менее, они маленькие, размещены близко друг к другу и легко ошибиться пользователям спешке.
Выводы
Приложения в значительной степени зависят от предметной области, поэтому удобное в использовании, эффективное и приятное приложение для одной отрасли может стать катастрофой в другой. Для создания пригодного к использованию приложения нужно выяснить рабочие процессы пользователей, необходимые им функции, а также их ментальные модели и ожидания.
Тем не менее, топ 10 ошибок в разработке приложений, изложенные здесь, представляют собой общие темы, которые мы наблюдаем в исследованиях в различных отраслях, включая творческую, финансовую, корпоративную, здравоохранение, инженерию и другие.