Как сделать удобную форму на сайте: ошибки в формах и UX-валидация

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

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

Сколько полей действительно нужно

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

Что я обычно вычёркиваю:

• отчество, если вы не оформляете договор прямо сейчас;
• дату рождения «для поздравлений»;
• повтор e-mail и повтор пароля (достаточно кнопки «показать пароль»);
• «Как вы о нас узнали» на первом шаге — это вопрос для письма после покупки;
• три поля для ФИО вместо одного, если вам не нужно склонять имя по падежам.

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

Отдельно проверьте, не спрашиваете ли вы то, что уже знаете. Человек вошёл в аккаунт, а вы просите e-mail ещё раз — это лишний ввод. В WCAG 2.2 это даже вынесено в отдельный критерий (3.3.7, «Redundant Entry»): не заставляйте вводить одни и те же данные повторно в рамках одного процесса.

Подпись или placeholder

Placeholder — серый текст внутри поля — выглядит аккуратно и экономит место, поэтому его так любят. Но у него несколько проблем, которые я регулярно вижу при тестах с живыми людьми.

• Как только человек начал печатать, подсказка пропала. Вернуться и проверить, что именно просили, нельзя.
• Серый текст часто не проходит по контрасту. Для обычного текста WCAG требует 4,5:1, а placeholder обычно делают бледнее.
• Заполненная форма с placeholder вместо подписей выглядит как набор непонятных значений, особенно когда человек возвращается к ней после паузы.
• Скринридер и автозаполнение лучше работают с настоящим <label>, связанным с полем.

Рабочая схема: подпись над полем, всегда видимая. Placeholder — только для примера формата, и то не всегда.

Правила про обязательность тоже стоит сделать явными. Если почти все поля обязательные, помечайте необязательные словом «необязательно». Если наоборот — звёздочкой лучше отметить обязательные и объяснить, что она значит. Угадывать человеку не нужно.

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

Валидация и тексты ошибок

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

Когда проверять

Моё правило: проверять поле, когда человек из него вышел, а не пока печатает. Если ругаться на второй символе e-mail («неверный адрес»), человек чувствует, что с ним спорят раньше времени. Исключение — подсчёт символов и надёжность пароля: тут подсказка в процессе помогает.

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

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

Как писать тексты ошибок

Хороший текст отвечает на два вопроса: что не так и что сделать. Без обвинений и без внутренней кухни («Error 422»). Это согласуется и с эвристиками Нильсена: сообщение должно точно называть проблему и предлагать выход.

Ошибка не должна быть выражена одним цветом. Красная рамка без текста не видна людям с нарушениями цветовосприятия, а в WCAG об этом прямо сказано (критерий 3.3.1: ошибку нужно описать текстом). Добавьте иконку и сообщение под полем, а само сообщение свяжите с полем через aria-describedby.

Строгие маски ввода тоже часто вредят. Человек вставляет номер с «8» в начале или с пробелами, а маска ломается. Принимайте любой разумный формат и приводите к единому виду на своей стороне. Так же с пробелами в конце и в номере карты.

Клавиатура и автозаполнение

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

Три вещи, которые делаются атрибутами и не требуют дизайна:

1. Тип поля. type="email" показывает клавиатуру с @, type="tel" — цифровую панель для телефона.
2. inputmode. Для полей, где нужны только цифры, но тип number не подходит (индекс, код из СМС, номер карты): inputmode="numeric". Для дробных значений есть decimal, для поиска — search.
3. autocomplete. Подсказывает браузеру, что вводит человек, и позволяет подставить сохранённые данные одним касанием.

Самые полезные значения autocomplete:

• name или given-name и family-name — имя;
• email и tel — почта и телефон;
• street-address, postal-code — адрес доставки;
• one-time-code — код из СМС: на телефонах он может подставиться автоматически;
• current-password и new-password — чтобы менеджер паролей понимал, вход это или регистрация.

Это ещё и требование доступности: WCAG 2.2 (критерий 1.3.5) просит указывать назначение полей с данными о человеке.

Отдельно про размер шрифта. Если в поле шрифт меньше 16px, мобильный Safari при фокусе приближает страницу, и форма «уезжает». Это легко проверить на своём телефоне, а чинится одной строкой в CSS.

Ещё мелочи, которые накапливаются: отключённая автокоррекция в поле для имени и e-mail (autocapitalize="none" для почты), возможность вставить текст в любое поле, включая подтверждение пароля, и пометка autofocus только там, где форма — единственная цель страницы.

Капча и защита от спама

Капча решает проблему владельца сайта за счёт пользователя. Заставить человека выбирать светофоры перед заявкой значит спросить: «Вы точно не робот?» у того, кто как раз собирался заплатить.

Порядок, которого я придерживаюсь: сначала невидимое, потом видимое.

• Honeypot — скрытое поле, которое заполняют только боты. Человек его не видит и не замечает защиты.
• Минимальное время заполнения. Если форма отправлена за секунду, это не человек.
• Проверка на сервере и ограничение частоты отправок с одного адреса.
• Невидимые капчи, например Yandex SmartCaptcha или Cloudflare Turnstile, в режиме, когда задание показывается только подозрительным посетителям.
• Подтверждение по почте или СМС для критичных действий вроде регистрации.

Если картиночная капча всё же нужна, проверьте три вещи: есть ли аудиовариант или альтернатива, читается ли задание на маленьком экране и не сбрасывается ли форма при неверном ответе. В WCAG 2.2 есть критерий 3.3.8 (Accessible Authentication): при входе нельзя требовать когнитивных усилий вроде распознавания искажённых символов, если нет альтернативы.

Кнопка отправки

Кнопка — последнее, что видит человек перед решением. Поэтому она не должна быть похожа на всё остальное и не должна врать.

• Называйте действие, а не процесс. «Отправить» говорит мало. «Получить расчёт», «Записаться на консультацию», «Оформить заказ» — понятнее и объясняют, что произойдёт дальше.
• Одна главная кнопка. «Очистить форму» рядом с «Отправить» — гарантированная случайная потеря данных. Если сброс нужен, уберите его в текстовую ссылку.
• Размер под палец. В гайдлайнах платформ рекомендуют области нажатия примерно от 44 до 48 пунктов, а WCAG 2.2 в критерии 2.5.8 задаёт минимум 24×24 CSS-пикселя. Это не одно и то же: минимум нужен для соответствия, а не как цель.
• Состояние после нажатия. Кнопка должна показать, что запрос идёт («Отправляем…»), и защитить от двойного нажатия.
• Что будет дальше. Рядом короткая строка: «Ответим в течение рабочего дня» — только если вы реально так отвечаете. Обещание, которое не выполняется, вредит сильнее, чем его отсутствие.

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

Многошаговые формы

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

Когда это оправдано:

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

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

Что нужно сделать, если шаги всё же есть:

1. Показать, где человек находится: «Шаг 2 из 4» и названия шагов. Неизвестность длины пугает.
2. Начать с лёгкого. Первый шаг с одним простым вопросом снижает порог входа.
3. Сохранять введённое при возврате назад. Потерянные данные — самая раздражающая ошибка.
4. Проверять шаг до перехода к следующему, а не в самом конце.
5. Дать итоговый экран с возможностью проверить и исправить ответы.
6. Не прятать цену или обязательные условия на последнем шаге.

Как проверить, что многошаговая форма лучше одношаговой? Только тестом: A/B или сравнением воронки по шагам. Универсальных ответов тут нет, и я не доверяю статьям, которые утверждают обратное. Как я вообще проверяю такие гипотезы, описано в статье «Как я провожу UX-аудит за неделю».

Мобильная версия и доступность

Эти два пункта я объединяю не случайно: почти всё, что делает форму удобной на телефоне, улучшает её и для людей с ограничениями. И наоборот.

Мобильные детали

• Одна колонка. Два поля в ряд на узком экране — это мелкий текст и промахи по нажатию.
• Расстояние между полями достаточное, чтобы палец не попадал в соседнее.
• Фиксированная кнопка внизу не должна перекрываться экранной клавиатурой и закрывать поле, в которое человек вводит текст. Проверьте на реальном устройстве, а не в режиме эмуляции в браузере.
• Выпадающий список из 50 пунктов лучше заменить поиском с подсказками. Для коротких списков подойдут сегменты или радиокнопки.
• Календарь для даты рождения, где нужно листать месяцы на двадцать лет назад, — классика плохого UX. Три коротких поля (день, месяц, год) с цифровой клавиатурой быстрее.

Доступность

• Каждое поле имеет label, связанный через for и id.
• Форму можно полностью пройти с клавиатуры: порядок табуляции совпадает с визуальным, фокус виден.
• Контраст текста — не ниже 4,5:1, границ полей и значимых элементов — 3:1 (WCAG 2.2, критерии 1.4.3 и 1.4.11).
• Ошибки объясняются текстом, а не только цветом, и озвучиваются скринридером.
• Группы радиокнопок и чекбоксов обёрнуты в fieldset и legend.

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

Как быстро диагностировать свою форму

Если времени на полноценное исследование нет, достаточно получаса и телефона. Вот что я проверяю в таком порядке.

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

Про использование AI-инструментов для разбора скриншотов форм я писал отдельно, в заметке «Как я использую AI в работе»: хорошо подходит для первичного списка гипотез, но не заменяет проверку на живых людях.

Чек-лист удобной формы

• Каждое поле нужно сегодня, остальное убрано или перенесено на потом
• Подпись всегда над полем, placeholder — только пример
• Обязательные и необязательные поля обозначены явно
• Проверка при выходе из поля, а не только при отправке
• Ошибка говорит, что не так и как исправить, и не держится на одном цвете
• Введённые данные не пропадают после ошибки
• Правильные type, inputmode и autocomplete
• Шрифт в полях не меньше 16px
• Капча не мешает обычному человеку
• Кнопка называет действие, достаточно крупная и показывает состояние
• Форма проходится с клавиатуры и читается на узком экране
• После отправки понятно, что будет дальше

Частые вопросы

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