Они скользят под волнами паутины, молча, свирепо и, казалось бы, просто ждут возможности нанести удар. Они бывают разных форм, размеров и уровней раздражения, и они почти всегда атакуют, когда вы меньше всего этого ожидаете.
Сообщения об ошибках являются частью цифрового мира, и, нравится вам это или нет, все сталкивались с ними раньше, от технологически сложной хозяйки до хардкорного геймера.
Как разработчики мы, вероятно, видим их чаще, чем большинство. Они неизбежны, но то, как мы представляем эти ошибки пользователю, может иметь либо положительный эффект (ну, как положительный, как можно ожидать), так и решительно отрицательный.
Давайте рассмотрим способы, которыми мы можем подойти к обработке сообщений об ошибках, чтобы они передавали смысл и обеспечивали хороший пользовательский опыт. Кроме того, я считаю важным отметить, что все приведенные здесь примеры были выбраны без предвзятости. Я выбрал их только потому, что они иллюстрировали некоторые моменты.
Профилактика лучше чем лечение
Прежде чем приступить к обработке сообщений об ошибках, может быть полезно посмотреть, как мы можем предотвратить возникновение ошибки в первую очередь, заранее направляя пользователей в нужном направлении.
Например, новые пароли являются классическими кандидатами для этого метода. Вышеприведенный твит забавен, но он говорит о проблеме, которую во многих случаях можно было бы полностью избежать: дать пользователям знать о плохих паролях после факта. Видишь, как много внимания получил твит? Это знак, индустрия.
Лучшим подходом было бы проинформировать пользователя о требованиях к проверке пароля или о том, как создать надежный пароль, прежде чем он нажмет кнопку отправить Еще лучше, обучите их, поскольку они это печатают.
Выше, идея очень удивительного Пола Льюиса, которую вы можете найти здесь , является одним из таких примеров живой обратной связи. Здесь каждый тик активируется, как только пароль соответствует условию, а это означает, что пользователь никогда не получает раздражающих сообщений об ошибках.
Если вы используете структуры привязки данных, такие как AngularJS или EmberJS, этот тип мгновенной обратной связи даже не сложен в реализации и имеет большое значение для хорошего пользовательского опыта.
Рука помощи
Однако когда происходит неизбежное, важно убедиться, что ошибки полезны и ведут пользователей туда, куда они, скорее всего, захотят пойти. Дон Норман из несколько легендарной группы Nielsen Norman , выступает за коллективный подход, когда дело доходит до сообщений об ошибках, давая пользователям полезные рекомендации о том, как выполнить свою задачу.
Вау. Это сообщение об ошибке было бы замечательно, если бы я знал, что такое «0x000000643», но, поскольку я не являюсь ни машиной, ни программистом, составившим сообщение об ошибке, я не знаю. И ваш пользователь тоже.
Если я сталкиваюсь с этой ошибкой, я не знаю, как продолжить. Я в значительной степени застрял, где я нахожусь в этом процессе, и мне не предлагают никаких указаний относительно того, как продолжить. И хотя этот вид ошибки может показаться устаревшим и смехотворным для некоторых, во многих отношениях он не слишком отличается от того, что мы видим сегодня в Интернете.
Эта ошибка дает мне столько же информации, сколько и предыдущая, и если бы я не работал в сети, я бы не понял, что это значит. Ваши пользователи, вероятно, не работают в Интернете, и они определенно не будут знать, что это значит.
Так как же дать пользователям более значимые сообщения об ошибках?
Возможно, лучший способ — понять, что пользователь на самом деле пытается достичь, когда они сталкиваются с вашими ошибками, а затем помочь им в этом. Руководство по стилю для Android на самом деле представляет собой хороший подход к обработке ошибок таким способом.
На самом деле нет ничего технически неправильного в сообщении в столбце «не»; он точно говорит вам, что вам нужно сделать, чтобы справиться с GPS вашего устройства, хотя и смутно.
Но было бы редко, если бы я специально хотел «вручную управлять своим GPS»; сообщение справа лучше, потому что оно раскрывает саму суть проблемы (то, что ваш GPS убивает время автономной работы) и помогает пользователю, направляя их к точному и ясному решению.
Опять же, идея заключается в том, чтобы создать среду, которая не наказывает пользователя за то, что на самом деле является «машинной проблемой», имея в виду, что машинные процессы существуют для удовлетворения потребностей человека. Как люди, мы не должны соответствовать тому, как машины делают вещи, это должно быть наоборот.
Просто для лулза
Если ошибка является распространенной и достаточно известной, существует также другой способ обработки ее представления пользователю: юмор. Приложения для такого подхода невероятно редки, и самым известным примером, вероятно, является печально известная ошибка 404.
Существует множество хороших 404 примеров. Страница Github, в частности, очень хороша, потому что она использует тот факт, что подавляющее большинство ее пользователей, вероятно, знают Star Wars и, таким образом, точно знают, на что ссылается изображение.
Фактически, есть ряд компаний, которые используют свою страницу 404 в качестве средства, чтобы расширить голос своего бренда, представляя эффективные и соответствующие сообщения своим пользователям, несмотря на тот факт, что 404 — это незапланированный, раздражающий результат.
Однако, опять же, обратите внимание, что почти каждая страница 404 также содержит информацию, которая поможет пользователю вернуться к своей первоначальной задаче, будь то с удобной панелью поиска или с одной или двумя ссылками, которые приведут вас в нужное место.
Вывод
Предотвращение ошибок — это всегда лучший способ, но когда это невозможно, хорошим сообщением об ошибке может быть разница между возвращающимся пользователем и раздраженным, даже сердитым, телефонным звонком вам или какой-то бедной душе в вашей компании.
Делая ваши сообщения об ошибках полезными, совместными и даже забавными, вы сможете сохранить этого пользователя или клиента и, если вам повезет, даже создать более прочную связь с вашим сайтом или брендом.