Как писать сообщения об ошибках в формах

Человек вводит почту, переходит к следующему полю и получает полезную подсказку. Другой видит почти тот же текст ещё во время ввода и не понимает, что сделал неправильно. Слова могут совпадать. Ощущения — нет.

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

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

Что реальные пользователи говорят о проверке

В январском отчёте Эдварда Скотта за 2024 год о тестировании встроенной проверки Baymard участница L.L.Bean пропустила знак @ в адресе. Сообщение появилось после перехода к следующему полю; она исправила адрес за секунды. В Etsy участник получил ошибку, едва войдя в нетронутое поле адреса, и воспринял это как выговор до ответа. REI дал другой пример восстановления: ошибка кода безопасности карты исчезла после добавления третьей цифры.

Эти исторические наблюдения показывают неполноту формулировки «использует встроенную проверку». Момент появления и исчезновения сообщения бывает так же важен, как текст.

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

Полезный контрпример — исследование регистрационных форм Люка Вроблевски и Etre 2009 года. Двадцать два участника попробовали шесть вариантов. По опубликованным результатам лучший вариант со встроенной проверкой относительно контрольного увеличил успешность на 22% и сократил время заполнения на 42%. Один участник выразил мысль: «Лучше узнавать об ошибках по ходу дела». Но зелёные галочки у привычных ответов тоже вызывали сомнения: что именно система проверила?

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

Почему GOV.UK выбирает другой момент

Паттерн проверки GOV.UK советует ждать попытки продолжить или отправить, не проверять при выходе из поля. Он также рекомендует сохранять ответы, ставить сводку ошибок наверху, переводить туда фокус и указывать ошибки у полей. Более раннему срабатыванию нужны подтверждающие исследования.

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

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

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

Запишите, какое поле каким событием проверяется. Иначе «у нас встроенная проверка» скрывает три поведения, реализованные тремя людьми.

Пишите исправление, которое система вправе предложить

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

В вымышленной форме мастер-класса пустое поле может сказать: «Введите почту для подтверждения бронирования». Если нет @: «Введите адрес электронной почты со знаком @». Оба описывают наблюдаемое; ни один не доказывает существование ящика или его принадлежность. Для этого нужна отдельная верификация.

Хочется написать чрезвычайно точное сообщение для каждой опечатки. Я бы избегал этого, если логика не различает их надёжно. Сообщение об ошибке домена бесполезно при незнакомом, но настоящем домене. При неопределённости необязательный совет лучше жёсткого отказа. Различие нужно согласовать до утверждения текста.

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

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

Сделайте длинную форму проходимой после ошибки

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

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

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

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

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

Сообщение должно меняться вместе с фактами

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

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

Я запросил бы при передаче ещё три состояния: проверяется, принято для этого шага и проверить невозможно. «Проверяем наличие…» не равно «Два места доступны», а ни одно не подтверждает бронирование. Различия сохраняют честность при задержках и продаже последних мест между проверками.

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

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

Сбой сервиса — не неправильно заполненный вопрос

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

Возьмём тайм-аут после «Забронировать». Запрос мог не дойти, а мог выполниться с потерянным ответом. Не зная этого, «Бронирование не удалось» слишком уверенно. Немедленный повтор бывает безвреден или создаёт дубликат. Продукту нужно явное решение относительно неопределённости.

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

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

Хорошая проверка формы включает путь восстановления

Поддерживаемый HTML-предпросмотр OpenDesign помогает сравнить обычное поле, ошибку и исправленный вариант. Используйте реалистичные значения и длинный текст, узкое окно и комментарий к конкретному элементу. Затем проверьте ту же последовательность с настоящим бэкендом, клавиатурой и объявлениями экранного диктора.

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

Наблюдайте действия после коррекции не менее внимательно, чем высказывания. Повторное чтение предупреждения может означать, что оно не исчезло. Изменение верной почты после тайм-аута — что интерфейс обвиняет не тот ответ. Полный перезапуск формы — что выход найти сложнее исходной задачи.

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

Перед одобрением я прошёл бы короткую последовательность:

1. Ввести неполный ответ и увидеть момент появления сообщения.
2. Отправить с двумя ошибками и дойти до обоих полей из сводки.
3. Исправить один ответ и подтвердить сохранность остальных.
4. Изменить зависимый ответ, например дату, и проверить новый результат.
5. Встретить недоступность сервиса и пройти путь восстановления.

Последняя проверка — успех. Подтверждение показывает исправленные дату и количество? Человек понимает, существует ли бронь? Исчезновение красного текста само по себе не означает восстановления.

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