Народна мудрість говорить, що хороші повідомлення про помилки повинні бути ввічливими, точними і конструктивними. З приходом Web цим вимогам додалися ще кілька: робіть так, щоб повідомлення про помилку було чітко видно; у випадку помилки не повинен витрачати багато часу на її виправлення; навчайте користувачів по ходу справи.

Правила створення ефективних повідомлень про помилки не змінюються ось уже 20 років. Гарне повідомлення про помилку повинне:

  • Явно вказувати, що щось не так. Найгірше повідомлення про помилку це те, що не було створено. Якщо користувачі роблять помилку і не отримують жодного відгуку від системи, це найгірше для них. Наприклад, додаток для роботи з електронною поштою має кілька ситуацій, де вказівка говорити про помилку було б корисним. Скажімо, ви відправили повідомлення, яке було благополучно проковтну системою, але так і не досягло адресата. Ще приклад? Ви повідомляєте у листі, що докладаєте до нього файл, але просто забули зробити це. Ось тут-то і знайшлася б робота для цієї дурної скріпки з MS Office: «Схоже, ви хотіли прикріпити файл до вашого повідомлення, але не зробили цього. Хочете зробити це?».
  • Бути написано на людській мові, а не з використанням таємничих кодів і скорочень типу «помилка типу 2».
  • Бути ввічливим і не звинувачувати користувачів у тому, що вони такі дурні або зробили щось не так, як наприклад в повідомленні «заборонена команда».
  • Точно описувати джерело проблеми, а не просто видавати загальні фрази типу » синтаксична помилка».
  • Давати конструктивний рада про те, як виправити проблему. Наприклад, замість того, щоб повідомляти про те, що товару немає в наявності», ваше повідомлення про помилку повинна повідомляти, коли товар буде в наявності, або пропонувати користувачам налаштувати відправку повідомлень-попередження, коли товар з’явиться в наявності.

Найпоширеніша помилка в Web — 404 — порушує більшість з цих правил. Я рекомендую вам написати власне повідомлення про помилку 404 замість того, щоб покладатися на скупу серверну фразу «page not found».

Нові правила

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

  • Видимим і дуже помітним, як щодо самого повідомлення, так і того місця, де користувач повинен виправити помилку.

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

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

Ось ще кілька правил, які дозволять пом’якшити неприємну ситуацію, в яку потрапляє користувач у разі помилки:

  • Зберігайте як можна більше від роботи, зробленої користувачем. Дозволяєте користувачам виправити помилку в своїй дії замість того, щоб пропонувати йому все почати спочатку. Наприклад, виводячи йому результати пошуку, показуйте там же поле пошуку в ньому виводите ті ключові слова, які користувач шукав, щоб він їх міг виправити і покращити результат. Якщо пошук не дав ніяких результатів, дайте користувачеві можливість одним клацанням миші розширити область пошуку.
  • Скоротіть роботу по виправленню помилки. Якщо можливо, постарайтеся, щоб система здогадалася про правильному дії і запропонувала користувачеві вибрати це правильне дію з невеликого списку варіантів. Наприклад, замість того, щоб просто написати «назва міста не відповідає його поштовим індексом», дайте користувачеві можливість клацнути на кнопці вибрати в списку місто, відповідний його поштовим індексом.

Навчання користувачів

І нарешті, ви напевно вже знаетеПервый Закон Нільсена про комп’ютерної документації: люди її не читають. Цей закон діє ще сильніше для веб-сайтів, де користувачі справді уникають читати те, що не суттєво для їх завдання. Клацнути по посиланню «Допомога»? Та ні за що.

Користувачі читають документацію до системи тільки тоді, коли у них виникає проблема (це Другий закон). Вони особливо уважно її читають, коли хочуть виправити помилкову дію. У цьому випадку ви можете використовувати повідомлення про помилки в якості навчального матеріалу, і подавати до них ці знання малими порціями. Природно, повідомлення про помилки повинні бути короткими і по справі, як втім весь вміст веб-сайту. Однак, повідомлення про помилки все-таки можуть дати людям трохи інформації про те, як працює система, і підказати, як з нею працювати краще. І на завершення цієї теми, Web вводить ще одне правило:

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