Дизайн эффективных форм на практике

Учимся танцевать с бубном по проверенным паттернам

Нравится ли нам заполнять формы? Да нет же, мы просто хотим купить билет, забронировать отель, совершить покупку и так далее. Желательно побыстрее. И желательно “без смс и регистраций”. Заполнение формы — неизбежное зло, с которым нам постоянно приходится иметь дело.

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

Давайте же и мы приникнемся болью и со всей эмпатией, на которую способны, выделим основные pain points, которые могут возникнуть у пользователя при работе с формами:

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

Поэтому важно помнить самый главный принцип проектирования форм:

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

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

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

Структура

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

Спрашивайте только то, что нужно

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

Сделайте порядок очевидным

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

Группируйте связанные поля

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

И это как раз тот самый случай, когда действительно уместно воспользоваться правилом 7±2 (или 5±2). Звучит оно следующим образом: “Человеку для решения задачи комфортно воспринимать определенное количество объектов. Их число равно 7±2. Если объектов становится больше, человек стремится избегать решать задачу. Либо сводит ее к более простым способам решения”.

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

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

Когда имеет смысл разбить форму на шаги

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

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

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

Один столбец vs. Несколько столбцов

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

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

Оптимальная длина полей

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

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

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

Исходя из этой рекомендации, вы можете комбинировать некоторые поля в одну строку. Но помните о Z-траектории и не перестарайтесь.

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

На примере слева поле “Zip code” короткое, и сразу становится понятно, что нужно ввести простой индекс (дизайн заточен под адреса в США, а там это 5 цифр ). В дизайне справа поле очень длинное, и пользователю непонятно: вводить простой индекс или расширенный (например, 94778–3829 или просто 94887). В данном случае дизайнер определил, что страна не будет заранее известна, поэтому выбрал универсальное длинное поле. Красавчик.

Уберите все лишнее

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

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

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

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

Любая форма включает в себя заголовки, поля с подписями и подсказками, кнопки. При успешном заполнении или о том, что что-то пошло не так, нужно сообщить, поэтому дополнительно к форме нужно спроектировать успешную отправку и валидацию с сообщениями об ошибках. Рассмотрим подробнее, о чем важно помнить в каждом компоненте.

Заголовок (title)

Форму важно назвать, не игнорируйте заголовок. В названии в 1–3 словах должна кратко фигурировать конечная цель заполнения формы. “Вход”, “Регистрация”, “Оформление заказа” и т.д.

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

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

Поля (input fields)

Это могут быть текстовые поля (text fields), поля пароля (password fields), флажки (checkboxes), радиокнопки (radio buttons), ползунки (sliders) и другие.

Минимизируйте запрос

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

Рекомендации по типографике

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

Не заливайте цветом поля. Пожалуйста. Если только у вас не промо-сайт с невероятно креативным визуальным концептом. В большинстве случайев это излишне.

Обязательное vs. Необязательное

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

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

Дефолтные состояния

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

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

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

Маски ввода информации

Снова возвращаемся к теме affordance. Дизайна справа подсказывает, в каком формате нужно ввести телефонный номер.

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

Desktop-Only: Подружите форму с клавиатурой

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

Даже самое простое поле выбора даты должно отвечать требованиям руководства W3C. Источник изображения: Salesforce

Автофокус

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

Автозаполнение

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

Метки, или подписи (lables)

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

Количество слов

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

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

Капитализация

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

Поработайте над отступами

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

На примере выше самый левый вариант дизориентирует. Правый — ваша цель.

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

Выравнивание метки: Сверху vs. Слева vs. Справа

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

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

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

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

Внутри поля
Не делайте так никогда. Внутри поля можно поместить подсказку (см.ниже), но никак не название поля, которое исчезнет, как только пользователь начнет вводить данные.

Плавающая метка (floating label)
Наилучшее решение с точки зрения дизайна из всех существующих на сегодяшний день. Плейсхолдер внутри поля превращается в метку сверху непосредственно в момент фокусировки.

Вывод: если вы хотите, чтобы пользователи быстро сканировали форму, ставьте метки над полями. Однако, если вы хотите, чтобы пользователи были более внимательны, выравнивайте метки по левому краю формы. Такой порядок будет тормозить пользователя и заставлять его производить просмотр в Z-образном виде.

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

Подсказки (tips)

Мы можем подсказывать, в каком формате требуется ввести данные в поле, двумя способами: используя плейсхолдеры внутри полей, а также оставляя подсказки рядом с полями.

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

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

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

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

Кнопки (action buttons)

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

Первичные действия vs. Вторичные действия

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

Расположение кнопки

Если форма сложная, в ней должна быть кнопка “назад”. Если расположить такую кнопку прямо под полями ввода (как на первой картинке), пользователи могут нажать на нее по ошибке. Поскольку кнопка “назад” — это второстепенное действие, она должна находиться в стороне (на второй картинке кнопки расположены правильно).

Наименование кнопки

Используйте в неймиге кнопок глаголы действия: “Войти”, “Зарегистрироваться”, “Забронировать”. Избегайте малоконтекстных типовых названий слов “Подтвердить”, “Далее”, старайтесь заменить их на более говорящие, чтобы можно было понять, что произойдет при после нажатия: “Подтвердить заказ”, “Перейти к оформлению”, “Создать бесплатный аккаунт” и т.д.

Внешний вид кнопки

Позаботьтесь о том ,чтоб кнопки выглядели как кнопки и призывали своим видом к действию, проработайте состояние при наведении (desktop-only) и состояние нажатия. И, конечно, вид поля должен отличаться от вида кнопки. Заметно отличаться.

Больше информации о кнопках читайте в статье Button UX Design: Best Practices, Types and States

Результат

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

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

Валидация

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

Человеческий язык

Пишите ошибки человеческим языком, а не машинным. Не стоит использовать термины, незнакомые реальному пользователю.

В процессе vs. в результате

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

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

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

Во время ввода vs при переходе к следующему полю

Наиучшим решением будет гибридное:

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

Награждайте рано, наказывайте поздно.

Защита данных

Что будет при случайном обновлении страницы? Джеф Раскин однажды сказал: “Система должна рассматривать все данные, вводимые пользователем в качестве священных”. Это абсолютная истина для форм. Здорово, если вы начинаете заполнять анкету и случайно обновляете страницу, но данные остаются в полях. Такие инструменты как Garlic.js помогут вам сохранить значения формы локально, пока форма не будет представлена. Таким образом, пользователям не придется терять драгоценные данные, если они случайно закрыли вкладку в браузере.

Работа с цветом

Используйте цвет с умом. Каждый раз, когда у вас появляется желание просто так сделать что-то не черно-белым — знайте, it’s a trap. Просто “чтобы красивее было” — это аргументация дизайнера-любителя. Используйте цвет для брендинга, логотипов. Используйте красный для ошибок, зеленый для всего, что связано с подтверждением и успешным заполнением.

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

Минимизируйте выделения

Как только мы начинаем выделять все, мы не выделяем ничего.

Правда есть случай, когда выделить все и поярче будет уместно. Японцы, например, считают европейские сайты “тоскливыми и неинтересными”. У них даже на сайтах крупных серьезных компаний все мигает, блестит и переливается. Когда же они заходят на сайт европейской страховой компании, то приходят к выводу, что там никто не работает и все процессы заморожены. Так что если разрабатываете форму для японской аудитории, не стесняйтесь разместить, скажем, танцующего медведя неподалеку, это повысит лояльность пользователей. Для европейцев же формы нужно делать лаконичными. Учитывайте разницу восточного и европейского менталитетов.

Цвет текста

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

Но главное, помните о контрастности. Цвет текста должен быть достаточно контрастным (не слишком темным, не слишком ярким) по отношению к фону. В руководстве W3C предлагается такое соотношение для основного текста:

• Для мелкого текста соотношение контрастов должно быть не менее 4,5:1 по отношению к фону.
• Если текст крупный (жирный 14pt или обычный — от 18pt и выше) контраст с фоном должен быть не менее 3:1.

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

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

Если ваш текст размером 18px или 14px bold, самый светлый оттенок серого, который вы можете использовать, — #959595. Если размер шрифта меньше, минимальное значение — #767676. Чтобы проверить, насколько ваш текст контрастен по отношению к вашему фону, используйте Colour Contrast Analyser.

Проверяйте консистентность

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

Mobile-Only Сделайте удобные тап-зоны

Тап-зоны должны быть достаточно большими, чтобы можно было без затруднений нажать пальцем. Общепринятый размер тап-зоны — 45–57px, но если подгонять поля под этот размер, то на мобильных они будут казаться огромными. Поле размером 32px — 40px не выглядит слишком большим, и при этом достаточно удобно для нажатия пальцем.

Высота поля в Bootstrap 3 по умолчанию 34px — и это хороший базовый размер. Не стоит делать поля меньше.

И наконец, просто проверьте

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

Горжусь вами, если дочитали до конца. Основой для написанного послужил мой тернистый практический опыт работы в сфере дизайна, а также перевод отличной статьи Nick Babich “Designing More Efficient Forms: Structure, Inputs, Labels and Actions”.

Любите то, чем занимаетесь, и занимайтесь тем, что любите.
Ваша Саша Куликовская Alexandra Kulikovskaya