Hi-Tech

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

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

В закладки

Аудио

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

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

1. Неотзывчивость

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

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

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

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

Неотзывчивость в режиме редактирования

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

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

Приложение от Telerik.com.

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

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

Долгая загрузка без шкалы прогресса

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

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

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

2. Несогласованность

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

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

  • Одно и то же действие обозначается по-разному.
  • Элементы управления одним и тем же объектом размещены в разных местах.
  • Элементы управления, которые вроде бы похожи друг на друга (с точки зрения пользователя), находятся в разных местах: первый в панели инструментов, второй в меню, а третий ― в настройках.
  • Для выполнения схожих задач требуется заходить в совсем разные разделы интерфейса.
  • Постоянно меняющиеся правила безопасного введения данных: иногда их можно ввести, а иногда нет, и система никак не объясняет, почему.
  • Иногда функция доступна, а иногда по таинственным причинам ― нет.
  • Элементы интерфейса или управления меняют своё местоположение.

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

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

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

3. Плохие сообщения об ошибках

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

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

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

Сообщения об ошибках в приложениях Quicken, Dropbox и IBM Verse лишь поверхностно и условно описывают происходящее: ни в одном из них не указано, почему произошла ошибка, как её устранить и пострадали ли данные пользователя

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

4. Нет шаблонных значений

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

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

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

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

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

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

5. Неподписанные иконки

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

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

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

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

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

6. Труднодоступные «цели»

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

Незаметные маркеры

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

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

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

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

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

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

Маленькие кликабельные области

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

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

7. Переизбыток модальных окон

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

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

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

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

8. Бесполезная информация

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

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

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

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

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

9. «Кладовое» меню

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

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

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

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

Назначение «кладового» меню под названием «...» в приложении Airtable очень неочевидно. Пользователю будет трудно понять, какие функции в нём есть «Кладовое» меню «Ещё» в приложении Salescore

10. Кнопки подтверждения и отмены расположены близко друг к другу

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

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

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

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

Советы дизайнерам

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

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

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

Итог

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

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

  • Как они привыкли работать.
  • Какие функции им нужны для работы.
  • Как они представляют себе ваше приложение.
  • Что ожидают от приложения.
Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»