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

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

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

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

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

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

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

"Извините, мы облажались, мы хотели бы отправить некоторую информацию об этом крахе, позволите ли вы нам это сделать? YES / NO"

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

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

EDIT:

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

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

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

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

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

EDIT:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одно, что я хотел бы добавить.

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

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

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

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

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

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

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

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

По возможности ориентируйтесь на свою аудиторию и избегайте скучных, как все неземное, общих ошибок, таких как: "please enter email" или "please enter valid email".

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

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

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

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

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

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

1. В чем заключается проблема и почему она возникла.
2. Как решить проблему.

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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