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

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

Більшість застосунків, створених з допомогою ШІ, помиляються саме в цьому. Не тому, що білдер зробив щось недбало, а тому, що повідомлення про помилки — це те, про що ніхто не думає, доки щось не піде не так на очах у реальної людини. За замовчуванням застосунки зазвичай показують один із двох найгірших варіантів: нічого або лякаючий блок технічного тексту. Виправимо обидва.

Чому застосунки мовчки провалюються або показують страшні помилки?

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

Мовчазний збій. Фрілансерка, яку я назву Майя, створила форму бронювання для свого фотобізнесу. Клієнтка натиснула «Підтвердити бронювання», кнопка блимнула — і… нічого. Ні підтвердження, ні помилки, ні індикатора завантаження. Спрацювало чи ні? Клієнтка не була впевнена, тож забронювала ще раз. Тепер у Майї було два бронювання на один і той самий час і спантеличена клієнтка. Застосунок не впав — просто не вдалося зберегти дані, і застосунок нічого про це не сказав, тож людина перед екраном не мала жодного уявлення про реальний стан справ.

Страшна технічна помилка. Другий тип збою гучніший і чомусь ще гірший. Волонтерка, яка організовувала громадський збір коштів, спробувала завантажити таблицю й отримала червоне вікно з написом Error 500: Internal Server Error. Вона прочитала це як «я щось зламала». Вона не спробувала ще раз, не написала на пошту з проханням про допомогу — просто закрила вкладку, бо повідомлення звучало так, наче проблема — її провина, і що краще більше туди не лізти.

Обидва користувачі зіткнулися зі звичайною, вирішуваною проблемою. Обидва пішли, бо повідомлення про помилку в застосунку або мовчали, або лякали.

Що робить повідомлення про помилку хорошим?

Хороше повідомлення про помилку робить чотири прості речі простими словами: пояснює, що сталося, каже, чия це проблема, каже, що робити далі, і не втрачає роботу користувача.

Пояснює, що сталося — «Нам не вдалося зберегти ваше бронювання», а не тиша й не 500.
Каже, чия це проблема — зазвичай чесна відповідь «наша», і визнання цього заспокоює людей.
Каже, що робити далі — «Спробуйте ще раз за мить» або «Перевірте інтернет-з’єднання й повторіть спробу».
Не втрачає їхню роботу — усе, що людина ввела, залишається у формі, коли з’являється повідомлення.

Ось і все. Жодного есе-вибачення, жодного коду помилки в заголовку, жодних звинувачень. Ось ті самі три збої, переписані:

❌ (нічого не відбувається) → ✅ «Нам щойно не вдалося це зберегти. Ваші дані досі тут — натисніть «Підтвердити», щоб спробувати ще раз».
❌ Error 500: Internal Server Error → ✅ «Під час завантаження файлу щось пішло не так з нашого боку. Це не через вас. Спробуйте ще раз за хвилину».
❌ Invalid input → ✅ «Цей номер телефону виглядає неправильно — він має складатися з 10 цифр, наприклад 555-123-4567».

Зверніть увагу на останній приклад: він вказує на конкретне поле й показує, як має виглядати правильний варіант. «Invalid input» змушує людину здогадуватися; «цей номер телефону має бути 10 цифр» точно каже, що виправити.

Які помилки застосунку варто виправити першими?

Не потрібне окреме повідомлення для кожного можливого збою — три категорії покривають майже все, що може піти не так у типовому застосунку: збереження чи надсилання, яке провалилося, дані, які застосунок не може обробити, і те, що ламається на вашому боці.

Збереження чи надсилання, яке провалилося. Найбільш руйнівне для довіри, бо користувач зробив усе правильно й не впевнений, чи спрацювало це. Завжди підтверджуйте успіх і пояснюйте невдачу. Ніколи не залишайте людину гадати й ніколи не викидайте те, що вона ввела.

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

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

Три звички, які тихо допомагають

Кілька речей відрізняють застосунки, що елегантно справляються зі збоями, від тих, що ні:

Ніколи не показуйте сирий код помилки як усе повідомлення. Код може ховатися дрібним текстом унизу для служби підтримки, але заголовок, який читає людина, має бути реченням, а не ERR_CONN_RESET.
Ніколи не звинувачуйте користувача. «Ви ввели щось неправильно» ранить; «ця дата виглядає так, ніби вона в минулому — можливо, ви мали на увазі наступний місяць?» допомагає. Та сама інформація, зовсім інше відчуття.
Завжди зберігайте введені дані. Якщо застосунок перезавантажується або збереження провалюється, а форма порожніє, ви перетворили дрібну заминку на десять хвилин повторного введення даних. Люди пробачають невдале збереження. Вони не пробачають подвійну роботу.

Як змусити свій ШІ-білдер писати кращі повідомлення про помилки?

Більшість цього можна отримати одним запитом — вставте щось на кшталт підказки нижче, і ваш ШІ-білдер застосує описані вище правила простої мови у всьому застосунку.

«Коли збереження чи завантаження не вдається, не мовчи і не показуй технічний код помилки. Покажи коротке, дружнє повідомлення простою мовою, яке пояснює, що сталося, каже, що можна спробувати ще раз, і зберігає все, що користувач уже ввів. Для полів форми валідуй їх одразу, як користувач покидає поле, і показуй конкретне повідомлення з прикладом правильного формату».

Потім попросіть його показати, що відбувається у трьох випадках: немає інтернету, обов’язкове поле порожнє, сервер повільний. Якщо відповідь на будь-який із них — «нічого не показується» або «показується сирий код помилки», ось ваш наступний фікс.

Як перевірити повідомлення про помилки у вашому застосунку?

Вимкніть Wi-Fi, відкрийте застосунок і спробуйте виконати основну дію — це весь тест, і він займе дві хвилини.

Забронюйте час, збережіть нотатку, завантажте файл. Подивіться, що він каже. Чи повідомив він щось зрозуміле звичайній людині? Чи втратив він те, що ви ввели? Тепер увімкніть Wi-Fi назад і навмисно введіть якусь нісенітницю в поле. Ті самі запитання.

Більшість застосунків не проходять цей тест з першого разу, і це нормально — він просто показує, з чого почати. Не обов’язково робити ідеальним кожне повідомлення про помилку. Знайдіть у своєму застосунку те, що ламається найчастіше, і зробіть саме це повідомлення добрим, зрозумілим і чесним у першу чергу. Наступного разу, коли реальна людина з ним зіткнеться, вона спробує ще раз замість того, щоб піти — а спробувати ще раз і є всією суттю гри.