Формы и мастера: чек-лист перед запуском в продакшен

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

Сначала определите, что именно проверяете

Этот чек-лист рассчитан на веб-формы и мастера в браузере, независимо от фреймворка. Для требований доступности ориентир — WCAG 2.2; конкретный способ реализации зависит от используемых HTML-элементов и компонентов. Здесь не разбираются выбор библиотеки и написание обработчиков.

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

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

Чек-лист: поля и ввод

Понятно ли, что вводить

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

Можно ли исправить ошибку

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

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

Если форма многошаговая

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

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

Хорошая форма не только принимает правильный ответ. Она помогает исправить неправильный, не заставляя начинать заново.

Решения, которые меняют цену ошибки

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

Доступность и поведение при сбоях

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

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

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

Что ломается после релиза

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

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

Что сделать дальше

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