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

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

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

• Форматування курсової допомоги; можливо, просте коротке повідомлення з кнопкою "дізнатися більше", що призводить до більш тривалого, детального повідомлення про помилку
• Всі повідомлення про помилки мають посилання на деякий розділ керівництва користувача (дещо важко досягти)
• Просто не видайте повідомлення про помилки, просто відмовтеся виконувати завдання (дещо "яблучний" спосіб обробки даних користувача)

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

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

• Не розміщуйте повідомлення про помилки в рядку статусу - вони ніколи їх не читатимуть, незважаючи на те, що вони збиті кольорами тощо .... вони завжди пропускають їх! Як би важко ви не намагалися ... На одному етапі під час тестування інтерфейсу Win 95 перед його запуском MS провела експеримент з читання інтерфейсу користувача ( ред. - слід зазначити, що повідомлення явно зазначено в контексті "Подивіться під стілець" ) із купюрою в 100 доларів, приклеєною до нижньої сторони стільця, на якій сиділи випробовувані ... ніхто не помітив повідомлення в рядку стану!
• Зробіть повідомлення короткими, не вживайте залякуючих слів, таких як "Сповіщення: система зіткнулася з проблемою", кінцевий користувач натисне кнопку паніки і буде надмірно реагувати ...
• Як би ви не старалися, не використовуйте кольори для ідентифікації повідомлення ... психологічно це схоже на те, щоб помахати бику червоним прапором!
• Використовуйте слова нейтрального звучання, щоб передати мінімальну реакцію та як діяти далі!
• Можливо, краще показати діалогове вікно з переліком нейтрального повідомлення про помилку та включити прапорець із зазначенням "Чи хочете Ви бачити більше таких повідомлень про помилки в майбутньому?", Останнє, що хоче кінцевий користувач, - це працювати. в середині програмного забезпечення, яке буде обстріляно спливаючими повідомленнями, вони зірвуться і додаток буде вимкнено! Якщо прапорець поставлений галочкою, замість цього введіть його у файл ...
• Інформуйте кінцевих користувачів про те, які повідомлення про помилки будуть ... що означає ... навчання та документацію ... тепер це складно перейти ... Ви не хочете, щоб вони думали, що буде бути "питаннями" або "глюками" і що робити у випадку цього ... вони не повинні знати, що можливі помилки, справді хитрі.
• Завжди завжди не бійтеся просити зворотного зв’язку, коли трапляється безпрецедентне явище - наприклад, "Коли з'явилася помилка № 1304, як ви відреагували? Якою була ваша інтерпретація "- бонус за це, кінцевий користувач, можливо, зможе дати вам більш узгоджене пояснення замість" Помилка 1304, об’єкт бази даних втрачено! ", Замість цього вони можуть сказати" Я натиснув на це так і так, то хтось випадково потягнув мережевий кабель машини ', це підкаже вам про те, що вам доведеться зіткнутися з цим, і може змінити помилку, сказавши: "Ой, мережеве з'єднання відключено" ... ви отримаєте дрейф.
• І останнє, але не менш важливе значення, якщо ви хочете націлити на міжнародну аудиторію, врахуйте інтернаціоналізацію повідомлень про помилки - отже, тому слід тримати її нейтральною, тому що тоді буде простіше перекладати, уникати синонімів, сленгових слів тощо, які могли б зробити переклад безглуздий - наприклад, Fiat Ford, компанія автомобільних автомобілів продавала свою марку Fiat Ford Pinto, але помітили, що в Південній Америці ніяких продажів не відбувалося, виявилося, Пінто там був сленгом для «маленького пеніса» і, отже, ніяких продажів ...
• ( ed ) Документуйте перелік повідомлень про помилки, які слід очікувати в окремому розділі документації під назвою "Повідомлення про помилки" або "Виправні дії" або подібному, перераховуючи номери помилок у правильному порядку із заявою або двома про те, як діяти далі. ..
• ( ed ) Завдяки Віктору Хурдугачі за його вклад, зберігайте повідомлення ввічливими, не змушуйте кінцевих користувачів відчувати себе дурними. Це суперечить відповіді Джека Марчетті, якщо база користувачів є міжнародною ...

Редагувати: Особливе слово подяки гніблеру, який також згадав ще одну надзвичайно важливу точку!

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

Редагувати №2: Моє погано! Ой, дякую Данму, який згадував, що про машину я назвав змішану назву, це був Ford Pinto ... мій поганий ...

Редагувати №3: Позначити редактором для вказівки додаткових або доповнень та зарахувати інших за їх вклад ...

Редагувати №4: У відповідь на коментар Кена - ось моя думка ... Ні, це не так, використовуйте нейтральні стандартні кольори Windows ... не йдіть на кричущі кольори! Дотримуйтесь звичайного сірого кольору заднього кольору з чорним текстом, що є звичайною стандартною інструкцією GUI у специфікаціях Microsoft. Див. Рекомендації щодо UX ( ред. ).

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

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

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

Коротка відповідь: Ви не можете.

Менш коротка відповідь: зробіть їх видимими, релевантними та контекстуальними (виділіть те, що вони зіпсували). Але все-таки ти ведеш програшну битву. Люди не читають на екранах комп’ютера, вони сканують, і їх навчають натискати кнопки, поки діалогові вікна не зникнуть.

У поле помилок ми поміщаємо просту пам’ятну графіку: не піктограму, досить велику растрову карту та нічого подібного до стандартних піктограм повідомлень Windows. Ніхто не може згадати формулювання скриньки повідомлень (більшість навіть не прочитає її, якщо в полі є кнопка "ОК", яку вони можуть натиснути), але більшість людей НЕ пам'ятають картинку, яку вони бачили. Тож наші служби підтримки можуть запитати замовника "ти бачив хлопця, що п'є каву?" або "ти бачив порожню парту?". Принаймні так ми приблизно знаємо, що пішло не так.

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

Наприклад, я написав заявку, яка дозволила нашим персоналам краще відслідковувати дати найму / звільнення працівників. [ми були невеликою компанією, дуже відстороненою].

Коли вони ввели неправильні дати, я напишу:

Гей, німа дупа, навчися вводити побачення!

EDIT: Звичайно, більш корисним є повідомлення: "Будь ласка, введіть дату як mm / dd / yyyy" або, можливо, в коді, щоб спробувати зрозуміти, що вони ввели, і якщо вони ввели "blahblah", щоб показати помилку. Однак це була дуже маленька заявка для HR людини, яку я знав особисто. Тому знову люди, читайте перший рядок цієї публікації: Залежно від вашої бази користувачів ...

Нещодавно я працював над проектом Art Institute, тому повідомлення про помилки були спрямовані на аудиторію, наприклад:

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

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

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

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

Складіть спеціальне поле для повідомлень . Ніколи не використовуйте поле повідомлень за замовчуванням у системі, наприклад, вікна повідомлень Windows XP дратують себе. Створіть нове кольорове поле з іншим кольором фону, ніж системний за замовчуванням.

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

ОНОВЛЕННЯ
Зробіть повідомлення значимим та корисним . Наприклад, не пишіть щось на кшталт "Клавіатури не знайдено, натисніть F1 для продовження".

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

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

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

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

Наприклад, я передаю таке повідомлення:

ORA-00237: операція зйомки заборонена: створений файл управління новостворений Причина: зроблена спроба викликати cfileMakeAndUseSnapshot із створеним на даний момент керуючим файлом, який був створений за допомогою CREATE CONTROLFILE. Дія: встановіть поточний файл керування та повторіть операцію.

до чогось типу:

Цей крок не вдалося обробити через миттєві проблеми з базою даних. Для вирішення проблеми зверніться (ваш адміністратор | довідковий відділ | будь-хто, хто може звернутися до розробника чи адміністратора). Вибачте за незручності.

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

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

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

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

Редагувати:

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

Мені особисто подобається програмне забезпечення, яке не змушує мене думати , і коли періодично немає нічого, що ви (розробник) можете зробити для тлумачення мого наміру, надайте дуже добре написані (і переглянуті фактичними користувачами) повідомлення.

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

Зробити їх весело . (Це здалося актуальним, враховуючи сайт, на якому ми працюємо :))

Для початку напишіть повідомлення про помилки, які користувачі можуть насправді зрозуміти. "Помилка: 1023" - не гарний приклад. Я думаю, що кращим способом є реєстрація помилки, ніж показ її користувачеві з деяким "фантазійним" кодом. Або якщо реєстрація неможлива, наведіть користувачів належним чином надіслати інформацію про помилки до відділу підтримки.

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

Якщо ваша програма - це веб-додаток, розробка нестандартних сторінок помилок - хороша ідея. Вони менше підкреслюють користувачів, наприклад, беруть SO. Ви можете отримати ідеї, як створити хорошу сторінку помилок тут: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Я хотів би додати одне.

Використовуйте дієслова для кнопок дії, щоб закрити повідомлення про помилки, а не вигуки, наприклад, не використовуйте "Добре!" "Закрити" тощо.

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

Ви повинні написати найважливіші речі для читання, по-перше, і надати більш детальну інформацію вдруге.

Іншими словами, це не добре:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Натомість змініть порядок:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

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

Дивіться також відповіді користувачів Slashdot тут .

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

З іншого боку, якщо ви дійсно можете показати користувачеві корисний спосіб вирішення, тоді одним із способів змусити їх прочитати - зробити так, щоб кнопка «ОК» увімкнулася через 10 секунд або близько того. Сортуйте, як Firefox робить це кожного разу, коли ви намагаєтесь встановити новий плагін.

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

" Вибачте, що ми збрехали, ми хотіли б надіслати деяку інформацію про цю аварію. Чи дозволите ви це зробити? Так / НІ "

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

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

Редагувати:

Хтось колись також нещодавно запропонував використовувати комікси разом із тим, яке повідомлення ви хочете показати. Наприклад, щось від Ділберта, що може бути близьким до типу помилок, які ви можете мати.

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

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

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

Тільки для запису: є користувачі, які НЕ читають повідомлення про помилки, але так бояться, що з цим нічого не зроблять. Одного разу мені було дзвонити в службу підтримки, де замовник прочитав мені повідомлення про помилку і запитав мене, що йому робити. "Ну, які у вас варіанти?", Запитав я. "У вікні є лише кнопка" ОК ".", - відповів він. ... ммм, важко :)

Я часто відображаю помилку червоним кольором (коли дизайн це дозволяє).

Червоний означає «попередження» тощо, тому його частіше читають.

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

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

Звичайно, це трохи ідеальний світ. Іноді програмні помилки неминучі. Коли вони виникають, вам потрібно надати чітку, повну та корисну інформацію, а головне, не піддавати систему користувачеві та не звинувачувати користувачів у своїх діях.

Гарне повідомлення про помилку повинно містити:

1. У чому проблема і чому це сталося.
2. Як вирішити проблему.

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

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

Менше помилок

Якщо програма регулярно кидає на вас блювоту, ви ставитеся до неї імунітетом, а помилки стають подразливим фоном музака. Якщо помилка - рідкісна подія, вона приверне більше уваги.

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

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

Срібної кулі немає, але вам потрібно зробити соціального інженера, щоб зробити важливі помилки.

Ми сказали користувачам, що з ними звернувся менеджер (що було брехнею). Це працювало трохи надто добре, і його потрібно було зняти.

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

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

Якщо на сторінці є помилки (я більше розглядаю веб-розробки, отже, я називаю це "сторінкою", але це також можна назвати "формою"), покажіть "резюме помилок", пояснивши, що там були помилки та кращий перелік того, що саме трапилось. Однак якщо на повідомлення входить більше 5-6 слів, вони не будуть прочитані / зрозумілі.

Як щодо створення кнопки "Клацніть тут, щоб поговорити з техніком із підтримки, який допоможе вам у цьому питанні."

Існує багато веб-сайтів, які надають можливість поговорити з реальною людиною.

Я читав кандидата на найжахливіше рішення на Slashdot:

Ми з’ясували, що єдиний спосіб змусити користувачів брати на себе відповідальність за помилки - це надати їм штраф за примушення виправити помилку. Для початківців, де це можливо, помилка фактично не закриється для них, якщо ми не введемо пароль адміністратора, щоб зникнути, і якщо вони перезавантажуються, щоб позбутися від нього (диспетчер завдань відключений на всіх клієнтських ПК), машина не відкриє додаток, який вийшов з ладу протягом 15 хвилин. Звичайно, все це залежить від типу користувачів, з якими ви маєте справу, оскільки більш технічно досвідчені користувачі не бажають приймати подібну систему, але після спроб буквально РОКІВ змусити користувачів взяти на себе відповідальність за збої та переконатися, що ІТ-відділ знає про це їх для того, щоб виправити проблему, перш ніж стає занадто важко керувати, це єдині кроки, які працювали. Тепер,

"УВАГА! УВАГА! Якщо ви не прочитали повідомлення про помилку, ВМЕРИТЕ!"

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

Користувач повинен зробити вибір перед OK з'явиться кнопка

Якщо він вибере 3-й варіант, він може продовжити, інакше додаток закриється.