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

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

• Не размещайте сообщения об ошибках в строке состояния - они никогда их не прочитают, несмотря на то, что они заигрывают цветами и т. Д.… Они всегда будут их пропускать! Как бы вы ни старались ... На одном из этапов тестирования пользовательского интерфейса Win 95 перед его запуском MS провела эксперимент по чтению пользовательского интерфейса (ed - он должен быть отметил, что сообщение явно указано в контексте «Загляните под стул»), с купюрой в 100 долларов, приклеенной к нижней стороне стула, на котором сидели испытуемые ... никто не заметил сообщение в статус бар!
• Делайте сообщения короткими, не используйте пугающие слова, такие как «Предупреждение: система обнаружила проблему», конечный пользователь нажмет кнопку паники и будет чрезмерно реагировать ...
• Как бы вы ни старались, не используйте цвета для обозначения сообщения ... психологически это похоже на размахивание красным флагом перед быком!
• Используйте нейтрально звучащие слова, чтобы передать минимальную реакцию и дальнейшие действия!
• Возможно, будет лучше показать диалоговое окно с нейтральным сообщением об ошибке и включить флажок, указывающий: «Хотите ли вы видеть больше этих сообщений об ошибках в будущем?» - последнее, что хочет конечный пользователь, - это работать. в середине программного обеспечения, которое будет засыпано всплывающими сообщениями, они будут разочарованы и будут отключены приложением! Если флажок установлен, вместо этого зарегистрируйте его в файл ...
• Держите конечных пользователей в курсе, какие сообщения об ошибках будут ... что подразумевает ... обучение и документацию ... теперь это сложно передать ... вы не хотите, чтобы они думали, что будут быть «проблемами» или «глюками», и что делать в случае этого ... они не должны знать, что будут возможные ошибки, это действительно сложно.
• Всегда, всегда, не бойтесь спрашивать об обратной связи, когда происходит обычное дело - например, «Когда появилась ошибка с номером 1304, как вы отреагировали? Какова была ваша интерпретация? »- бонус в том, что конечный пользователь может дать вам более связное объяснение вместо« Ошибка 1304, объект базы данных потерян! », Вместо этого они могут сказать:« Я нажал на это, поэтому Итак, затем кто-то случайно выдернул сетевой кабель машины », это подскажет вам, что с этим нужно иметь дело, и может изменить ошибку, чтобы сказать« Ой, сетевое соединение отключено »... вы получите дрейф.
• И последнее, но не менее важное: если вы хотите настроить таргетинг на международную аудиторию, примите во внимание интернационализацию сообщений об ошибках - поэтому следует сохранять нейтралитет, потому что тогда будет легче переводить, избегать синонимов, сленговых слов и т. Д., Которые могут сделать перевод бессмысленный - например, Fiat Ford, автомобильная компания продавала свою марку Fiat Ford Pinto, но обнаружила, что в Южной Америке не было продаж, как выяснилось, Пинто там на сленге означало «маленький пенис» и, следовательно, никаких продаж ...
• (ed) Задокументируйте список ожидаемых сообщений об ошибках в отдельном разделе документации, озаглавленном «Сообщения об ошибках» или «Корректирующие действия» или аналогичном, с указанием номеров ошибок в правильном порядке с указанием. или два о том, как действовать ...
• (ed) Спасибо Виктору Хурдугачи за его вклад, делайте сообщения вежливыми, не заставляйте конечных пользователей чувствовать себя глупыми. Это противоречит ответу Джека Маркетти, если база пользователей является международной ...

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

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

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

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

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

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

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

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

Краткий ответ: нельзя.

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

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

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

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

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

Эй, тупица, научись указывать дату!

РЕДАКТИРОВАТЬ: Конечно, более полезным будет сообщение: «Пожалуйста, введите дату как мм / дд / гггг» или, возможно, в коде, чтобы попытаться выяснить, что они ввели, и если они ввели «бла-бла», чтобы показать ошибку. Однако это было очень маленькое приложение для человека, которого я знал лично. И снова люди, прочтите первую строку этого сообщения: В зависимости от вашей пользовательской базы ...

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ
Сделайте сообщение содержательным и полезным. Например, не пишите что-то вроде «Клавиатура не найдена, нажмите F1, чтобы продолжить».

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

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

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

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

Например, я передаю такое сообщение:

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

что-то вроде:

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

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

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

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

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.

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

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

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

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

Хочу добавить одну вещь.

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

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

С другой стороны, если вы МОЖЕТЕ на самом деле показать пользователю полезный обходной путь, то один из способов заставить его прочитать его - это сделать кнопку OK активированной через 10 секунд или около того. Вроде того, как Firefox делает это всякий раз, когда вы пытаетесь установить новый плагин.

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

Для записи: есть пользователи, которые ДЕЙСТВИТЕЛЬНО читают сообщения об ошибках, но так боятся, что ничего не сделают с ними. Однажды мне позвонили в службу поддержки, и клиент прочитал мне сообщение об ошибке и спросил, что ему делать. «Ну, а какие у вас есть варианты?», - спросил я. «В окне есть только кнопка« ОК »», - ответил он. ... ммм, сложный :)

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

Красный означает «предупреждение» и т. Д., Поэтому его читают чаще.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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