Упс, что-то пошло не так. Как UX-редактору написать сообщение об ошибке?

А вы знали, что 70% пользователей покидают сайт или приложение, если сталкиваются с непонятными или неинформативными сообщениями об ошибках?

Привет! Сегодня поговорим о том, что такое плохо написанное сообщение об ошибке. Разберемся, почему непонятные сообщения об ошибках портят не только UX, но также вредят продукту и бизнесу. Конечно, также покумекаем о формуле, благодаря которой слагаются классные сообщения, и о важности коммуникации UX-редактора с командой разработки.

Не открываю Америку, и все же…

Что такое сообщение об ошибке?

Сообщение об ошибке — это информация, которая показывается пользователю при возникновении той или иной проблемы. Правильно написанные сообщения помогают пользователю понять, что пошло не так, и предлагают пути решения проблемы. А неправильно написанные – перекладывают вину за ошибку на пользователя, вводят его же в недоумение и ступор, ничего не объясняя, а просто сообщая «Упс, ошибочка!» и так далее.

Картинка отсюда (знаю, что она и её сестра, прикрепленная ниже, ходят-бродят по сети не один год). Это пример неправильного сообщения об ошибке, которому характеры: неуместный тон, перекладывание вины на пользователя, использование технического жаргона и слишком абстрактные формулировки.

Какие ошибки бывают?

Ошибки в пользовательских интерфейсах неизбежны и могут возникать по разным причинам. Советую ознакомиться с кодами состояния ответа HTTP. Для себя я выделяю три типа, но, конечно, на самом деле их больше:

Бизнесовые/продуктовые

К бизнесовым ошибкам принадлежат те, к примеру, которые совершаются пользователем при использовании приложения или сайта. Сюда входят, например, ошибки ввода. Именно такие ошибки лучше всего предупреждать. Именно за то, чтобы по ходу дела у пользователя возникло как меньше проблем, отвечают дизайнеры и UX-редакторы, создавая понятные и простые формулировки, прокладывая и формируя грамотный пользовательский флоу. В очередной раз воспользуюсь цитатой из книги «Здесь должен быть текст» М. Меттса и Э. Уэлфла»:

«…лучше, конечно, вообще предотвращать ошибки, подсказывая пользователю на всем его пути (визуальными подсказками и паттернами взаимодействия)».
Технические/сервисные

К таким ошибкам относятся проблемы с сервером, базой данных или другими компонентами системы. Пользователь никаких ошибок не совершал, но сервер по каким-то причинам недоступен. Ну, кто из нас не сталкивался с тем, что приложение временно недоступно? Хорошо, если такие проблемы решаются достаточно быстро.
Сетевые

Сетевые ошибки могут возникать по разным причинам: нестабильное соединение с сетью, недоступность прокси-сервера (он не работает или что-то блокирует доступ к нему на пути от ПК до этого прокси-сервера), различные точечные санкции от сервисов (некоторые ресурсы могут быть недоступны для определенных адресов).

Почему важно писать хорошие сообщения об ошибках?

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

Я не забываю и о пользе для бизнеса. Нередко в сообщении об ошибке не предлагается каких бы то ни было вариантов решения проблемы, кроме как обратиться в поддержку. Однако поддержка – это определенные (большие!( траты. Чем выше нагрузка на поддержку, тем дороже это дело для бизнеса. Зачем призывать людей обращаться в поддержку, когда можно сэкономить буквально и время, и деньги, просто написав одно полезное предложение? Как показывают некоторые исследования, хорошо написанные сообщения об ошибках могут снизить количество обращений в службу поддержки на 25% (иногда и больше), так как пользователи смогут самостоятельно решить возникшие проблемы.

Немного статистики:

Согласно исследованию, проведенному компанией Nielsen Norman Group, 90% пользователей считают, что четкие и понятные сообщения об ошибках значительно улучшают их опыт взаимодействия с продуктом.
Исследования показывают, что 70% пользователей покидают сайт или приложение, если сталкиваются с непонятными или неинформативными сообщениями об ошибках. Хорошо написанные сообщения могут снизить этот показатель и удержать пользователей.
Компания UserTesting тоже провела свое исследование и выяснила, что целых 85% пользователей доверяют бренду больше, если они получают полезные и вежливые сообщения об ошибках.

Сообщение написано неправильно, если…

Нет конкретики, один только факт наличия ошибки. Безусловно, сообщение не должно быть похоже на сочинение, однако одна из ключевых задач такого сообщения – показать решение. Что мне, как пользователю, даст полупустая формулировка «Ошибка» без какого-либо уточнения, в чем эта ошибка заключается и как мне сделать то, что я хочу – оплатить коммуналку, заказать продукты или купить билет на Аляску.

Такие сообщения слишком непонятны. А что делать дальше? Какая проблема? Почему не получилось авторизоваться? Почему загрузка не удалась? Куча вопросов, ни одного ответа.Итак. Формула — Такие сообщения слишком непонятны. А что делать дальше? Какая проблема? Почему не получилось авторизоваться? Почему загрузка не удалась? *Куча вопросов,* ни одного ответа.

Как будто робот написал. Хорошо, если сообщение донесло до пользователя, что за проблема случилась и как её решить. И хорошо, если редактор при написании такого сообщения обошелся без использования специальных терминов или канцеляризмов. Сейчас реальность такова, что от взаимодействия с интерфейсом ждешь приятных впечатлений. Нынешний пользователь, как мне кажется, начинает потихоньку воспринимать интерфейсы в качестве друга-помощника по жизни, ведь именно через них его собственная жизнь становится чуточку проще, качественней, комфортней. Короче не ждут от интерфейса и текстов в интерфейсы, в т.ч. от текстов об ошибках, сухости, безэмоциональности.
Панибратский тон. Сообщение об ошибке в первую очередь должно быть информативным и полезным. Во вторую – быть забавным или остроумным, если того требует ToV продукта или бренда. Если из-за желания выделиться страдает качество, нужно серьезно призадуматься, правильная ли стратегия выбрана. Плюс из-за слишком оригинальных формулировок можно ударить в грязь лицом, т.к. они с меньшей вероятностью впишутся во множество контекстов.

Пункты 2 и 3 связаны, поскольку важно соблюсти баланс – текст не должен быть слишком сухим и равнодушным, но и чрезмерная эмоциональность (в особенности, если пользы мало) может навредить. Полезный текст, написанный человечным языком, – это то, что нам нужно.

Сообщение больше похоже на простыню. Исследование Американского института прессы показало, что короткие предложения понимаются пользователями лучше. Так, когда предложения состояли из 14 слов или меньше, пользователи понимали 90% сообщения. Когда предложения состояли из 8 слов или меньше, пользователи понимали все 100%. Что ж, весомый аргумент для того, чтобы не расписывать на три предложения проблему, важно емко обозначить её суть.

А как правильно?

Ошибка, возникающая при использовании ПО, не должна вводить пользователя в недоумение. Да, случилась ошибка, но! Важно, во-первых, объяснить её (конкретизировав проблему, предоставив достаточное количество информации). Во-вторых, необходимо предложить способ её решить. А лучше, конечно, вообще предотвращать ошибки, подсказывая пользователю на всем его пути (визуальными подсказками и паттернами взаимодействия). В книге «Здесь должен быть текст» М. Меттса и Э. Уэлфла пишется:

Вновь подчеркнем: главное – предвидеть проблемы и решать их до того, как они возникнут. Делая это, вы относитесь к созданию текста как к дизайну, чем оно и является на самом деле. Если вы рассматриваете свою работу как написание сообщения для конкретного поля с определенным количеством символов, то тем самым ограничиваете способы помощи своим пользователям.

Это пример хорошего сообщения об ошибке. Сообщение объясняет пользователю, что произошло и почему, предлагает способ решения проблемы, а также дает четкое указание на тот случай, если проблема не решилась. Плюс – для него характерен сочувствующий тон (пользователю это приятно).

Всегда можно обратиться к критериям, которые перечисляет в своей книге «Стратегия создания UX-текстов» Торри Подмаерски: целесообразность, лаконичность, разговорность, ясность. Я считаю, что они универсальны.

Любой UX-текст должен помогать пользователям решать их задачи и цели. А сообщения об ошибках – тем более, т.к. они появляются в критический момент и как бы разрывают путь, мешают завершить начатое дело. Необходимо смягчить потрясение пользователя от произошедшей проблемы, оставив в основном положительные эмоции от взаимодействия с интерфейсом.

Сообщение об ошибке должно быть конкретным и понятным. А еще – дружелюбным.

К кому должен обратиться UX-редактор, чтобы написать качественное сообщение об ошибке?

К разработчику, тестировщику или системному аналитику.
К дизайнеру или продакту.

Все эти ребята погружены во множество процессов единовременно и знают, какая отбивается ошибка на том или ином этапе. Они смогут показать, как написаны сообщения об ошибках и сориентировать в тот самый момент, когда редактор во имя пользы захочет некоторые из них переписать. И если первые ребята буквально в курсе всех технических сложностей, то вторые смогут подказать по консистентности, по ToV и так далее.

UX-редактору, как я успела усвоить, важно умение легко коммуницировать буквально со всеми. Чтобы получился классный текст – будь то сообщение об ошибке или пуш-уведомление, необходимо стучаться во все двери, какими бы закрытыми они не выглядели.

Универсальный совет для всех – меньше страха, больше действий.