Лучшие практики дизайна форм: 10 правил для веба и мобильных

Цена плохой формы

Плохая форма — это налог на каждый доллар, потраченный на привлечение пользователя. Процент заполнения форм регистрации, оформления заказа и онбординга в среднем составляет около 12%, когда в них есть трение. Устраните трение, и этот показатель перевалит за 50%.

Разрыв почти никогда не в тексте и не в брендинге. Всё дело в десяти правилах, применяемых последовательно.

Посмотреть на notion.so

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

Правило 1: Один столбец, одна задача на экране

Один столбец, всегда. Многоколоночные макеты выглядят эффективно в сетке Figma и убивают конверсию форм на реальном экране.

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

Поток регистрации Notion — один центрированный столбец с одним выделенным полем на мобильном. Форма ощущается быстрой, потому что просит об одной вещи. Вот и всё правило.

Правило 2: Расположение метки важнее её стиля

Метки располагаются над полем. Не внутри, не сбоку. Над полем, всегда видимые.

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

Посмотреть на mercury.com

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

UX-исследования о расположении меток подробно рассмотрены в нашем руководстве по методам UX-исследований.

Правило 3: Порядок полей следует логике пользователя, а не схеме базы данных

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

Форма оформления заказа, запрашивающая адрес доставки до подтверждения корзины, перекладывает на пользователя бремя контекста. Stripe Checkout, образцовый пример UX для форм оплаты, делит форму на три шага:

1. Email (кто вы)
2. Оплата (чем платите)
3. Адрес (куда отправить)

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

Правило 4: Валидация — в реальном времени, а не при отправке

Проверяйте поле в момент, когда пользователь покидает его, а не при нажатии кнопки отправки.

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

Apple ID проверяет формат email на blur и подтверждает доступность аккаунта до того, как кнопка отправки становится активной. Такая последовательность предотвращает сразу два класса ошибок. Паттерны взаимодействия, лежащие в основе этого, рассмотрены в нашем руководстве по дизайну микровзаимодействий.

Правило 5: Мобильный подход означает мобильные клавиатуры

Каждый тип поля должен вызывать правильную клавиатуру. Это 80% дизайна мобильных форм.

Если поле запрашивает номер телефона, а появляется стандартная текстовая клавиатура, форма сломана ещё до первого нажатия. Используйте inputmode="numeric" для числовых полей, type="email" для вывода символа @, и inputmode="decimal" для цен. iOS и Android поддерживают полный диапазон режимов ввода.

Клавиатура — основное устройство ввода на мобильном. Указать неправильную значит превратить визуально правильно спроектированную форму в источник разочарования.

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

Правило 6: Прогресс, микрокопи и проблема длинных форм

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

Многошаговый поток бронирования Airbnb показывает индикатор прогресса с именованными шагами на протяжении всего процесса. Пользователи, видящие, что прошли 60% пути, заметно чаще доходят до конца, чем те, у кого нет точки отсчёта.

Посмотреть на tally.so

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

Микрокопи решают ту же задачу. "Шаг 2 из 4" честнее, чем просто индикатор прогресса. "Это нужно для подтверждения вашей личности" полезнее, чем поле без подписи с чувствительными данными.

Правило 7: Сообщения об ошибках — это инструкции, а не обвинения

Пишите сообщения об ошибках в повелительном наклонении, а не в обвинительном.

"Это поле обязательно" — обвинение. "Введите адрес email, чтобы продолжить" — инструкция. Пользователь уже знает, что что-то пошло не так. Ему нужно решение.

Лучший текст об ошибке называет точное условие и точное действие: "Пароль должен содержать не менее 8 символов и хотя бы одну цифру." Stripe Checkout делает именно это. Сообщение появляется на blur, называет проблему и исчезает, как только условие выполнено.

Никакого затяжного красного состояния. Просто работает.

Правило 8: Автозаполнение — это функция, а не послемыслие

Атрибут autocomplete сообщает браузеру точно, что нужно заполнить. Используйте его на каждом поле.

Форма оформления заказа с правильными атрибутами autocomplete занимает около 12 секунд на телефоне с сохранёнными данными. Без них то же самое занимает две минуты, потому что пользователь вводит всё вручную. Именно в этих 108 секундах и живёт большинство отказов при мобильном оформлении заказа, и закрыть этот разрыв ничего не стоит. Руководство по библиотеке UI-компонентов рассказывает, как встроить эти атрибуты в компоненты форм вашей дизайн-системы, чтобы они никогда не терялись.

Правило 9: Кнопка отправки решает всё

Кнопка отправки — это контракт. Её текст, состояние и расположение сигнализируют, можно ли пользователю доверять тому, что произойдёт дальше.

Серая неактивная кнопка без объяснений говорит пользователю, что форма сломана, но не почему. Это тупик. Кнопка с текстом "Отправить" не говорит пользователю ничего о том, с чем он соглашается.

"Создать аккаунт", "Получить бесплатный пробный период", "Начать создавать" — всё это честнее. Деактивируйте кнопку только тогда, когда можете объяснить причину в интерфейсе. Tally использует конкретный текст действия на кнопке для каждого шага в конструкторе форм, и это напрямую способствует их выше среднего показателям завершения для встроенных B2B-форм.

Правило 10: Тестируйте на реальных пальцах, реальных данных, реальной задержке

Тестирование формы в браузере на десктопе через быстрый Wi-Fi не говорит ничего значимого о том, работает ли она.

Тестируйте на Android-устройстве среднего класса с 4G-соединением и данными реальной длины в каждом поле:

• Имя с символом с диакритикой
• Адрес с номером квартиры во второй строке
• 22-символьный email
• Имя из одного символа

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

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

Где дизайнеры по-прежнему делают худшие формы

Худшие формы в продакшене сегодня объединяют три паттерна:

• Корпоративные лид-формы: Salesforce-стиль, 30 полей квалификации с обязательным выбором "годового дохода" и без встроенной валидации
• Многошаговые онбординговые флоу без сохранения прогресса: телефонный звонок на шаге 7 из 9 возвращает пользователя на шаг 1
• Формы оформления заказа, созданные до эпохи мобильных и никогда не переработанные: каждое числовое поле до сих пор использует type="text", потому что "на десктопе работает нормально"

Выбор состояния ошибки во всех трёх случаях также, как правило, не соответствует требованиям к контрасту; паттерны доступного цветового контраста устраняют эту конкретную проблему.

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

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

---

FAQ

Сколько полей должно быть в форме?

Ровно столько, сколько требует результат. Правильное число — то, при котором удаление ещё одного поля сломает продукт. Каждое добавленное поле снижает процент завершения. Начните с нуля и добавляйте только обязательное.

Что лучше: многошаговая или одностраничная форма?

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

Как лучше всего помечать обязательные поля?

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

Отмечайте исключения. "Необязательно" рядом с полем несёт реальную информацию. Звёздочка у каждого поля — нет.

Как обрабатывать требования к паролю, не наказывая пользователя?

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

Сообщает ли ширина поля что-то пользователю?

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

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

Что чаще всего приводит к отказу от мобильных форм?

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

Устраните оба с помощью двух атрибутов на каждое поле. Затраты — 15 минут. Отдача — измеримый рост конверсии при оформлении заказа уже в том же спринте.