Тексты ошибок в формах: как помочь человеку закончить заявку

Исправление одного поля бумажной формы без потери остальных данных.

Оглавление

• Сначала разберитесь, кто может исправить проблему
• Как переписать типичные сообщения
• Когда показывать ошибку
• Не потерять введённое и не соврать об отправке
• Соберите каталог ошибок, а не набор красивых фраз
• Разбор формы с несколькими зависимыми полями
• Как писать о форматах, числах и ограничениях
• Проверка при вводе: где заканчивается помощь
• Доступная ошибка — это текст вместе с поведением
• Не раскрывайте лишнее через сообщение об ошибке
• Как проверить, стало ли лучше после редакторской правки
• Небольшая проверка, которая полезнее литературной правки
• По теме

Сначала разберитесь, кто может исправить проблему

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

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

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

Как переписать типичные сообщения

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

Последний пример нельзя просто скопировать. Сначала проверьте, сохраняются ли поля. То же касается форматов и размера: текст должен отражать настоящую проверку, а не пожелание редактора.

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

Когда показывать ошибку

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

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

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

Не потерять введённое и не соврать об отправке

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

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

Различайте «запрос отправлен браузером» и «заявка получена системой». Сообщение об успехе должно соответствовать подтверждённому результату. Если сервер сохранил заявку, а отправка уведомления менеджеру задержалась, не нужно предлагать посетителю оформить её ещё раз.

Локальная подсказка рядом с ошибочным полем.

Соберите каталог ошибок, а не набор красивых фраз

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

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

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

Условный каталог для формы записи на консультацию может содержать такие строки:

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

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

Разбор формы с несколькими зависимыми полями

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

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

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

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

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

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

Как писать о форматах, числах и ограничениях

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

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

Обработка дробных чисел требует отдельного решения. Человек может ввести запятую или точку; интерфейс не должен незаметно превратить 1,5 в 15. Если система принимает только один разделитель, объясните формат. Если нормализует оба, убедитесь, что это одинаково работает на клиенте и сервере, включая вставку из таблицы.

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

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

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

Осторожнее с «умным» исправлением

Безопасная нормализация убирает лишние пробелы там, где они не несут смысла. Опасная — меняет данные по предположению. Не стоит автоматически заменять домен почты на популярный или дописывать код страны по языку браузера без ясного поведения. Подсказать возможную опечатку можно; подменить контакт незаметно — значит рискнуть отправкой не тому адресату.

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

Проверка при вводе: где заканчивается помощь

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

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

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

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

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

Конверты как иллюстрация разных состояний отправки.

Доступная ошибка — это текст вместе с поведением

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

Для вспомогательных технологий связь задаётся разметкой. Поле должно иметь доступное название, а сообщение — быть программно связано с ним; состояние ошибки не выражается только цветом. В HTML для этих задач существуют, в частности, атрибуты aria-describedby и aria-invalid. Их наличие само по себе не гарантирует удобства: требуется проверить реальное чтение и изменение состояния.

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

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

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

Не раскрывайте лишнее через сообщение об ошибке

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

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

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

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

Как проверить, стало ли лучше после редакторской правки

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

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

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

Сохраните тексты вместе с условиями их появления и тестовыми сценариями. Тогда при смене интеграции не останется прежнее «Заявка не отправлена» в ситуации, когда она уже сохранена.

Небольшая проверка, которая полезнее литературной правки

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

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

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

По теме

• Форма обратной связи: как сделать правильно
• Какие поля оставить в форме заявки — инструкция
• Как отслеживать отправку формы: пошаговая инструкция