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