Как заставить пользователей обратить внимание на проблемы?

Question

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

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

У нас есть система управления предупреждением/ошибкой в ​​виду, что, я думаю, это поможет, но я хочу посмотреть, что сделали другие.

Answer 1

Если вы хотите, чтобы пользователи обратили внимание на предупреждения, используйте их в меру!

Большая проблема с UAC в Vista, является то, что люди получают так много уведомлений, чтобы они прекратили чтение кто точно запрашивающий доступ к , что, они просто дают разрешение, не задумываясь.

Другим примером является подтверждение удаления в проводнике при отправке файлов в корзину. Я так привык, что просто ударил «Ok» сразу после нажатия «delete», что я пропустил тот факт, что в диалоговом окне мне сообщается, что файл не будет перемещен в корзину, но по какой-то причине удаляется немедленно.

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

Вывод: Не спам пользователя сообщениями или важные предупреждения будут потеряны в шуме.

Answer 2

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

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

Answer 3

Мне очень нравится метод firefox при установке плагинов: кнопка ok отключена и отображает обратный отсчет в течение 5 секунд. После этого использование может игнорировать его.

Answer 4

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

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

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

• Если местоположение абсолютно критическое, мы сделаем это обязательным для формы.

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

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

Answer 5

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

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

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

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

Answer 6

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

Моя другая, гораздо более зловещая идея заключалась в том, чтобы сделать «Нет» или «Отменить» параметры по умолчанию. В конце концов они получили бы нажатия клавиш Tab-Enter вниз, а затем вы просто переключили их обратно.

Answer 7

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

Лучший способ борьбы с этим заключается в следующем:

• Не выскочит окно, если это абсолютно необходимо
• Если вы делаете, чтобы сообщение об ошибке или предупреждение, как коротким и лаконичным, как вы, возможно, can

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

Answer 8

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

В случае обращения с пользовательскими вводами, которые могут быть неправильными, считаете ли вы использование чего-то вроде красных squigglies, используемых проверкой орфографии или какой-либо подсветкой проблемных областей, когда пользователь выполняет свою работу? Большинство пользователей прошли обучение, чтобы игнорировать диалоги, используя багги-программное обеспечение, но такое сообщение может дать понять, что ошибка исправлена ​​пользователем.

Answer 9

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

• делает обзор пользователя данных для очевидных опечаток или ошибок

• сделать кому-либо просмотреть данные на более позднем этапе, когда более подробная информация

• проинформировать пользователя и кого-либо еще, глядя на данные на более позднем этапе о каких-либо предположений, сделанных

• убедитесь, что пользователь понимает последствия своих действий

Можно ли достичь какой-либо из этих целей более эффективно по-другому?

Некоторые идеи (ни один из них автоматически квалифицируется как серебряная пуля):

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

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

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

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

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

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

• совершать действия, которые можно отменить, так что вы на самом деле не нужны предупреждения

Answer 10

Разбейте систему!

Он честно был мой опыт, что, если вы не хотите, чтобы конечный пользователь, чтобы сделать что-то без явного понимания его, остановить их от делать это ...

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

Время Google ответ ... или RTFM

Я знаю, что это не всегда возможно использовать этот подход, но если вы можете ... они будет слушать!

Answer 11

Мой совет сводится к трем вещам.

1. Оцените то, что, по вашему мнению, важно для пользователя.
2. Не ленитесь и попросите пользователя решить, что ваша программа может решить самостоятельно.
3. Не прерывайте то, что пользователь делает с глупыми (и да, они глупыми) сообщениями.

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

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

Answer 12

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

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

Answer 13

Это то, что мы запланировали. По существу, создайте что-то Bugzilla-ish для хранения этих ошибок/предупреждений/независимо. Но это также идет рука об руку с некоторыми другими ответами.

Вместо использования простого MessageBox отображать предупреждения/ошибки в окне ошибки в Visual Studio. Пока есть проблемы, они будут отображаться в этом окне.

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

Разрешить пользователям выполнять несколько действий, как:

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

Записывать все эти действия в базе данных, поэтому мы имеем подотчетности

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

Answer 14

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

Answer 15

Используйте цвета и значки.

Зеленый - все в порядке (или подтверждение что-то произошло, как и ожидалось)

Желтый - предупреждение. Вы можете или не хотите обращаться к проблеме

Красный - Ошибка. Что-то, что требует взаимодействия с пользователем.

Я бы также предложил (как и другие на эту тему) использовать экономно.