Х'юстон, у нас проблеми, або Як показувати повідомлення про помилки

Х'юстон, у нас проблеми, або Як показувати повідомлення про помилки

  • 15 січня, 2019
  • читати 2 хв

Людині властиво помилятися. Помилки виникають, коли люди взаємодіють з користувацькими інтерфейсами або тому, що користувачі роблять помилки. Іноді помилки виникають в самому додатку. Незалежно від причини і того, хто винен у виникненні проблеми, обробка та відображення помилок мають величезний вплив на UX. Некоректна обробка помилки разом з марними повідомленнями про помилку, можуть викликати у користувача негативну реакцію, що згодом може привести до відмови користувача від використання вашого додатку.

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

Обробка і відображення помилок мають величезний вплив на UX

Мільйони людей щодня відвідують різні сайти. Природно, це не завжди проходить, як по маслу, та іноді трапляються помилки, що відбуваються то з вини розробників, то з вини користувачів. На мою думку, очевидно, що якщо помилка мала місце, причому не важливо звідки б, скрипт повинен показати її в зручній для користувача формі.

Але дуже часто продуктові команди не приділяють достатньо уваги таким сценаріями. Наприклад, дуже типова історія: «Щось пішло не так. У нас проблеми, тому просто закрийте це повідомлення».

Коли в системі на будь-яку помилку було повідомлення «Упс, щось пішло не так» кількість дзвінків і створених запитів могла досягати 300-400 на день

Хороші повідомлення про помилки в першу чергу знижують навантаження на службу технічної підтримки. Ми переконалися в цьому на власному прикладі. Коли в системі на будь-яку помилку було повідомлення «Упс, щось пішло не так» кількість дзвінків і створених запитів могло досягати 300-400 на день. Рішення проблем дуже затягувалося через те, що користувачі не могли пояснити, що вони зробили перед тим, як отримати дане повідомлення. Після проектування коректних повідомлень про помилки і своєчасних попереджень про те, що система може працювати зі збоями, кількість запитів і дзвінків скоротилася в 10 разів і довіра користувачів до системи значно підвищилася.

Метою цієї статті є нагадування про те, що помилки повинні виводитися в системі грамотно:

— Помилки треба показувати, ніяких переадресаций;

— Необхідно використовувати прихильність помилок до їх причин або розміщувати їх в очікуваному місці;

— Якщо немає можливості використовувати прихильність, то використовувати колірне кодування;

— Уникати невпевнених помилок типу: «У вас введений невірно або пароль, або логін»;

— Запобігати помилки, шляхом пояснень під полем введення.

Завжди краще запобігти помилкам шляхом надання користувачу чітких інструкцій до дій. Але це можливо зробити не завжди. Коли помилки виникають, правильно відображені повідомлення про них не тільки зможуть навчити ваших користувачів взаємодії з додатком, а й позбавлять їх від відчуття того, що вони неграмотні. Повідомлення про помилку — найменш приємна частина дизайну. Однак, якщо ви докладете певних зусиль, ваш продукт буде комфортно використовувати.