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