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

Для Windows 11.05.2019
Для Windows

Сообщения об ошибках это скрытая угроза успеху сайта или ПО. Если человек не понимает что от него хотят, то он быстро покидает сайт. Консультант по вопросам взаимодействия John Hyde рассказывает какими приемами воспользовался сайт финансовой конторы, чтобы увеличить конверсию на 17%.

Счастливый путь

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

Когда я впервые протестировал такой путь, то я был удивлен. Мой программист зафиксировал ошибки при заполнении простой формы на сайте:

  • 31% процент сразу делали ошибки;
  • 7% из них смогли успешно продолжить;
  • 24% из них ушли с сайта после нескольких попыток.

Как лучше всего поступать с ошибками людей?

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

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


 Красный текст под нужным полем тоже хороший пример.


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

Встроенная проверка и сообщения
об ошибке


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

Хорошо о встроенной проверке написал Luke Wroblewski в журнале A List Apart .

У этого метода есть свои недостатки:

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

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

Как формулировать
сообщения об ошибке

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

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

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

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

Ваше сообщение об ошибке должно:

  • быть тактичным и избегать обвинений пользователя («упс» хорошее слово);
  • четко объяснять что не так;
  • помогать исправить ситуацию.


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


 Вот пример того как не надо делать с полем для ввода электронной почты.
Нам всем понятно что не так, но сайт предлагает нам читать целый параграф возможных проблем. Как на счет «В вашем адресе не хватает знака “@”»?

Для других проблем понадобятся иные сообщения:

bob.green@superduper => «Адрес введен не до конца, проверьте окончание»
bob./[email protected] => «В адресе встречается не обычный символ (/)»

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

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

Пустые поля

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

Мой совет на такой случай - объясните посетителю зачем вам его данные:

  • «Нам нужен вам телефон, потому что наш водитель может опоздать»
  • «Введите вашу почту, чтобы мы могли напоминать вам пароль»
  • «Введите почтовый индекс, чтобы посылка дошла быстрее»

Улучшение на 17%

Одна финансовая компания воспользовалась этими рекомендациями. Вот какие данные были изначально:

  • 100 попыток регистрации;
  • 31 ошибка у регистрирующихся впервые;
  • 7 все-таки зарегистрировались;
  • 24 не закончили регистрацию.

Было: 76% успешных регистраций из всех (100% — 24%)
Стало: 89% успешных регистраций.

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

JavaScript почти не рассматриваются сообщения об ошибках.

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

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

Пожалуйста, запомните! В более поздних версиях MSIE и Navigator это окошко может не появляться.

При использовании MSIE сообщение об ошибке появится сначала как треугольный значок в нижнем левом углу. В этом треугольнике будет находиться восклицательный знак. Будет также присутствовать текст, сообщающий, что на странице встретились ошибки. Щелкните на этом треугольнике, чтобы получить сообщение об ошибке , которое рассматривается в данном учебнике. Или, если вы хотите, чтобы окно ошибки выводилось сразу, без щелчка на значке, перейдите в меню Tools (Сервис) и выберите Internet Options (Свойства обозревателя). В Internet Options щелкните на вкладке Advanced (Дополнительно) и поставьте флажок у строки "Display a notification about every script error " (Показывать уведомление о каждой ошибке сценария).

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

При использовании более поздней версии Netscape Navigator в строке состояния выводятся указания пользователю. При возникновении ошибки будет предложено ввести javascript : в строке адреса. Затем будет выведена ошибка и соответствующее текстовое описание.

Сообщение об ошибке

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

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

Исправление ошибок

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

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

Строка ошибки

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


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

Правила создания эффективных сообщений об ошибках не меняются вот уже 20 лет. Хорошее сообщение об ошибке должно:

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

Быть написано на человеческом языке, а не с использованием таинственных кодов и сокращений типа " произошла ошибка типа 2".

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

Точно описывать источник проблемы, а не просто выдавать общие фразы типа " синтаксическая ошибка".

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

Самая распространенная ошибка в Web - 404 - нарушает большинство из этих правил. Я рекомендую вам написать свое собственное сообщение об ошибке 404 вместо того, чтобы полагаться на скупую серверную фразу "page not found".

Новые правила

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

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

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

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

Вот еще несколько правил, которые позволят смягчить неприятную ситуацию, в которую попадает пользователь при ошибке:

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

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

Обучение пользователей

И наконец, вы наверное уже знаетеПервый Закон Нильсена о компьютерной документации: люди ее не читают. Этот закон действует еще сильнее для веб-сайтов, где пользователи действительно избегают читать то, что не существенно для их задачи. Щелкнуть по ссылке "Помощь"? Да ни за что.

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

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

Правила создания эффективных сообщений об ошибках не меняются вот уже 20 лет. Хорошее сообщение об ошибке должно:

  • Явно указывать, что что-то не так. Самое плохое сообщение об ошибке это то, которое не было создано. Если пользователи делают ошибку и не получают никакого отклика от системы, это самое худшее для них. Например, приложение работы с электронной почтой имеет несколько ситуаций, где указание о произошедшей ошибке было бы явно полезным. Скажем, вы отправили почтовое сообщение, которое было благополучно проглочено системой, но так и не достигло адресата. Еще пример? Вы сообщаете в письме, что прилагаете к нему файл, но просто забыли сделать это. Вот тут-то и нашлась бы работа для этой глупой скрепки из MS Office: "Похоже, вы хотели прикрепить файл к вашему сообщению, но не сделали этого. Хотите сделать это? "
  • Быть написано на человеческом языке , а не с использованием таинственных кодов и сокращений типа "произошла ошибка типа 2 ".
  • Быть вежливым и не обвинять пользователей в том, что они такие глупые или сделали что-то не так, как например в сообщении "запрещенная команда "
  • Точно описывать источник проблемы, а не просто выдавать общие фразы типа "синтаксическая ошибка ".
  • Давать конструктивный совет о том, как исправить проблему. Например, вместо того, чтобы сообщать о том, что товара "нет в наличии ", ваше сообщение об ошибке должно либо сообщать, когда товар будет в наличии, или предлагать пользователям настроить отсылку им сообщения-уведомления , когда товар появится в наличии.

Самая распространенная ошибка в Web - 404 - нарушает большинство из этих правил. Я рекомендую вам написать свое собственное сообщение об ошибке 404 вместо того, чтобы полагаться на скупую серверную фразу "page not found".

Новые правила

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

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

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

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

Вот еще несколько правил, которые позволят смягчить неприятную ситуацию, в которую попадает пользователь при ошибке:

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

Обучение пользователей

И наконец, вы наверное уже знаете Первый Закон Нильсена о компьютерной документации : люди ее не читают . Этот закон действует еще сильнее для веб-сайтов, где пользователи действительно избегают читать то, что не существенно для их задачи. Щелкнуть по ссылке "Помощь"? Да ни за что.

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

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


Рекомендуем почитать

Наверх