Форма не отправляется: как показать ошибку пользователю

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

Разберём предлагаемый сценарий доработки формы обращения в личном кабинете. Учебные поля и ошибки вымышлены, реальных заявок отправлять не нужно. Цель проверки — человек понимает причину отказа, находит нужный участок и может продолжить без повторного набора всей задачи. Это отдельный вопрос от доставки уже принятого обращения в CRM или почту.

Одна кнопка, три разных результата

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

Теперь другой пример: поля соответствуют требованиям, но обработчик временно не отвечает. Исправление контакта здесь ничего не решит. Нужна другая обратная связь и понятный способ продолжения. Нельзя показывать замечания к заполнению только потому, что приложение получило любой неуспешный результат. Технический отказ и ошибка значения имеют разные основания.

Третий вариант — запрос выполняется. Пока результат неизвестен, не показывайте окончательный успех или требование заполнить поле заново. Человек должен видеть, что действие ещё не завершено. При этом ожидание не может длиться бесконечно без объяснения. Условия завершения и повторной попытки согласуются с устройством конкретного приложения.

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

Сообщение называет предмет ошибки

W3C в разъяснении критерия Error Identification указывает: автоматически обнаруженная ошибка ввода должна быть определена и описана текстом. Только повторно показать форму без указания причины недостаточно. Это не требует единственного универсального расположения сообщения; решение зависит от интерфейса и проверяется целиком.

Для учебной формы сравните «некорректные данные» и «укажите контакт для ответа». Во втором случае понятен предмет, даже если человек не видит цветовое выделение. Но и такая подсказка должна соответствовать реальному правилу. Если разрешено несколько способов связи, не требуйте телефон в тексте ошибки поля, которое допускает другой согласованный вариант.

Не используйте внутренние названия свойств вместо подписей. Человек выбирал «Контакт», а программа сообщает про contact_value: связь приходится угадывать. Для переведённого интерфейса проверьте язык сообщения. Понятность ошибки нельзя принимать только по тому, что разработчик сумел прочитать код в консоли.

Сводка и сообщение возле поля решают разные задачи

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

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

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

Исправленный ввод не должен исчезать

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

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

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

Ответ сервера связывается с актуальной формой

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

В тесте используйте две учебные версии контакта: первую отправьте на проверку, затем измените на вторую до ответа. Нужен понятный результат без потери нового ввода и без ложного подтверждения старого. Конкретный способ реализации выбирает разработчик. Заказчик проверяет наблюдаемое: к чему относится сообщение и какое действие требуется теперь.

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

Как проверить до публикации

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

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

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

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

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