Проектирование форм и мастеров: типичные ошибки и решения

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

Сначала решите, нужна ли форма из нескольких шагов

Мастер разбивает длинный сценарий на последовательность экранов. Это полезно, когда данные естественно делятся на группы: например, контакты, параметры заказа, подтверждение. Но несколько шагов сами по себе не делают сценарий проще: каждый переход добавляет действие и риск потерять контекст.

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

Ошибки, из-за которых форму бросают

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

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

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

Правила становятся известны после ошибки

Сообщение «Неверное значение» не помогает исправить поле. Скажите, что именно нужно изменить: например, «Введите адрес электронной почты в формате name@example.com». Показывайте ограничение до отправки, если оно влияет на ввод: допустимый формат даты, число символов или перечень вариантов.

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

Проверка только на клиенте создаёт ложное ощущение надёжности

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

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

Мастер теряет введённые данные при переходах

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

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

Как спроектировать мастер без лишних переходов

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

1. Сгруппируйте поля по смыслу. Разделяйте данные, относящиеся к разным решениям, а не просто добивайтесь одинакового числа полей на экране. Проверка: пользователь может назвать тему шага до того, как начнёт заполнять его.
2. Покажите положение в сценарии. Укажите текущий этап и, если количество шагов действительно известно, общее число этапов. Проверка: человек понимает, сколько ещё действий предстоит; не обещайте точную длительность, если она зависит от ответов.
3. Сохраните ответы при переходе назад. Не заставляйте повторно вводить уже заполненное. Проверка: пройдите мастер до середины, вернитесь на первый экран и убедитесь, что значения на месте.
4. Сделайте следующий шаг явным. Кнопка должна описывать действие: «Продолжить» подходит для промежуточного перехода, «Отправить заявку» — для финальной отправки. Проверка: не возникает сомнений, будет ли нажатие сохранять черновик или отправлять данные.
5. Покажите итог перед необратимым действием. Для заказа, заявки или бронирования выведите ключевые данные и дайте способ вернуться к их исправлению. Проверка: на итоговом экране можно заметить и поправить ошибку до отправки.

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

Что проверить перед запуском

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

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

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

Термин: прогрессивное раскрытие

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

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

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

Смежная тема — проектирование хранения персональных данных: здесь рассматривается только поведение интерфейса формы.