Коли щось йде не так, зробіть повідомлення про помилки краще

Коли справа доходить до обробки помилок, це справді командний вид спорту

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

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

Ласкаво просимо на Errorgate 2021.

Або історія як ми змінили тисячі повідомлень про помилки в Wix лише за місяць.

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

Що робить поганим повідомлення про помилку

Невідповідний тон: уявіть, що лікар виконує процедуру, а потім раптом каже: «Ой! Щось пішло не так…» Це останнє, що хтось хоче почути, коли ставки високі, будь то операція чи чиєсь джерело доходу. Зараз не час бути милим чи пухнастим. Ми хочемо показати користувачам, що ми знаємо, що це серйозно, і ми розуміємо, що це важливо для них.

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

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

Ми також прийняли рішення не перекладати провину на треті сторони, оскільки це робить нас непрофесійними, навіть якщо це зняло б частину тягаря з Wix. Користувач прийшов на Wix як на надійну платформу; вони не хочуть думати про інші платформи. Хоча ми можемо сказати щось на кшталт «У нас виникли проблеми з підключенням до ___», ми б не сказали щось на зразок «___ зараз не відповідає».

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

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

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

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

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

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

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

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

Як ми видаляли погані повідомлення про помилки

Ми здійснили пошук у нашій системі керування вмістом і виявили, що було 7643 ключі зі словом «помилка» в ключі або значенні. Це 7643 одиниці вмісту, які, принаймні, потребують перевірки.

Завдання здавалося монументальним.

Але ми це зробили. Ми переглянули кожну частину вмісту, пов’язану з помилками, і вирішили, чи підходить вона для цієї роботи. Отримавши список усіх помилок, які ми вважали «загальними» або «некорисними», ми надіслали все розробникам.

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

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

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

Що ми навчилися

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

Здебільшого це не проблема вмісту. Авішай Абрахамі, наш генеральний директор і причина, по якій розпочався цей проект, розповів про це в своєму електронному листі всім співробітникам. «Загальні помилки є результатом поганої розробки та продукту. … Ми всі повинні піклуватися про це разом».

Дійсно, усім у Wix довелося об’єднати зусилля з усіх дисциплін, щоб виправити ці повідомлення. Розробникам довелося провести дослідження та скласти карту. Продуктові менеджери повинні були розставляти пріоритети та створювати завдання. Дизайнери повинні були створити нові конструкції для нових потоків. І нам, авторам UX, довелося написати та переписати тисячі повідомлень про помилки.

Ми повинні ставити більше питань. Раніше розробник казав нам: «Гей, нам потрібне загальне повідомлення про помилку». Чи можете ви додати один?» І ми сказали б «так», вважаючи, що це буде резервне або рідкісне повідомлення. Ми не часто зупинялися, щоб поставити запитання на кшталт: «Чому користувачі це бачать?» і «Що відбувається на задньому плані?»

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

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

Коли ми працюємо разом, ми створюємо кращі продукти. Це кліше, але це правда.

Що ми змінили в нашому процесі

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

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

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

Триває процес перевірки. Як автори, ми знаємо, що все завжди можна оптимізувати. Тому ми постійно переглядаємо наші помилки, навіть ті, які нещодавно оновили.

UX-автори мають право оскаржувати загальні помилки. Якщо продуктовий менеджер або розробник скаже: «Давайте просто використовувати це загальне повідомлення про помилку в усіх випадках», тепер ми маємо право сказати «ні». Генеральний директор компанії сказав, що загальні помилки неприйнятні, тому ми не збираємося писати їх без додаткового дослідження та розуміння проблеми. Сила в нас!

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

Дженні Надлер, під редакцією Дена Раза. Графіка Янсу Жірард

Переклад wix-ux.com