UXPUB

UXPUB - спільнота з 4,813 дизайнерів та креативних фахівців

Місце для обміну досвідом та дискусій навколо індустрії

Зареєструватися Увійти
Cover image for Коли щось йде не так, зробіть повідомлення про помилки краще
Dinozavrix
Dinozavrix

Опубліковано

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

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

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

Емоджі із замисленим обличчям, оточене 6 прикладами помилок, як-от «Ура!  Щось пішло не так» і «Ой!  Сталася невідома помилка».

Ми постійно стикаємося з повідомленнями про помилки, але як часто вони насправді допомагають нам зрозуміти, що пішло не так і як це виправити?

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

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

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

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

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

Спливаюче вікно про помилку, яке демонструє погане повідомлення про помилку з виділеним розділом, щоб показати, чому це погано.. «Ой!  Щось пішло не так.  (використовує невідповідний тон) Третя сторона, до якої ви намагаєтеся підключитися, не відповідає (перекладає провину), тому ми не можемо отримати ваші дані (використовує технічний жаргон).  Спробуйте пізніше (занадто загальний).  Кнопка "Закрити".

Це приклад поганого повідомлення про помилку. Воно використовує невідповідний тон, перекладає провину, говорить на технічному жаргоні та є надто загальним.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

система керування завданнями, яка показує різні типи помилок, їхні пріоритети, тип помилки та термін виконання.

Це була лише одна з дощок Monday.com, які ми використовували для класифікації кожного окремого вмісту, пов’язаного з помилками. Такі дошки допомогли нам встановити пріоритети, терміни виконання та тримати в курсі всі дисципліни.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обговорення (1)

Згорнути/розгорнути
mykola_golovko profile image
Mykola Golovko

Стаття хороша, дякую. Але немає сенсу давати, англійські приклади, без їх перекладу. Так як, з перекладом помилки, деякі фрази зникнуть, або буде переведено інакше. Відповідно, термінологія в даній статті втратить сенс.