🔔 Как правильно описывать ошибки для пользователя

Екатерина Рудая, Менеджер продукта в Контур · 19.08 · ред.

🔔 Как правильно описывать ошибки для пользователя

📌 Ошибка должна быть расположена рядом с источником ошибки.

📌 Сообщение об ошибке можно показывать пользователю до того, как он закончил ввод. Если система может распознать ошибки. Например при вводе букв в числовое поле

📌 Сообщение об ошибки должно быть понятное. Как для школьника. Нашла любопытный материал по поводу удобочитаемости. Будет завтра

📌 Сообщение об ошибке должно давать определенные рекомендации для действий пользователю.

Здесь как раз вздыхают безопасники со своими best practice. И рекомендация "проверьте логин и пароль" не то.

📌 Весь пользовательский ввод должен быть сохранен. На ввод пользователя можно ссылаться в ошибке

📌 Для регулярных ошибок должен быть FAQ. Или они могут упоминаться в онбординге. Или в руководстве пользователя.

📌 Сообщение об ошибке должно возникать только после того, как пользователь отправил данные. За исключением случаев, когда система может отхватывать ошибки на фронте. Например ввод недопустимых символов в поле.

#ux #интерфейсы #немнонопродакт #дизайн

712

Март Красильников

· 19.08

Вот дроп введённых данных вообще бесит🥲

Владимир Онищук

· 19.08

Ну не знаю, все эти правила оторваны от реальной жизни, могу объяснить почему

Владимир Онищук

· 22.08

Пишут обычно, ой что-то случилось, но мы уже работаем над этим.

Владимир Онищук

· 22.08

Это кстати нормально, проблемы по трафику определяют и по логам локализуют, зато нет проблем в общении с пользователями и на это не надо тратить деньги

Дмитрий Кузнецов

· 22.08

Хех) тут недавно одна компания делала кое-что, проект на год, матерые консы, прогеры, опыт на рынке 15 лет. Сообщения об ошибках вида "Чота сломалось, проверьте там всё повнимательнее". Вот не вру!!! Ни одного джуна на проекте не было)

Владимир Онищук

· 22.08

1. Что значит рядом, есть системы логирования и есть stdout выводить в интерфейс очень круто. 2. В ui так всегда и делают или ваша команда ленивая? 3. Не понимаю как можно сделать по другому, если ошибка правильно обрабатывается или у вас джун-фронтеэндер или он очень ленив. 4. ☢️ это история про позвоните или свяжитесь с администратором системы))). Проверьте логи и пароль пишется не просто так, нельзя говорить что не правильно или систему могут использовать для чекинга логина или пароля. 5. Да это хорошо но не обязательно, для этого и существует метод patch в http-запросов, и есть системы где это необязательно или даже вредно. 6. Faq это начало 2000, должен быть нормальный cjm, чтобы не возникало никаких вопросов. 7. Ну это базовый принцип всех it-систем, чтобы получить ответ, надо отправить запрос, в том числе с ошибкой.