Начните с ситуации, а не с красной рамки
Представим мастерскую с формой из трёх полей: имя, телефон и комментарий. Посетитель пишет, что у него перестала работать стиральная машина, оставляет номер и отправляет заявку. Красное «Ошибка» не помогает ему понять, какое действие требуется.
Для этой формы спроектируем три отдельных ответа: нужно исправить поле, пока нет подтверждения отправки, заявка принята. Это пример интерфейса, а не отчёт о реальной мастерской. Тексты ниже нужно согласовать с фактической работой вашего сервиса.
- Ошибка поля, до: «Неверные данные».
- Ошибка поля, после: «Телефон заполнен не полностью. Проверьте, все ли цифры вы указали». Такой текст подходит, когда проверка действительно выявила неполный номер.
- Нет подтверждения, до: «Ошибка отправки» без объяснения статуса.
- Нет подтверждения, после: «Пока не можем подтвердить запись. Позвоните в мастерскую и уточните, поступила ли заявка». Это вариант для мастерской, которая действительно проверяет записи по телефону.
- Подтверждённый успех, до: одна зелёная галочка без пояснения.
- Подтверждённый успех, после: «Заявка принята. Мастер свяжется с вами по указанному телефону». Такое обещание подходит сервису с обратным звонком.
Хорошее сообщение отвечает на два вопроса: что произошло и что человек может сделать сейчас.
Назовите поле и объясните, что исправить
Сравните «Неверные данные» и «Поле телефона осталось пустым. Укажите номер для связи». Во втором варианте понятно и место ошибки, и способ исправления. Разместите сообщение рядом с телефоном, а не только в уведомлении в углу экрана.
Для неполного телефона подойдёт другой текст: «Телефон заполнен не полностью. Проверьте, все ли цифры вы указали». Если форма действительно требует конкретный формат, дополните его допустимым примером. Но нельзя требовать запись «+7 900 123-45-67», когда проверка принимает другие способы ввода: сначала выясните реальные правила у разработчика.
Если ошибок несколько, можно вывести их список перед формой со ссылками на соответствующие поля. Попросите разработчика настроить переход к первому ошибочному полю после отправки. Технически это называется переводом фокуса: поле становится активным для ввода с клавиатуры. А правильно заполненные имя и комментарий в нашем примере оставим на месте: посетитель уже потратил время на описание поломки.
Покажите требования до ошибки
Подпишем поле «Телефон для связи», отметим, что оно обязательное, и рядом покажем допустимый пример. Если мастерская обслуживает только определённый город или перезванивает в конкретные часы, место для этих условий тоже стоит предусмотреть до отправки. Указывайте только действующие ограничения, а не случайные обещания.
Не прячьте всю инструкцию в сером примере внутри поля: при вводе он обычно исчезает. Оставьте видимую подпись. Разработчику также нужно связать подпись и подсказку с полем в коде. Это помогает программе экранного доступа, которая озвучивает интерфейс людям с нарушениями зрения, прочитать назначение поля и инструкцию. Одного удачного текста для этого недостаточно.
Не называйте неизвестный результат успехом
Для нашего примера отдельно предусмотрим состояние, когда интерфейс ещё не получил подтверждение записи. Не будем ни обещать «Заявка принята», ни обвинять человека в неправильном телефоне. Подходящий текст: «Пока не можем подтвердить запись». Дальше нужен путь, который действительно есть у сервиса.
Например, если мастерская проверяет записи по телефону, можно добавить: «Позвоните нам и уточните, поступила ли заявка». Если доступна проверка статуса на сайте, покажите её. Предлагать повторную отправку или ожидание следует по предусмотренному сценарию обработки, а не по универсальному шаблону. Фразу «Ваши данные сохранены» используйте только после проверки, что они действительно сохранены.
Подтвердите успех понятным сообщением
После подтверждённой записи в нашем примере напишем: «Заявка принята. Мастер свяжется с вами по указанному телефону». Последнее предложение подходит, только если мастерская действительно перезванивает. Номер заявки можно добавить, если он существует и пригодится для проверки статуса.
Галочка и цвет могут дополнять этот ответ. Проверьте, что посетитель понимает результат и без них. Если сообщение появляется без перезагрузки страницы, разработчику нужно обеспечить его объявление для программы экранного доступа: например, через специальную область уведомлений. Это требуется проверить в работающем интерфейсе, а не считать выполненным после замены текста.
Пройдите форму три раза
Сначала оставьте обязательный телефон пустым. Видно ли, где ошибка и что исправить? Сохранился ли комментарий? Удобно ли перейти к телефону с клавиатуры? Так вы проверите конкретный путь вместо абстрактного «форма работает».
Затем вместе с разработчиком воспроизведите предусмотренный сценарий без подтверждения. Соответствует ли сообщение реальному состоянию, работает ли предложенный способ уточнения? Наконец, отправьте корректные данные и проверьте подтверждение, в том числе программой экранного доступа.
Полезно попросить человека, который не участвовал в разработке, пройти эти шаги и объяснить, что сейчас с заявкой. Если ему приходится гадать, вернитесь к тексту или поведению формы. Это практическая проверка понятности, а не обещание определённого роста продаж.
Что стоит запомнить
- Укажите конкретное поле и способ исправления вместо общего «Ошибка».
- Согласуйте подсказки, форматы и обещания с реальной работой сервиса.
- Различайте неподтверждённую отправку и принятую заявку.
- Проверяйте сообщения вместе с поведением формы, клавиатурой и программой экранного доступа.
Материалы и первоисточники
Подготовлено с помощью ИИ на основе открытых источников. Примеры поясняют подход и не являются подтверждёнными результатами клиентских проектов.

