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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я хотел бы добавить одну вещь.

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

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

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

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

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 здесь .

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

С другой стороны , если вы CAN действительно показать пользователю полезный обходной путь, то один из способов заставить его прочитать его - активировать кнопку ОК через 10 секунд или около того. Что-то вроде того, как Firefox делает это всякий раз, когда вы пытаетесь установить новый плагин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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