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