Краще забути про «Ой» та «Упс». Як писати про помилки в UX

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я Черничко Антон, UX Writer. Працював протягом 15 років як копірайтер і сценарист, а останні 3,5 роки — інтерфейсним письменником у кількох застосунках. Зараз працюю у ПУМБ, веду канал про інтерфейсні тексти «Оплата пройшла успішно».

Ми стикаємося з помилками в застосунках щодня: зник інтернет, неправильний пароль, помилка оплати, помилка «404», щось пішло не так і ще десяток інших типів помилок. Я вирішив написати великий гайд, який побудований із 3 кроків та 13 рекомендацій. На вас чекають тільки свіжі приклади й тільки українською. Фокус на мобільних застосунках, але для вебу теж підійде.

Гайд буде корисний інтерфейсним та технічним письменникам, дизайнерам, розробникам, продакт-менеджерам та всім, хто пише тексти замість інтерфейсних письменників.

Поїхали!

Що таке помилка

Це стан застосунку, коли він з якоїсь причини не може виконати бажану дію користувача. Або вдається до іншої дії. Або просто зупинився. Тому застосунок попереджає користувача про проблему, що виникла, і підказує, що робити далі.

Резерв+

Коли з’являються повідомлення про помилку? У більшості випадків:

Іноді в помилках винні самі користувачі — наприклад, неправильно ввели пароль. Часом застосунок — розробники неправильно написали код. Буває ніхто не винен — просто зник інтернет.

А іноді ніхто не винен і ніхто не знає причини помилки. Трапляється і так. Але в такому разі теж винен застосунок. Однак про це згодом.

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

OLX

Чому важливо вправно писати про помилки

Щонайменше з трьох причин.

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

Друга — зберегти лояльність користувача до застосунку в конкретний момент і взагалі. Помилки викликають у людей роздратування, образи й навіть гнів. Згадайте, коли ви хочете щось отримати, а програма вам це не дає і «кричить» повідомленнями з червоними текстами. Ви дратуєтесь, розчаровуєтесь, психуєте, лаєтесь. А в такому стані зрозуміти ситуацію ще складніше. Тому хороші помилки повинні допомогти користувачам розв’язати ситуацію максимально зрозуміло, швидко та м’яко.

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

Bolt. Що таке «жива» фотографія? Що значить текст у дужках (і чому він у дужках)?

Три кроки, як вправно писати про помилки

Дізнаємося причину та контекст

Насамперед інтерфейсний письменник повинен сам розібратися у причині та контексті помилки. Інакше він не зможе правильно її описати та допомогти користувачеві її виправити.

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

Отже, користувач із цього повідомлення дізнається, що не може підписати поліс і повинен пройти все спочатку. Мабуть, він вилаявся. А коли заспокоївся, почав думати, як йому все ж таки оформити поліс: «Серйозно? Пропонуєте пройти все заново із смс та реєстрацією, перевірками фото та документів? Пишете, що треба ще раз залишити заявку на поліс. А як її залишити? Телефоном? Або на пошту? А кому залишити? Де форма чи будь-який контакт? Рятуйте! Стоп, а чому я взагалі маю залишати заявку, якщо отримав її просто через розсилку? Де тут кнопка „Видалити застосунок“?».

Так, навряд чи користувач зараз піде, але настрій ми йому зіпсували. А ще згаяли його час. Погано. Однак тепер ми зробимо цей флоу максимально корисним, щоб людина не втекла від нас одразу після того, як оформила поліс.

Почнемо з причини помилки. Тож ідемо до замовника (наразі це продакт-менеджер) та уточнюємо:

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

Тепер усе стало на місця. Так, ми не знаємо причини — таке буває. Але це не означає, що ми повинні залишити користувача наодинці з помилкою та його питаннями. Ми маємо зробити все, щоб загладити свою провину, а він оформив поліс. Розпочинаємо.

Пишемо причину помилки та пропонуємо рішення

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

• не знають причину помилки;
• не хочуть докопуватися до суті або їм її не дають;
• не хотіли вдаватися до зайвого клопоту і взяли зручний шаблон.

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

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

Щось пішло не так → Неправильний пароль

Неможливо завантажити сторінку → Зник інтернет

Ой, спробуйте ще раз → Немає грошей на рахунку

У нашому випадку: «Дуже шкода, щось пішло не так» → Поліс не оформлено.

З тих самих причин не варто писати в заголовку «Помилка».

X. Краще написати в заголовку суть помилки, навіть якщо щось справді пішло не так

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

В тілі повідомлення пишемо розв’язання проблеми, не витрачаючи час користувача на зайві слова. Не повторюємо зміст заголовка. А ще перепрошуємо, адже ми винні. І заспокоюємо користувача. Отримуємо:

Як на мене, стало значно краще. Не ідеально, але краще. Тепер людина знає, що робити, і що не доведеться вводити все знову.

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

Але коротко скажу, що кнопка повинна:

• бути короткою — 1–2 слова;
• бути зрозумілою;
• повторювати назвою дію в тілі повідомлення.

Shafa. Кнопка «Вийти» коротка, зрозуміла та повторює назвою дію в тілі повідомлення — «Бажаете вийти?»

Доповнюємо флоу діями, що здатні запобігти помилці

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

Bolt. Дати до 13.06 неактивні для бронювання, щоб запобігти помилці

У нашому випадку ми не можемо запобігти помилці, бо не знаємо її причини. Тому розберемо схожий приклад: користувач хоче оформити страховий поліс, але спливає час сесії та з’являється відповідна помилка.

Йдемо за схемою та дізнаємося причину і контекст:

• А який час сесії цього флоу?
• 1 година.
• Окей.

Що ми можемо зробити в цьому випадку, щоб запобігти помилці? Ми знаємо час сесії, а користувач ні. Дізнається він його лише після того, як з’явиться помилка. А нам якраз треба зробити навпаки — щоб він дізнався про це до помилки! Тому рішення напрошується саме — повідомити його про час сесії заздалегідь. Як ми можемо це зробити? Тултіпом? Це варіант. Ще можна підказати в тілі повідомлення або окремим рядком:

Текст не ідеальний, але вирішує завдання — тепер клієнт знає ліміт часу та наслідки.

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

Але це ще не все, сама по собі схема — тільки половина справи.

Ось ще 13 корисних рекомендацій, щоб написати гарний текст про помилку

1. Перепросити, якщо є ваша провина

З нас корона не впаде, а користувачеві буде приємно. До того ж це робить тон спілкування людським, а не роботизованим.

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

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

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

Інтерфейсна письменниця Torrey Podmajersky у своїй книзі Strategic UX Writing пише, що якщо вибачення є доречним, краще просити вибачення за затримку, втрату, незручності чи розчарування користувача.

А ви як думаєте? Варто перепрошувати чи ні? Пишіть у коментарях.

2. Не звинувачувати користувача, навіть якщо він винен

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

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

Ще він не повідомляє, що користувач помилився. У цьому величезна різниця з текстом ліворуч.

3. Писати зрозуміло та доступно

Без системних цифр, кодів, жаргону, технічних термінів, серверів і датабаз. Гарний текст зрозумілий з першого прочитання.

4. Заспокоїти користувача

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

5. Уникати надто творчих текстів

Так, з одного боку, тексти помилок — поле для креативного маневру. З іншого боку, важливо знати міру і не втратити в ній суть повідомлення.

6. Акуратно підходити до гумору в текстах

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

7. Не лякати користувача

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

8. Уніфікувати структуру тексту

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

Наприклад:

• пишемо заголовок без розділового знаку наприкінці або з ним;
• не пишемо заголовок капсом;
• у тілі повідомлення пишемо без емодзі.

9. Мабуть, уже краще забути про «Ой» або «Упс»

Тут відразу кілька причин: це застаріло, безрезультатно, може не потрапляти в TOV і, схоже, ви не знаєте, чому ваш застосунок дає збій. Якщо ж ви все одно хочете «Упс», то краще використовувати щось на штиб українських вигуків і фраз: «Халепа», «Дзуськи», «Усе догори дриґом» чи щось подібне. Нумо!

10. Не перекладати провину на ваших партнерів

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

11. Попередити про помилку

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

12. Налаштувати інверсію

Дайте користувачеві можливість повідомляти про помилки. Через чат, спеціальне вікно тощо. Він випустить пару, відчує себе корисним, а ви отримаєте слушний зворотний зв’язок.

Duolingo

13. Знижуйте градус відразу

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

Погода в iPhone

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

Заходьте на мій канал у телеграм «Оплата пройшла успішно» — там будуть схожі матеріали щодо інших елементів UX: кнопок, попапів, пушів, тултипів, розбір вдалих і невдалих прикладів UX-текстів, опитування та всяке різне.

Дякую Марії, засновниці каналу 404 | сторінку не знайдено за надані приклади помилок. Підписуйтесь — там багато цікавих, нудних і веселих сторінок 404 з мережі інтернет.

Заходьте в гості до української спільноти юікс-райтерів — UX-райтери: там обговорюють, поширюють, радяться та нетворкаються.