«Опаньки»: что должно быть на странице ошибки на сайте Статьи редакции

Объяснить, из-за чего возникла проблема, проинструктировать, добавить теплые слова — перевод материала контент-дизайнера Рианнон Джонс.

Иногда дизайнеры развлекаются при создании сообщения об ошибке. Посмотрите на «Опаньки...» или «Он мёртв, Джим» в Google Chrome, на страницу ошибки 404 на GitHub.

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

В 2017 году я устроилась в Deliveroo, здесь сообщениям об ошибке почти не уделяли внимания. В своё время ими занималось много разных сотрудников: инженеры, дизайнеры по продукту.

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

Такое случается часто. Видела подобное почти в каждом продукте, с которым работала.

Наша команда по дизайну контента решила создать понятный, удобный, уместный и последовательный пользовательский опыт. Мы хотели быть уверенны в том, что если продукт падает, то он падает красиво.

Поэтому мы переписали каждое сообщение об ошибке в продукте для покупателей. Вот как мы это сделали.

На этом этапе нужно работать с электронными таблицами, скриншотами и цветомаркировкой.

Реакция пользователя зависит от того, правильно ли выбран тон сообщения об ошибке. Хороший показатель — потраченное на решение задачи время. Пользователь только открыл приложение или уже выбрал, что заказать, ввёл данные карточки и адрес доставки? Он может исправить свою проблему? Насколько она повлияет на опыт?

Помня об этом, мы составили список ошибок и распределили их по категориям:

• Системная ошибка. Возникающая на стороне системы. Сюда относятся системный сбой, сообщение о том, что товар распродан, отклонение заказа.
• Пользовательская ошибка. Возникает из-за действий пользователя. Например, если ввёл неправильный номер банковской карты, некорректный адрес доставки.

Затем ошибки делятся на:

• Частичные. Ошибка, которая не остановит пользователя от совершения действия. Например, пользователь хочет заказать еду из ресторана, но узнал, что он закрыт. Однако пользователь всё равно может заказать еду, но из другого ресторана.
• Полная. Ошибка, которая не даст пользователю завершить действие. Это ошибки сервера (с кодом 500) или серьёзные сбои.

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

Пройти этот этап — это выполнить 80% работы.

Самый простой способ — показать все ошибки на графике. Одна ось описывает тип ошибки: частичная, полная, системная или пользовательская. Вторая ось описывать степень влияния ошибки на опыт пользователя.

Мы сделали три уровня тяжести: «раздражает», «злит», «полный кошмар».

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

• Объяснить.
• Добавить теплоты.

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

• Объяснить.
• Проинструктировать.

Расскажите, из-за чего возникла проблема. Дайте инструкцию по её решению.

• Извиниться.
• Решить проблему.

Если необходимо — извинитесь. Если ошибка конкретная, упомяните её в извинении. Дайте понять, что работаете над решением проблемы.

Если пользоваться похожей схемой, то процесс написания сообщений об ошибках пройдёт быстрее.

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