Как заставить пользователей читать сообщения об ошибках?

Ответ 1

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

• Не помещайте сообщения об ошибках в строку состояния - они никогда не прочтут их, несмотря на то, что они были взорваны цветами и т.д.... они всегда будут пропустить их! Как бы вы ни старались... На одном этапе тестирования Win 95 UI перед его запуском MS провела эксперимент по чтению пользовательского интерфейса (ed). Следует отметить, что сообщение явно указано в контексте "Взгляд под стул" ), с битой стоимостью 100 долларов, прикрепленной к нижней стороне кресла, на которой сидели субъекты... никто не заметил сообщение в строке состояния!
• Сделайте сообщения короткими, не используйте запугивающие слова, такие как "Оповещение: система столкнулась с проблемой", конечный пользователь собирается нажать кнопку паники и будет слишком реагировать...
• Как бы вы ни старались, не используйте цвета, чтобы идентифицировать сообщение... психологически, это похоже на размахивание красным флагом быку!
• Используйте нейтральные звуковые слова, чтобы передать минимальную реакцию и как действовать!
• Возможно, лучше показать диалоговое окно с сообщением о нейтральной ошибке и включить флажок, указывающий "хотите ли вы видеть больше этих сообщений об ошибках в будущем?", последнее, чего хочет конечный пользователь, - это чтобы работать в середине программного обеспечения, которое будет обмануто всплывающими сообщениями, они будут расстроены и будут отключены приложением! Если галочка была отмечена галочкой, запишите ее в файл вместо...
• Предоставьте конечным пользователям информацию о том, какие сообщения об ошибках будут... что подразумевает... обучение и документацию... теперь это сложно, потому что вы не хотите, чтобы они думали что будут "проблемы" или "глюки", и что делать в случае этого... они не должны знать, что возможны ошибки, каверзно.
• Всегда, всегда, не бойтесь просить обратной связи, когда происходит беспрецедентное событие, например "Когда появился номер ошибки 1304, как вы реагировали? Какова была ваша интерпретация?" - бонус с этим, конечный пользователь может дать вам более последовательное объяснение вместо "Ошибка 1304, объект базы данных потерян!", Вместо этого они могут сказать "я нажал на это" и так, тогда кто-то случайно вытащил сетевой кабель машины ", это подскажет вам о необходимости иметь дело с ним и может изменить ошибку, чтобы сказать" Ooops, Network connection disconnected "... вы получаете дрейф.
• И последнее, но не менее важное: если вы хотите настроить таргетинг на международную аудиторию, учтите интернационализацию сообщений об ошибках - отсюда и поэтому, чтобы сохранить ее нейтральной, потому что тогда ее будет легче переводить, избегать синонимов, сленговых слов и т.д. что сделало бы перевод бессмысленным - например, Fiat Ford, компания по продаже автомобилей продавала свой бренд Fiat Ford Pinto, но не заметила, что в Южной Америке продажи не происходили, это оказалось, Пинто был сленгом для "маленького пениса" и, следовательно, без продаж...
• (ed) Документируйте список сообщений об ошибках, которые ожидаются в отдельном разделе документации "Сообщения об ошибках" или "Корректирующие действия" или аналогичные, перечисляя номера ошибок в правильном порядке с выражением или двумя о том, как действовать...
• (ed) Благодаря Victor Hurdugaci для его ввода, держите сообщения вежливыми, не заставляйте конечных пользователей чувствовать себя глупо. Это противоречит ответу Jack Marchetti, если база пользователей является международной...

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

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

Изменить # 2: Мой плохой! Ой, благодаря DanM, который упомянул об этом в машине, я перепутал имя, это был Ford Pinto... мой плохой...

Изменить # 3: Выделили ed, чтобы указать дополнения или дополнения и зачислить их другим для своих входов...

Edit # 4:В ответ на комментарий Кена - вот мой прием... Нет, это не так, используйте нейтральные стандартные цвета Windows... не ходите за яркими цветами! Придерживайтесь обычного серого заднего цвета с черным текстом, который является стандартным стандартным GUI-ориентиром в спецификациях Microsoft. Смотрите Руководства по UX (изд).

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

Ответ 2

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

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

Ответ 3

Короткий ответ: вы не можете.

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

Ответ 4

В зависимости от вашей пользовательской базы письма с забавными/грубыми/личными сообщениями об ошибках могут отлично работать.

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

Когда они ввели неправильные даты, я бы написал:

Эй, глупая задница, научись вводить дату!

EDIT: Конечно, более полезное сообщение - сказать: "Пожалуйста, введите дату как mm/dd/yyyy" или, возможно, в коде, чтобы попытаться выяснить, что они ввели, и если они ввели "blahblah", чтобы показать ошибку. Однако это было очень маленькое приложение для человека, которого я знал лично. Следовательно, люди снова читают первую строчку этого сообщения: в зависимости от вашей пользовательской базы...

Недавно я работал над проектом Art Institute, поэтому сообщения об ошибках были ориентированы на аудиторию, например:

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

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

Ответ 5

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

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

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

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

UPDATE
Сделать сообщение значимым и полезным. Например, не пишите что-то вроде: "Нет клавиатуры найдена, нажмите F1 для продолжения".

Ответ 6

Мы помещаем в поле ошибки простую незабываемую графику: не значок, довольно большой растровый рисунок и ничего подобного стандартным значкам сообщений Windows. Никто никогда не может запомнить формулировку почтового ящика (большинство из них даже не прочитает, если в коробке есть кнопка "ОК", которую они могут нажать), но большинство людей помнят изображение, которое они видели. Поэтому наши люди поддержки могут спросить клиента: "Вы видели парня, пьющего кофе?" или "вы видели пустой стол?". По крайней мере, мы знаем, что пошло не так.

Ответ 7

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

Ответ 8

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

Этот момент может быть причиной вашего опыта, потому что в какой-то момент они перестанут их читать, потому что "они все равно не понимают", поэтому ваша задача проста:

Сделать сообщение об ошибке максимально понятным и сохранить техническую часть под капотом.

Например, я передаю сообщение следующим образом:

ORA-00237: операция моментального снимка запрещена: новый файл управления Причина. Была сделана попытка вызвать cfileMakeAndUseSnapshot с установленным в данный момент управляющим файлом, который был создан с помощью CREATE CONTROLFILE. Действие: Установите текущий файл управления и повторите операцию.

к чему-то вроде:

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

Ответ 9

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

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

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

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

EDIT:

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

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

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

Ответ 10

Сделайте их забавой. (Это казалось актуальным, учитывая сайт, на котором мы находимся:))

Ответ 11

Я часто показываю ошибку красным цветом (когда это позволяет дизайн).

Красный означает "предупреждение" и т.д., поэтому он чаще читается.

Ответ 12

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

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

Если ваше приложение является веб-приложением, разработка пользовательских страниц ошибок является хорошей идеей. Они стесняют пользователей меньше, например, возьмите SO. Вы можете получить некоторые идеи о том, как создать хорошую страницу ошибок здесь: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Ответ 13

Из моего опыта: вы не получаете пользователей (особенно нетехнических), чтобы читать сообщения об ошибках. Независимо от того, насколько ясным и понятным, полужирным, красным и мигающим сообщение является то, что вы показываете, большинство пользователей просто нажимают на что-нибудь, к чему они не привыкли, даже если это "вы действительно хотите удалить все?". Я видел, как пользователи нажимают "закрыть окно" -icon вместо "ОК" или "отменить", даже если они даже не знают, какой вариант они выбрали, сделав это...

Если вам действительно нужно заставить пользователей читать то, что вы показываете, я бы предложил JavaScript-обратный отсчет, пока кнопка не будет нажата. Таким образом, пользователь, мы надеемся, будет использовать время ожидания, чтобы действительно прочитать, что он должен был делать. Будьте осторожны: большинство пользователей будут еще более раздражены тем, что:)

Кроме того, мне нравится ваша идея "читать больше" -link, хотя я сомневаюсь, что пользователи получат больше интереса, которые просто хотят избавиться от сообщения всеми способами...

Только для записи: есть пользователи, которые DO читают сообщения об ошибках, но так опасаются, что они ничего не сделают с этим. У меня когда-то был звонок поддержки, когда клиент читал мне сообщение об ошибке, спрашивая меня, что он должен делать. "Ну, каковы ваши варианты?", - спросил я. "В окне есть кнопка" ОК ", - ответил он.... mmh, hard one:)

Ответ 14

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

С другой стороны, если вы действительно можете показать пользователю полезное обходное решение, то один из способов заставить их прочитать его - сделать кнопку OK включенной через 10 секунд или около того. Как работает Firefox, когда вы пытаетесь установить новый плагин.

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

" Мне жаль, что мы напортачили, мы хотели бы отправить некоторую информацию об этом сбое, разрешите ли вы нам это сделать? ДА/НЕТ"

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

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

EDIT:

Кто-то недавно также предложил использовать комиксы вместе с любым сообщением, которое вы хотите показать. Например, что-то из Dilbert, которое может быть близко к типу ошибки, которую вы можете иметь.

Ответ 15

См. также ответы пользователя Slashdot здесь.

Ответ 16

Одна вещь, которую я хотел бы добавить.

Используйте глаголы для кнопок действий, чтобы закрыть ваши сообщения об ошибках, а не восклицания, например, не используйте "Ok!". "Закрыть" и т.д.

Ответ 17

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

Вы должны написать наиболее важные вещи, чтобы сначала прочитать и предоставить более подробную информацию.

Другими словами, это нехорошо:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Вместо этого измените порядок:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Таким образом, пользователь может читать столько, сколько он хочет, или беспокоит, и все еще имеет представление о том, что требуется.

Ответ 18

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

Ответ 19

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

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

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

Хорошее сообщение об ошибке должно содержать:

• В чем проблема и почему это произошло.
• Как решить проблему.

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

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

Ответ 20

Меньше ошибок

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

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

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

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

Ответ 21

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

Ответ 22

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

Если на странице есть ошибки (я больше в веб-разработке, поэтому я имею в виду ее как "страницу", но ее можно также назвать "формой" ), показать "сводку ошибок", объясняя, что были ошибки и маркированный список того, что именно произошло. Однако, если в сообщении больше 5-6 слов, это не будет прочитано/понято.

Ответ 23

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

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

Ответ 24

Я прочитал кандидата на самое страшное решение на slashdot:

Мы обнаружили, что единственный способ заставляют пользователей брать на себя ответственность за ошибки должны дать им штраф за заставляя ошибку уйти. Для как можно скорее, ошибка обычно не будут закрыты для них, если мы введите пароль администратора, чтобы он прошел и если они перезагружаются, чтобы избавиться от он (Диспетчер задач отключен на всех клиентский ПК) машина не откроется приложение, которое разбилось на 15 минут. Конечно, все это зависит о типе пользователей, с которыми вы имеете дело с, как более технически успешными пользователями не принял бы такую ​​систему, но после попытки буквально ЛЕТ чтобы пользователи несли ответственность за сбоев и отдел знает о них в порядке решить проблему до того, как она станет слишком трудно управлять, это единственные шаги, которые сработали. Теперь, весь наш конец пользователи знают, что если они игнорируют ошибок, они будут страдать за это сами.

Ответ 25

"ВНИМАНИЕ! ВНИМАНИЕ! Если вы не прочитали сообщение об ошибке, ВЫ УМЕРЕТЕ!"

Ответ 26

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

Пользователь должен сделать выбор до появления кнопки OK

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