← Все статьи

Интерфейсы и скорость

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

Выбираем нужные поля, формулируем ошибки и проверяем путь от ввода до подтверждения.

Форма — последняя часть обещания страницы

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

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

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

Как выбирать поля и подписи

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

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

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

Поля → Проверка → Отправка → Подтверждение
Схема ZEVY. Поля → Проверка → Отправка → Подтверждение.

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

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

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

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

Разбор формы для расчёта сайта

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

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

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

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

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

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

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

Как описать задачу на доработку

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

Три фразы для одного поля

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