Десять ошибок в разработке приложений

Перевод статьи Nielsen Norman Group.

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

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

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

Таким образом, наша первая рекомендация — провести исследование пользователей с вашей целевой аудиторией:

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

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

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

Вот наш текущий список топ-10 ошибок в разработке приложений, которые одновременно являются как вопиющим, так и обычным явлением.

Одним из основных принципов повышения юзабилити приложения является предоставление чёткой обратной связи:

1. Показывать пользователям текущее состояние системы.
2. Расскажите пользователям, как были интерпретированы их команды и действия.
3. Сообщайте пользователям, что происходит.

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

Хорошая обратная связь говорит пользователям многое. К примеру, правильно ли кнопка, которую они кликнули, интерпретируется системой как «клик» и реагирует ли система? Что сейчас выбрано или активно?

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

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

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

В режиме редактирования это приложение от Telerik.com добавляет серый фон в строку таблицы, которая в данный момент редактируется, изменяет ячейки так, чтобы они выглядели как поля формы, и изменяет кнопки «Изменить» и «Удалить» на «Обновить» и «Отмена» с другим макетом.

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

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

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

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

Помните правило двойного D: различия сложны (differences are difficult). Когда у пользователей есть ожидания относительно того, как что-то будет работать или где они могут получить доступ, отклонения от этих ожиданий вызывают путаницу, разочарование и повышенную когнитивную нагрузку, когда люди пытаются решить проблему. Человеческий разум жаждет последовательности.

Существует несколько типов несоответствий, которые особенно распространены в сложных приложениях и приводят в замешательство даже опытных пользователей:

1. Разные слова или команды для одного и того же действия.
2. Размещение элементов управления для одной и той же функции в разных местах.
3. Элементы управления, которые похожи друг на друга (с точки зрения пользователя), но доступны в разных местах (например, один доступен на панели инструментов, другой — в меню, а третий — глубоко в диалоге настроек).
4. Подобные структуры рабочего процесса, которые требуют взаимодействия с самыми разными разделами интерфейса.
5. Несовместимые правила для допустимых входных данных: иногда запись разрешена, а в других случаях она помечается как недействительная, без какой-либо обратной связи о том, почему это происходит.
6. Функция иногда доступна, а иногда нет — по таинственным причинам, которые не указаны.
7. Элементы пользовательского интерфейса или элементы управления, которые перемещаются, нарушая пространственную согласованность.

Архитектор в нашем исследовании, имевшая многолетний опыт использования AutoCAD, изо всех сил пыталась понять, когда она может или не может «стыковать» различные плавающие панели, чтобы закрепить их на одной стороне экрана.

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

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

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

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

Наиболее распространенное нарушение правил — когда в сообщении об ошибке просто говорится, что что-то не так, без объяснения, почему и какпользователь может решить проблему. Такие сообщения оставляют пользователей в замешательстве.

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

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

Набор расплывчатых сообщений «Что-то пошло не так» от Quicken (вверху слева), Dropbox (вверху справа), IBM Verse (внизу): ни одно из них не описывает суть проблемы, подробности о том, как её решить, и была ли работа пользователя потеряна в процессе.

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

Настройки по умолчанию помогают пользователям во многих отношениях. Самое главное, значения по умолчанию могут:

1. Ускорить взаимодействие, освободив пользователей от необходимости указывать значение, если значение по умолчанию приемлемо.
2. Научить, предоставляя пример вроде ответа, который подходит для вопроса.
3. Направить начинающих пользователей к безопасному или общему результату, позволив им принять значение по умолчанию, если они не знают, что еще делать.

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

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

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

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

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

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

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

Иконки редко ничем не подкреплены, но большинство пользователей сразу же могут их понять. Даже значки, которые могут показаться универсальными (например, гамбургер-меню), не настолько знакомы пользователям, как ожидало бы большинство практиков UX.

Становится намного хуже, если в вашем приложении есть уникальные значки; вероятность того, что пользователи поймут, что означают эти уникальные значки, очень мала. Помните закон Якоба: «Пользователи проводят большую часть времени на других веб-сайтах». Это означает, что большинство значков без текстовой метки, пользователи не смогут понять.

Четыре преимущества сопряжений значков с текстовой меткой:

1. Увеличивает размер значка (что, согласно закону Фиттса, сокращает время, необходимое пользователям для доступа к элементу управления).
2. Это сокращает время распознавания команды: две метки (значок и текст) лучше, чем одна.
3. Относительно предыдущего: это также может облегчить изучение интерфейса (путём создания нескольких ассоциаций с одной и той же командой).
4. Это может помочь пользователям визуально различать несколько команд, расположенных рядом друг с другом.

В наших недавних исследованиях представлены значки без меток из различных приложений для десктопных устройств: все значки — нестандартные, которые не указывают чётко их назначение. Можете ли вы угадать, что они обозначают? Наши участники исследования не смогли.

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

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

«Доступность» означает, что вы можете сделать с объектом. Например, флажок позволяет включать и выключать, а ползунок — перемещаться вверх или вниз.

Сигнификаторы — это визуальные элементы, которые помогают вам понять преимущества, просто посмотрев на объект, прежде чем вы начнёте его использовать (или почувствуете, если это физическое устройство, а не элемент пользовательского интерфейса на экране). Эти концепции обсуждаются в книге Дона Нормана «Дизайн повседневных вещей».

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

(Исключение: маленькие дети иногда любят просматривать экраны, нажимая на всё вокруг.)

В современных приложениях одним из худших нарушителей являются ультраплоские конструкции. Многие плоские конструкции имеют слабые значения для целей: люди не могут лёгко отличить текст от кнопок, потому что у кнопок нет традиционных 3D-подсказок.

Распространёнными признаками слабых сигнификаторов являются:

1. Пользователи говорят: «Что я здесь делаю?»
2. Пользователи не приближаются к функции, которая поможет им.
3. Обилие экранного текста пытается преодолеть эти две проблемы. (Ещё хуже многоступенчатые инструкции, которые исчезают после выполнения первого из нескольких действий.)

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

(Крошечные размеры целей представляют собой особую проблему для пожилых пользователей и пользователей с инвалидностью.)

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

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

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

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

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

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

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

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

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

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

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

Эта таблица содержит бессмысленную идентификационную информацию в качестве первого столбца; поля Net Code и Location Code также включают в себя закодированную информацию, предназначенную для представления сложной информации в компактном пространстве.

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

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

Одним из следствий этого ограничения часто является переполнение меню: наиболее часто используемые действия отображаются на панели инструментов, а конечный элемент, помеченный как «Дополнительные действия» или «Инструменты», содержит всё остальное, что не подходит.

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

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

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

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

Хотя с логической точки зрения такое размещение часто имеет смысл (например, «Сохранить» и «Удалить» связаны с тем, что они решают судьбу элемента), но оно также позволяет легко нажимать неправильную кнопку или значок — особенно когда пользователи спешат, выполняя повторяющиеся действия. Этот тип непреднамеренной замены одного действия другим называется ошибкой.

Veeam, корпоративное ПО для резервного копирования, содержит многошаговый мастер для настройки нового задания резервного копирования.

В нашем исследовании пользователь потратил почти 20 минут, чтобы пройти через этот мастер, и почти нажал кнопку «Отмена», а не «Готово» на последней странице сводной информации из-за близости двух кнопок. Если бы этот пользователь нажал «Отмена», работа за 20 минут была бы потеряна.

Microsoft Outlook размещает кнопку «Отметить для продолжения» рядом со значками «Архивировать» и «Удалить». Эти значки служат противоположным намерениям пользователя, тем не менее они маленькие, размещены близко друг к другу и в спешке легко ошибиться.

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

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

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

Перевод сделан при поддержке канала UI/UX Designer.