Ошибки в формах: валидация и сообщения, которые помогают исправить ввод

Человек заполняет форму заявки, нажимает «Отправить» и видит «Что-то пошло не так». Поля остались на месте, но непонятно, что исправлять и ушла ли заявка. В таком сценарии проблема находится не только в тексте сообщения: команда не определила, как интерфейс помогает завершить действие после неудачи.

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

Начните с правил, которые действительно нужны

Для каждого поля запишите, зачем продукту значение, обязательно ли оно и что система может принять. Для учебной формы договоримся: имя обязательно, почта нужна для ответа, описание задачи необязательно и ограничено 1000 символами. Лимит выбран для примера; в рабочем продукте его следует обосновать способом обработки заявки.

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

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

Подсказка должна появиться до ошибки

Подпись объясняет назначение поля, подсказка — условие, которое важно знать заранее. Для описания задачи можно сразу указать «Необязательно, до 1000 символов». Для почты — объяснить, что на неё придёт ответ. Не заменяйте подпись плейсхолдером: когда значение введено, человеку всё ещё нужно понимать, что находится в поле.

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

Выберите момент проверки

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

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

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

Напишите сообщение, по которому можно действовать

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

В объяснении критерия WCAG 3.3.1 требуется обозначить обнаруженную ошибку ввода и описать её текстом. Одной цветной рамки недостаточно. Отдельный критерий 3.3.3 касается известного способа исправления, если такая подсказка не нарушает безопасность или назначение содержимого.

Не обвиняйте человека и не показывайте ему внутренний код вместо объяснения. Фраза «Вы неправильно ввели данные» не помогает найти проблему. Если команда хочет сохранить код для поддержки, он может сопровождать понятное сообщение, но не заменять его. И не предлагайте исправление, которое система на самом деле не принимает.

Свяжите общий список и ошибки у полей

У короткой формы человек может заметить сообщение рядом с полем. У длинной формы проблемное место иногда находится за пределами экрана. Нужно продумать, как после отправки пользователь узнает о неудаче, увидит количество проблем и перейдёт к каждой из них. В учебном варианте над формой появляется блок «Проверьте два поля» со ссылками на имя и почту.

Компонент Error summary в GOV.UK сочетает общий список с локальными сообщениями и переводом фокуса на сводку. Это конкретный способ организации формы, а не единственная допустимая реализация WCAG. Если команда использует такой подход, формулировка в списке и у соответствующего поля должна совпадать.

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

Сохраните введённые данные

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

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

Отделите ошибку ввода от сбоя отправки

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

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

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

Проверьте путь исправления и передайте правила

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

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

Перед разработкой приложите таблицу правил, тексты сообщений, начальное состояние, ошибку у поля, общую сводку, отправку и успех. Укажите сохранение данных и поведение фокуса. Практический порядок передачи описан в чек-листе подготовки Figma к разработке. Затем повторите сценарии уже в работающей форме: именно реализация показывает, получилось ли исправить ошибку и завершить задачу.