Способы создания эффективных форм для заполнения — от структуры до кнопок

Советы по проектированию от разработчика интерфейсов Ника Бабича.

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

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

У обычной формы есть пять компонентов:

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

Дополнительные компоненты форм:

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

Эта статья охватывает множество аспектов, которые относятся к структуре, полям ввода, текстовому содержимому ячеек, командным кнопкам и валидации.

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

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

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

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

Основная проблема организации полей формы в несколько колонок заключается в том, что скорее всего пользователи будут перемещаться по ней непоследовательно. Если колонки будут распределены по горизонтали, то пользователю придется просматривать форму зигзагообразно. Это может замедлить скорость восприятия и создать трудности во время заполнения формы. Но если в форме будет только одна колонка, то путь заполнения будет строго вертикальным, вниз по странице.

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

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

Но и перегибать палку не стоит: никому не понравится, если форма, состоящая из трех полей, вдруг превратится в допрос из 30 полей. Как правило, за один раз выводится от пяти до семи полей.

Старайтесь не включать необязательные поля в форму. Но если вы их используете, то по крайней мере отчетливо выделяйте, какие поля нельзя оставить незаполненными. Традиционно символ (*) используется для обязательных полей, а слово «необязательно» — для необязательных полей (лучше придерживаться этой практики в больших формах со множеством обязательных полей).

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

Избегайте значений по умолчанию, если только не считаете, что большая часть ваших пользователей (например, 90%) выберут это значение. Особенно избегайте этого для обязательных полей. Почему? Потому что скорее всего так вы будете поощрять ошибки.

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

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

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

В примере ниже скобки, пробелы и тире появляются автоматически — по мере ввода номера телефона и карты. Эта простая техника экономит время и усилия на ввод числовых данных.

У пользователей должна быть возможность переходить по полям и редактировать их с помощью одной клавиатуры. Пользователи, которые привыкли работать с клавиатурой, должны иметь возможность перемещаться по полям и редактировать их с помощью клавиши Tab. Подробные требования к взаимодействию с клавиатурой можно найти в руководстве W3C (World Wide Web Consortium) по шаблонам дизайна.

Автофокус на поле показывает пользователю, где начало ввода, и позволяет быстро начать заполнять форму. Должен быть четкий визуальный сигнал о том, что фокус сдвинулся. Это может быть изменение цвета, изменение яркости поля, сверкающая стрелка — всё что угодно.

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

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

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

Ясная подпись — один из основных способов сделать UI более доступным. Хорошая подпись объясняет пользователю, зачем существует каждое поле, полезна непосредственно во время работы с этим полем и остаётся видимой даже после того, как поле заполнено.

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

Предыдущие версии подписи регистрационной формы Amazon состояли из большого количества слов, из-за чего форма заполнялась очень медленно. Текущая версия гораздо лучше, а подписи короче.

В большинстве цифровых продуктов сегодня используется два способа капитализации начальных букв в словах:

• Капитализация начальных букв всех слов в предложении (Title case) — с большой буквы пишется каждое слово. «Это Пример Title Case».
• Капитализация начальной буквы первого слова в предложении (Sentence case) — с большой буквы пишется только первое слово. «Это пример sentence case».

Капитализация начальной буквы первого слова читается немного проще (а значит, и быстрее). Если подписи короткие, то разницей можно пренебречь («Полное Имя» и «Полное имя»), а если подпись длинная, то капитализация начальной буквы первого слова в предложении — предпочтительнее.

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

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

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

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

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

Главное преимущество подписей, выравненных по правому краю, — сильная визуальная связь между текстом и полем ввода. Предметы, расположенные рядом друг с другом, кажутся нам связанными. Этот принцип совсем не новый и происходит из закона близости в гештальт-психологии.

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

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

Если подпись расположена внутри поля ввода как замещающий текст, то она будет исчезать каждый раз, когда пользователь начинает заполнять поле, то есть с этого момента он её больше не увидит. Эти встроенные подписи хорошо работают, если форма состоит из двух полей (простая форма авторизации с полями имени пользователя и пароля), однако когда от пользователя требуется больше информации, то этот вариант не так хорош, как подпись, которую видно всегда.

Как только пользователь кликнет по полю ввода, подпись исчезнет, так что ему не удастся перепроверить, то ли он написал. Это увеличивает вероятность совершить ошибку. Еще одна проблема заключается в том, что пользователи могут принять встроенную подпись за предзаполненные данные и, следовательно, проигнорировать это поле (это подтверждается исследованием Nielsen Norman Group, в котором отслеживалось движение глаз пользователя).

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

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

Если нажать на командную кнопку, то должен запуститься какой-то процесс, например, отправка формы.

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

Для сложных форм часто требуется кнопка «назад». Если она расположена сразу под полем ввода (как в примере слева ниже), пользователь может случайно на нее нажать. Так как кнопка «назад» — это второстепенное действие, сделайте так, чтобы доступ к ней был более сложным (на форме справа кнопки расположены верно).

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

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

Не используйте кнопку «Сбросить». Она почти никогда не помогает пользователям, а, наоборот, приносит одни проблемы. Интернет стал был гораздо лучше, если бы везде удалили кнопки «Сбросить».

Кнопки должны выглядеть как кнопки: покажите, что по ним можно кликнуть или тапнуть.

Оформите кнопку «Отправить» так, чтобы после нажатия на неё было четко понятно, что форма обрабатывается. Таким образом он получает обратную связь и понимает, что не надо отправлять форму второй раз.

Ошибки валидации формы неизбежны, и это естественная часть ввода данных (потому что пользователи склонны совершать ошибки). Да, конечно, нужно минимизировать вероятность возникновения ошибки, но ошибки валидации никогда не исчезнут. Так что главный вопрос звучит так: «Что вы можете сделать, чтобы пользователю было проще исправить ошибки?».

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

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

Однако не стоит делать так, чтобы валидировалось каждое нажатие клавиш, потому что чаще всего вы не можете проверить правильность данных, пока пользователь не закончит печатать ответ. Формы, которые валидируют данные во время набора текста, «наказывают» пользователя, как только он начинает вводить данные.

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

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

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

Джеф Раскин однажды сказал: «Система должна относиться к тексту, введенному пользователем, как к неприкосновенному». Это абсолютно истинно и для форм. Очень здорово, когда вы начинаете заполнять форму, а затем случайно обновляете страницу, но данные остаются на своем месте.

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

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

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

Каждый интерфейс — это диалог. Традиционные формы (те, которые мы создаем каждый день) очень похожи на разговор. Единственная разница — то, как мы отвечаем на вопросы. Но что если бы создаваемые нами формы задавали вопросы в таком формате, который больше бы напоминал настоящий человеческий (не машинный) разговор?

Форма, которая показана ниже, создает диалоговый контекст, который способствует пониманию, но в то же время не опирается на традиционные элементы онлайн-форм (такие как подписи и поля ввода).

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

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

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

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

#Интерфейсы