Укр
Хьюстон, у нас проблемы, или Как показывать сообщения об ошибках

Хьюстон, у нас проблемы, или Как показывать сообщения об ошибках

  • 15 января, 2019
  • читать 2 мин

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

Любой, кто хотя бы раз использовал какие-либо программы, получил, по крайней мере, одно плохое сообщение об ошибке. Сообщения, которые ни о чем не говорили («Это не работает»); сообщения, которые не имели смысла; сообщения, которые не давали достаточной информации; сообщения о проблемах, которые оборачивались дефектом в чьей-то другой программе; сообщения о проблемах, которые оборачивались сбоями сети.

Обработка и отображение ошибок имеют огромное влияние на UX

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

Но очень часто продуктовые команды не уделяют достаточно внимания таким сценариям. Например, очень типичная история: «Что-то пошло не так. У нас проблемы, поэтому просто закройте это сообщение».

Когда в системе на любую ошибку было сообщение «Упс, что-то пошло не так» количество звонков и созданных запросов могло достигать 300-400 в день

Хорошие сообщения об ошибках в первую очередь снижают нагрузку на службу технической поддержки. Мы убедились в этом на собственном примере. Когда в системе на любую ошибку было сообщение «Упс, что-то пошло не так» количество звонков и созданных запросов могло достигать 300-400 в день. Решение проблем очень затягивалось из-за того, что пользователи не могли объяснить, что они сделали перед тем, как получить данное сообщение. После проектирования корректных сообщений об ошибках и своевременных предупреждений о том, что система может работать со сбоями, количество запросов и звонков сократилось в 10 раз и доверие пользователей к системе значительно повысилось.

Целью этой статьи является напоминание о том, что ошибки должны выводиться в системе грамотно:

  • ошибки надо показывать, никаких переадресаций;
  • необходимо использовать привязанность ошибок к их причинам или размещать их в ожидаемом месте;
  • если нет возможности использовать привязанность, то использовать цветовое кодирование;
  • избегать неуверенных ошибок типа: «У вас введен неверно либо пароль, либо логин»;
  • предотвращать ошибки путем пояснений под полем ввода.

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