Scott
Многошаговая форма должна помогать закончить длинную заявку, а не превращать одну задачу в четыре возможности потерять ответ. Человеку нужно понимать, на каком он этапе, можно ли вернуться назад, что уже сохранено и что осталось до отправки. Представим вымышленную команду, которая запрашивает новый дизайн-проект в четыре этапа: основные сведения, требования, необязательные детали и проверка. Мы соединим переходы в прототипе Pixso и отделим работу дизайнера от поведения, которое должен реализовать сервис.
Разделите форму по решениям, а не по числу полей
Границу этапа стоит провести там, где меняется задача человека. В нашем примере основные сведения определяют проект, требования описывают ожидаемый результат, необязательные детали добавляют материалы, а проверка позволяет перечитать заявку перед отправкой. Экран с одним полем, за которым следует экран с двадцатью несвязанными вопросами, не становится проще оттого, что в индикаторе четыре точки.
Перед началом объясните, какая информация потребуется. Указывайте примерное время только при наличии обоснованной оценки; полезнее назвать то, что стоит подготовить, например владельца проекта и краткое описание работы. Не требуйте регистрацию или файл, пока человек не понял саму задачу. Руководство W3C по многостраничным формам рекомендует группировать связанные поля, повторять общие инструкции, обозначать необязательные этапы и помогать ориентироваться на каждой странице.
До макетов зафиксируйте правила: какие ответы обязательны, какие этапы можно пропустить, когда данные сохраняются, сколько живёт черновик и может ли коллега продолжить его заполнение. Это свойства сервиса. Нарисованная шкала прогресса сама по себе ничего не сохраняет.
Покажите текущий этап и оставшуюся работу без ложной точности
При четырёх постоянных этапах «Требования — этап 2 из 4» понятнее безымянной полосы. Назовите текущий, завершённые и следующий этапы. Если необязательный этап можно пропустить, отметка «75%» может искажать объём оставшейся работы: путь зависит от выбора человека. Упорядоченный список с названиями часто яснее точного на вид процента.
Используйте одни и те же названия в заголовке, индикаторе и навигации. На экране проверки дайте перейти к завершённому этапу и исправить ответ. Если изменённое требование делает последующие вопросы ненужными, объясните, какие ответы будут удалены или проверены заново, вместо того чтобы молча их очистить. W3C также описывает возврат к пройденным этапам при условии сохранения уже введённых данных.
Не помечайте этап выполненным только потому, что его открыли. Статус «завершён» уместен, когда необходимые для перехода ответы прошли соответствующие проверки. Посещённый экран с непроверенным черновиком остаётся незавершённым. Индикатор показывает положение в процессе, а не гарантирует отправку заявки.
Сохраните ответы перед возвратом, пропуском и продолжением
Кнопка «Назад» должна вести себя предсказуемо: предыдущий этап открывается с уже введёнными значениями. Если данные сохраняются при переходе вперёд, показывайте «Сохранено» только после подтверждения от сервиса. Эта надпись не должна быть декорацией во время сетевого запроса. При автосохранении различайте состояния «Сохраняется», «Сохранено» и «Не удалось сохранить».
Пропуск необязательного этапа не должен стирать предыдущие ответы. На проверке покажите, что дополнительные сведения «Не указаны», а не выдавайте внезапную ошибку обязательного поля при отправке. В нашем примере подробное техническое задание можно добавить позже, но владелец проекта обязателен. Одно и то же правило должно действовать в интерфейсе и серверной проверке.
Если человек вернулся после разрыва сети, различайте сохранённый на сервере черновик и последнее изменение, оставшееся только на устройстве. Нельзя намекать, что офлайн-редактирование уже дошло до сервера. Восстановление после истечения срока сеанса входа — отдельная задача; здесь речь о нормальном возврате и исправлении внутри формы.
Объясните ошибку и не стирайте правильные ответы
Показывайте ошибку рядом с нужным полем и подсказывайте конкретное действие. «Укажите владельца проекта» можно исправить; «Что-то пошло не так» не помогает. Не откладывайте проблему первого этапа до итоговой проверки. Но и не прерывайте ввод предупреждением после каждого символа, прежде чем человек закончит значение.
Допустим, дата сдачи оказалась раньше даты начала проекта. Сохраните обе даты и объясните, что именно нужно изменить. Когда человек исправит дату, остальные допустимые ответы останутся на месте. Проверка в браузере ускоряет обратную связь, но итоговая отправка должна проверяться и на сервере. Руководство W3C по проверке форм подчёркивает, что клиентскую проверку можно обойти: она не заменяет серверную.
Если ошибка относится к другому этапу, с экрана проверки ведите к конкретному полю, сохраните остальные ответы и возвращайте человека к итоговому обзору после исправления. При нескольких ошибках помогает общий список. Когда сервер отклоняет значение, принятое браузером, назовите новую причину и сохраните весь черновик. Возврат к пустому первому этапу недопустим.
Разделите проверку, отправку и результат
На итоговом экране суммируйте ответы теми же словами, которыми они обозначались при вводе, и дайте редактировать каждый раздел. Для пустого необязательного раздела напишите «Не указано», не выдавая его за обязательный. Если правка раннего ответа меняет смысл заявки, обновите сводку до отправки.
Нажатие кнопки «Отправить» ещё не доказывает, что заявка создана. Во время обработки предотвратите случайную повторную отправку и покажите действительное состояние ожидания. После успеха дайте устойчивый номер заявки или страницу подтверждения и понятный следующий шаг. После ошибки сохраните заполненную форму и сообщите, был ли запрос принят. При сетевом тайм-ауте исход может быть неизвестен: прежде чем советовать повторить отправку, сервис должен проверить, не существует ли уже такая заявка.
Оценивайте не число экранов, а возможность выполнить и исправить задачу. Может ли человек назвать текущий этап, вернуться и изменить один ответ, пропустить необязательный раздел, исправить ошибку и понять, была ли итоговая заявка отправлена?
Проверьте переходы и состояния в Pixso
Разместите четыре этапа рядом в дизайн-файле Pixso. Соедините действия «Далее», «Назад», «Пропустить» и «Изменить», добавьте отдельные состояния сохранения, ошибки сохранения, ошибки поля, отправки, успеха и неизвестного исхода. На всех экранах используйте одно название проекта и одинаковые ответы: тогда будет видно, сохраняются ли данные после возврата. Один красивый сценарий без ошибок не выявит исчезнувший черновик.
Попросите коллегу пройти прототип без подсказок. Понятно ли, что уже сохранено? Можно ли исправить дату сдачи и вернуться к проверке, не набирая описание заново? Различает ли он сбой сохранения и ошибку итоговой отправки? Исправьте места, где приходится гадать, и передайте разработчикам экраны вместе с действительными правилами хранения, проверки и статуса заявки. Pixso помогает проектировать и обсуждать взаимодействие; хранение данных в рабочем сервисе нужно реализовать и проверить отдельно. Откройте Pixso и свяжите состояния формы.
