Как спроектировать форму заявки на лендинге

Определите, что произойдёт после отправки

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

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

Составьте паспорт полей

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

Разведите клиентскую и серверную проверку

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

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

Продумайте состояния формы

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

Блокировка кнопки в браузере не решает все дубли. Запрос мог сохраниться, а ответ потеряться в сети. Для важных операций нужен согласованный механизм идемпотентности или другой способ распознавания повтора на сервере. Конкретное решение зависит от архитектуры, но риск следует описать в задании заранее.

Учебный пример ошибки интеграции

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

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

Проверьте удобство и данные

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

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

Протокол перед выпуском

• Успешное обращение найдено ответственным сотрудником.
• Ошибочный ввод не создаёт запись и объясняет исправление.
• Повторное нажатие и потеря ответа разобраны отдельно.
• Сбой уведомления не маскируется под успешную доставку.
• Аналитическое событие соответствует согласованному результату.
• Тексты формы описывают реальные условия связи.

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

Карточка проверки одного обращения

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

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

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

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

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

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

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