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

Конспект материала Якоба Нильсена и Пейджа Лабхеймера из Nielsen Norman Group.

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

В 2019 они провели исследование вновь и составили новый список. В нём сохранились пять старых ошибок (их номера в этом конспекте — 1, 2, 3, 4, 6) и добавились пять новых (5, 7, 8, 9, 10).

Одно из главных качеств хорошего приложения — отзывчивость. Это значит, что оно должно:

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

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

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

Хороший пример — дизайн интерфейса приложения от Telerik.com.

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

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

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

Если система не может выполнить действие вовремя, то лучше сообщить об этом пользователю прямо и позволить ему следить за ходом процесса. Вот что советуют сделать Нильсен и Пейдж:

Помните правило двух О: отличия осложняют. Когда у пользователя есть своё представление о том, как что-то в приложении должно работать и откуда получить к этому доступ, любое несоответствие ожиданиям вызовет путаницу. Люди начнут ломать голову над тем, как же на самом деле всё устроено.

Несогласованность проявляется по-разному и может сбить с толку даже опытных пользователей. Вот как она может проявляться:

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

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

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

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

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

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

Шаблонные значения помогают во многом. Самое важное, что они могут делать, это:

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

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

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

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

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

По мнению авторов, у подписей к иконкам четыре преимущества:

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

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

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

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

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

В приложении наверняка есть незаметные маркеры, если:

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

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

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

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

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

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

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

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

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

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

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

Многие разработчики, стараясь выполнить эти условия, часто распределяют функции в меню неравномерно: самые нужные из них — в панели инструментов, а всё остальное — в последнем разделе под названием «Ещё», «Инструменты» или в худшем случае просто «...».

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

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

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

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

Корпоративное приложение для резервного копирования Veeam предлагает пользователю пройти этот процесс пошагово. Участник исследования Нильсена и Пейджа потратил почти 20 минут, чтобы пройти все этапы, и чуть не нажал на кнопку «Отмена» вместо «Завершить» в последнем окне, потому что эти две кнопки были близко друг к другу. Если бы он нажал на «Отмену», то потратил бы эти 20 минут впустую.

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

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

Первое, что советуют сделать авторы — провести исследование среди целевой аудитории:

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

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