Рекомендации по интерфейсу форм

Проектирование форм может оказаться настоящей проблемой. Чтобы получилось что-то стоящее и удобное для пользователей необходимо принять во внимание кучу разных рекомендаций и правил. В данной статье я постарался составить полезный список таких рекомендаций. Для его составления я использовал свой опыт и статьи экспертов.

Основные рекомендации и ввод данных

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

Группировка, табы и многостраничные формы

• Размещайте похожие поля рядом.
• Группируйте поля так, чтобы пользователю приходилось переключать раскладку поменьше.
• Используйте подходящую группировку полей для организации содержимого формы.
• Используйте минимальное количество визуальных элементов, необходимые для выделения формы.
• Если форму можно легко разбить на несколько коротких форм, то используйте одну страницу для нее.
• Если форма содержит большое число вопросов, связанных с несколькими темами – используете несколько страниц.
• Если форма содержит большое число вопросов по одной теме – используйте длинную страницу.
• Для мастеров обеспечьте возможность возврата к предыдущим шагам.
• В мастерах избегайте вложенных шагов, делайте их последовательными.

Поля

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

Подписи

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

• Избегайте многострочных подписей к полям.
• Подписи должны четко отражать ожидаемые данные.
• Старайтесь не помещать на форму необязательные поля, может их вообще не стоит заполнять пользователю.
• Если большинство полей обязательны для заполнения — выделите необязательные.
• Если большинство полей необязательные — выделите обязательные.
• Лучше выделять обязательные поля текстом, но * или выделение шрифтом/цветом тоже подойдет.
• Название формы должно соответствовать задачам формы.
• Сведите к минимуму подсказки и советы необходимые для заполнения формы.
• Помощь должна быть контекстной – находится возле нужного поля и быть полезной.
• Когда запрашиваете много незнакомых для пользователя данных — используйте динамическую систему помощи, всплывающие подсказки, например.
• Используйте выравнивание и объединение в группы для показа того, как связаны между собой данные.

Рекомендации по валидации и подсказкам

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

Рекомендации по чекбоксам и радио-кнопкам

• Флажок и радио-кнопка всегда располагаются слева от подписи.
• Кастомный дизайн элементов должен быть максимально близок к стандартному представлению.
• Располагайте списки вертикально, с одним вариантом на строке.
• Если несколько флажков или радио-кнопок расположено друг под другом, то между ними должно быть одинаковое расстояние.
• Если нужно использовать их горизонтально, с несколькими вариантами на строке, сделайте достаточно места между ними элементом и подписью, четко выделяя какая надпись куда относится. .
• Используйте позитивные формулировки для подписей чекбоксов, так, чтобы ясно понятно, что произойдет, когда пользователь выберет его.
• Пишете подписи так, чтобы пользователи могли понять, что будет если они его выберут, и что будет, если они оставят его пустым.
• Если вы не можете так сделать, то лучше сделать две радио кнопки, одну для включения возможности, а вторую — для отключения, и написать ясные подписи для каждого случая.
• Если возможно, используйте радио кнопки вместо коротких выпадающих списков.
• Всегда ставьте вариант по умолчанию для всех списков радио кнопок.
• Так как радио кнопки позволяют выбрать только один вариант, убедитесь, что оба варианта не противоречат друг другу, явно отличаются друг от друга.
• Убедитесь, что радио-кнопки полностью покрывают необходимую сферу данных, если нет, добавьте вариант «другое» и текстовое поле для ввода своего варианта. Это относится и к выпадающим спискам.
• Позвольте пользователям выбирать опцию кликая не только по чекбоксу/кнопке, но еще и по их подписи: на цель большого размера легче кликнуть, в соотвствии с законом Фиттса. В HTML формах, вы можете легко это достичь, просто окружив каждую надпись тегом label.
• Используйте чекбоксы и радиокнопки только для смены состояниея, а не как кнопку действия или отправки формы.

Выпадающие списки

• Если вариантов в списке больше чем 2-3, то их следует отсортировать по алфавиту, это убыстрит поиск нужного элемента.
• Если предполагается вариант «Другое», то он должен быть в конце.
• Если вариантов достаточно много, но они разбиваются на группы по смыслу, то это стоит сделать.
• Если список длинный, но есть группа наиболее популярных значений (около 5-7 шт.), их можно перетащить вверх списка.
• Если список ооочень длинный, то нужно использовать автокомплит.
• Если в выпадающем списке только варианты да/нет, то заменяем его на флажок.
• Если количество значений в выпадающем списке всегда постоянно, и оно меньше 4-5, то такой список разворачивается в горизонтальную группу радио-кнопок.

Рекомендации по кнопкам «Отмена» и «Очистить»

• Кнопка «Отмена» в хороших интерфейсах не требуется вовсе, т.к. используются другие механизмы навигации – кнопка назад в браузере, хлебные крошки и меню.
• Кнопку отмены желательно заменять ссылкой, подчеркивая её второстепенность.
• Кнопку очистить тоже стоит делать ссылкой. Размещать её стоить только в нужных для этого местах, к примеру в фильтрах и поисках.
• Самая главная проблема заключается в том, что пользователи часто по ошибке нажимают кнопку Reset вместо кнопки Submit. Одно нажатие — и вся кропотливая работа исчезла.
• Наличие двух кнопок в конце формы вносит неразбериху в интерфейс, и для пользователя затруднительно четко определить свой следующий шаг. Некоторое время зря тратится на рассматривание этой бесполезной кнопки, чтобы разобраться, какую же из двух кнопок надо нажимать.
• Даже если пользователь действительно желает удалить некоторые данные, которые он ввел в форму, наличие выделенной кнопки для выполнения этой функции может только замедлить его работу, так как перед ни возникают два выбора:
  
  • отредактировать поля, содержащие неверные данные, заменив старый текст на новый.
  • нажать кнопку Reset и набрать новый текст во все девственно чистые поля формы.

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