Сообщения об ошибках это скрытая угроза успеху сайта или ПО. Если человек не понимает что от него хотят, то он быстро покидает сайт. Консультант по вопросам взаимодействия 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% успешных регистраций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ?

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

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

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

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

Что такое сообщение об ошибке?

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

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

Легче предупредить, чем исправить

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

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

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

Сообщения об ошибках неправильного ввода данных

Валидация форм необходима для сообщения пользователю об имеющихся неточностях в введенных им данных. Хорошая валидация формы содержит четыре важных элемента:

1. Правильное время (встроенная валидация)

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

Валидация должна незамедлительно информировать пользователей о правильности введенной ими информации. Главный принцип хорошей валидации формы таков: Разговаривайте с пользователями! Говорите им, что идет не так! Это поможет им сократить время на исправление ошибок.

2. Правильное место

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

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

3. Правильный цвет (интуитивный дизайн)

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

4. Понятное сообщение

Ваше сообщение об ошибке должно четко говорить пользователю, что конкретно не так и что ему нужно исправить. То есть вместо вывода сообщения «недействительный email» следует уточнить, что именно неправильно: допущена опечатка, этот e-mail уже занят и т.д. Затем необходимо предложить пользователю варианты действий (войти или восстановить пароль).

Ошибки приложений

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

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

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

Это сообщение об ошибке было написано разработчиком для разработчика: «Операция не может быть завершена (WDGeneralNetworkError 500)»

2. Тупиковое сообщение. Такие сообщения не дают никакой полезной информации для пользователей.

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

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

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

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

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

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