Человек заполнил форму, нажал кнопку и увидел «Произошла ошибка». Что именно не так, отправилось ли обращение и нужно ли повторять — неизвестно. Даже короткая форма в такой момент превращается в неприятную задачу.
Хорошая обработка ошибки помогает восстановить действие. Она не должна заставлять пользователя разбираться во внутреннем устройстве системы или повторно вводить всё без необходимости.
Различайте причины
Незаполненное обязательное поле, неверный формат и временный сбой отправки требуют разных сообщений. Если проблема в конкретном поле, покажите, где она находится и как её исправить.
Если причина не установлена, не обвиняйте пользователя. Сообщение «Вы ввели неверные данные» не подходит для ситуации, когда недоступен сервер. Текст должен соответствовать тому, что система действительно знает.
Объясняйте действие, а не код
Вместо общего «Некорректное значение» укажите ожидаемый формат понятным языком. При этом не навязывайте ограничение, которое не нужно для реальной обработки данных.
Важную подсказку лучше показать до ошибки, если требование неочевидно. Человек не должен угадывать допустимый формат методом нескольких неудачных отправок. Пример полезен, когда он поясняет правило, а не заменяет его.
Сохраняйте уже выполненную работу
После исправимой ошибки введённые данные по возможности должны оставаться в форме. Иначе система перекладывает стоимость собственного сбоя на пользователя.
Однако сохранение требует продуманного обращения с чувствительной информацией. Не стоит автоматически хранить её дольше необходимого. Конкретное техническое решение зависит от формы и требований проекта; на уровне дизайна важно заранее обсудить этот вопрос с разработкой.
Покажите состояние отправки
После нажатия кнопки человек должен понимать, что действие обрабатывается. Если запрос ещё выполняется, интерфейс не должен провоцировать многократные повторения.
При неопределённом результате особенно важно не обещать, что обращение точно не отправилось. Продумайте, как пользователь сможет проверить статус или связаться другим способом. Для критичных операций этот сценарий нужно проектировать вместе с технической логикой, а не только текстом сообщения.
Проверьте неидеальный путь
Протестируйте пустые поля, неверный формат, медленное соединение и повторное нажатие. Посмотрите, заметно ли сообщение на маленьком экране и можно ли понять проблему без различения цветов.
Не ограничивайтесь красивым состоянием успешно заполненной формы. Именно ошибки показывают, насколько интерфейс помогает человеку продолжить работу, когда всё пошло не по плану.
Хорошее сообщение не обязано подробно рассказывать о сбое. Оно должно честно описывать известное, указывать доступный следующий шаг и сохранять как можно больше уже выполненной пользователем работы.
Дизайн-система для бизнеса: когда она нужна и как не превратить ее в дорогой архив компонентов
Как принимать дизайн-решения на данных, а не на субъективном вкусе руководителя
Как проектировать интерфейсы для сложных B2B-продуктов, а не только для лендингов
UX-аудит сайта: 30 проблем, из-за которых пользователь не доходит до заявки
