Ошибки в формах: как проектировать валидацию и подсказки без раздражения

Почему валидация - это UX, а не техническая задача

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

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

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

Хорошая валидация говорит: «Вот что пошло не так, и вот как это исправить». Плохая валидация говорит: «Ты сделал что-то не так» - и замолкает.

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

Тайминг: когда показывать ошибку

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

Четыре момента, когда может появиться ошибка

On input (при вводе). Ошибка появляется в реальном времени, пока пользователь набирает текст. Это почти всегда плохая идея. Красная рамка появляется ещё до того, как человек закончил слово - это агрессивно и сбивает с толку. Исключение: индикатор силы пароля, который обновляется по мере ввода - здесь это уместно, потому что помогает принять решение, а не сообщает об ошибке.

On blur (при уходе с поля). Ошибка появляется, когда пользователь переходит к следующему полю. Это хороший момент для большинства случаев: человек закончил ввод в этом поле и переключил фокус - самое время дать обратную связь. Но важно не показывать ошибку, если поле пустое и пользователь просто «проходит мимо» - это создаёт лавину красных сообщений раньше, чем человек успел что-то ввести.

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

On fix (после исправления). После того, как ошибка уже была показана, поле переключается обратно в нейтральное состояние - или в состояние успеха - по мере того, как пользователь исправляет ввод. Это работает хорошо: человек видит прогресс в реальном времени.

Момент	Когда использовать	Когда избегать
On input	Индикатор силы пароля, счётчик символов	Проверка формата, обязательные поля
On blur	Проверка email, формата телефона, длины	Пустые поля, через которые пользователь только прошёл
On submit	Обязательные поля, финальная проверка	Поля, где важна немедленная обратная связь
On fix	После показа ошибки - всегда	-

Гибридный подход: лучшее из двух стратегий

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

Гибридный подход: лучшее из двух стратегий

Оптимальная стратегия для большинства форм - комбинация: первый раз ошибки показываются при сабмите, а после этого - инлайн при blur или on fix. То есть пока пользователь впервые заполняет форму, система молчит и не мешает. Как только он попытался отправить и увидел ошибки - при следующем редактировании исправления отслеживаются в реальном времени. Это сочетает предсказуемость с оперативностью и не создаёт ощущения постоянного «надзора» при первичном заполнении.

Инлайн-валидация vs валидация при сабмите

Это не вопрос «что лучше» - это вопрос «что лучше для конкретного типа формы».

Когда инлайн-валидация работает лучше

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

Когда валидация при сабмите предпочтительнее

Короткие формы с 2–4 полями - накладные расходы инлайн-валидации не оправданы.
Поля свободного текста без строгих правил формата.
Поиск и фильтры - здесь «ошибок» в классическом смысле нет, есть просто отсутствие результатов.
Форма обратной связи - расслабленный контекст, меньше напряжения.

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

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

Три правила хорошего сообщения об ошибке

Правило 1: Скажи, что не так. Не «Ошибка», не «Неверный формат», не «Проверьте введённые данные». Скажи конкретно - что именно не так с тем, что ввёл пользователь.

Правило 2: Скажи, как исправить. Хорошее сообщение об ошибке - это инструкция. Пользователь должен понять, что сделать прямо сейчас, чтобы продолжить.

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

❌ Плохо

Некорректный формат email

✓ Хорошо

Проверьте адрес - должно быть что-то вроде name@example.com

❌ Плохо

Поле обязательно для заполнения

✓ Хорошо

Введите номер телефона - мы отправим туда код подтверждения

❌ Плохо

Пароль не соответствует требованиям безопасности

✓ Хорошо

Добавьте хотя бы одну цифру - это делает пароль надёжнее

❌ Плохо

Error 422: Validation failed

✓ Хорошо

Этот email уже зарегистрирован. Войдите или восстановите пароль

Тон: не обвиняй пользователя

Формулировки от первого лица («Вы ввели неверный пароль») звучат как обвинение. Формулировки, ориентированные на действие, звучат как помощь: «Неверный пароль - попробуйте другой или восстановите его». Пассивный залог тоже снижает напряжённость: «Пароль не совпадает» мягче, чем «Вы ввели пароль неправильно».

Длина сообщения

Ошибка должна быть короткой - одно предложение. Если нужно объяснить требования к полю подробнее, это делается через подсказку (hint) до того, как пользователь сделал ошибку, а не через длинное сообщение после.

Ошибки аутентификации: особый случай

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

Ошибки аутентификации: особый случай

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

Для формы восстановления пароля используйте тот же принцип: «Если такой email существует в системе, мы отправили инструкции» - безопаснее, чем «Email не найден».

Подсказки и inline hints

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

Placeholder vs hint text

Placeholder - текст внутри поля, который исчезает при вводе. Hint text - текст под полем, который остаётся всегда видимым.

Placeholder удобен для примеров формата: «+7 (999) 999-99-99» или «name@example.com». Но у него есть критический недостаток: он исчезает при вводе. Если пользователь заполнил половину формы и вернулся к полю - он уже не видит, что там должно быть. Поэтому placeholder не подходит для важных инструкций и требований.

Hint text - более надёжный инструмент для требований и пояснений. «8–20 символов, хотя бы одна цифра» под полем пароля видно всегда - до ввода, во время и после.

Пароль

8–20 символов · хотя бы одна цифра · хотя бы одна заглавная буква

Когда давать подсказку

Подсказка нужна тогда, когда требование к полю неочевидно из самого label. Если поле называется «Email» - подсказка не нужна: все знают, как выглядит email. Если поле называется «Промокод» - полезно написать, откуда его взять. Если поле «ИНН» - нужно уточнить, 10 или 12 цифр, и для кого какой.

Подсказка не нужна к каждому полю. Избыток объяснений создаёт информационный шум и снижает внимание к действительно важным пояснениям.

Прогрессивное раскрытие подсказки

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

Визуальный дизайн ошибок и состояний поля

Каждое поле формы может находиться в одном из нескольких состояний: default, focused, error, success, disabled. Все они требуют визуального различия - но не чрезмерного.

Состояния и как их показывать

Примеры состояний полей

Email - нейтральное

Email - ошибка

⚠ Проверьте адрес - должно быть что-то вроде name@example.com

Email - успешно

✓ Отлично

Цвет - не единственный сигнал

Красный цвет - стандартный сигнал ошибки. Но опираться только на цвет нельзя: около 8% мужчин и 0.5% женщин имеют нарушения цветовосприятия, при которых красный и зелёный плохо различимы. Ошибку должен сопровождать:

иконка (⚠ или ✕ рядом с текстом ошибки);
текстовое сообщение;
изменение формы/толщины рамки поля (не только цвета).

Где размещать сообщение об ошибке

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

Не красить всё поле при ошибке

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

Доступность: валидация для всех

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

ARIA-атрибуты для валидации

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

aria-invalid="true" на поле, которое имеет ошибку - скринридер объявит его как невалидное;
aria-describedby на поле, ссылающийся на id блока с сообщением об ошибке - скринридер прочитает сообщение при фокусе на поле;
role="alert" или aria-live="polite" на контейнере ошибки - чтобы сообщение зачитывалось автоматически при появлении.

Управление фокусом при ошибке сабмита

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

Управление фокусом при ошибке сабмита

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

Не блокировать кнопку сабмита превентивно

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

Особый случай: поля паролей

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

Требования к паролю - до ввода, не после

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

Индикатор силы пароля

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

Показать/скрыть пароль

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

Подтверждение пароля

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

Особый случай: телефоны, даты, числа

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

Телефоны

Люди вводят телефоны очень по-разному: с пробелами, с дефисами, с кодом страны, без него, со скобками и без. Хорошая форма принимает всё это и сама нормализует. Плохая форма требует строго «+79991234567» и выдаёт ошибку при любом другом вводе.

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

Даты

Для дат предпочтительны специализированные контролы (date picker), а не поле свободного ввода. Если всё же нужно текстовое поле - используйте маску и hint с форматом. Никогда не проверяйте только после сабмита - для дат инлайн-валидация при blur обязательна.

Отдельная проблема: разница форматов в разных локалях. ДД/ММ/ГГГГ в России и MM/DD/YYYY в США - это разные вещи. Пользователь из России, видя поле «дата», введёт «15/08/1990». Если ваша форма ждёт американский формат, это катастрофа. Показывайте формат явно.

Числа и суммы

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

Суммарные ошибки и прокрутка к проблеме

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

Суммарный блок ошибок

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

Важно: суммарный блок дополняет, а не заменяет inline-ошибки под полями. Пользователь должен видеть ошибку и в списке, и рядом с самим полем.

Автоскролл к первой ошибке

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

Валидация на мобильных устройствах

Мобильные формы - отдельный сложный случай. Экран маленький, клавиатура занимает половину, набор текста медленный. Каждая дополнительная итерация «попробовал, ошибся, исправил» стоит дороже, чем на десктопе.

Правильная клавиатура для типа поля

Атрибут inputmode и тип поля type определяют, какая клавиатура откроется. Это напрямую влияет на количество ошибок:

type="email" - клавиатура с символом @ и точкой;
type="tel" - цифровая клавиатура для телефонов;
inputmode="numeric" - только цифры без минуса и запятой;
inputmode="decimal" - цифры с запятой/точкой для сумм;
type="date" - нативный date picker.

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

Размер зоны ошибки

На мобильном сообщение об ошибке должно быть достаточно заметным, чтобы его не перекрывала клавиатура. Когда поле в фокусе и клавиатура открыта, hint и error-message должны оставаться видимыми. Это требует специального внимания при проектировании - проверяйте в реальных условиях, а не только в браузере на десктопе.

Микрокопи в формах

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

Лейблы. Лейбл должен точно описывать, что нужно ввести. «Телефон или email» точнее, чем «Контактная информация». Лейблы должны быть видны всегда - поэтому «плавающий лейбл», который превращается в placeholder при вводе, снижает доступность, хотя и выглядит опрятно.

Кнопка сабмита. «Отправить» - слабый текст: не говорит, что произойдёт. «Создать аккаунт», «Оформить заказ», «Получить код» - конкретно и убедительно. Текст кнопки должен отвечать: «что случится после нажатия?»

Состояние загрузки. После нажатия кнопка должна заблокироваться и показать индикатор загрузки. Иначе пользователь нажимает несколько раз, думая, что форма не реагирует.

Подтверждение успеха. После отправки - конкретное сообщение: «Аккаунт создан - письмо с подтверждением отправлено на vasya@mail.ru» убедительнее, чем просто «Готово».

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

Step-by-step формы имеют свою специфику валидации.

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

Показывайте прогресс. Индикатор «Шаг 2 из 4» снижает тревогу и даёт понять, сколько осталось. Без него форма кажется бесконечной.

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

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

10 типичных ошибок в проектировании валидации

1. Ошибка появляется, пока пользователь ещё набирает

Красная рамка на поле email, в которое ввели одну букву - это агрессивный UX. Ждите blur.

2. Слишком строгая проверка формата

Форма не принимает «Иван Иванов-Петров» в поле имени, потому что в ней дефис. Или отказывается от телефона с пробелами. Будьте терпимее к разнообразию реального ввода.

3. «Поле обязательно для заполнения» без объяснения, зачем

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

4. Технические сообщения об ошибках

«Error 400: Bad Request», «Validation failed», «Invalid input» - всё это нужно заменить на человеческий язык до того, как форма попадёт в продакшн.

5. Форма очищает поля при ошибке

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

6. Ошибки появляются только после сабмита в длинной форме

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

7. Нет указания на то, где именно ошибка

«Проверьте введённые данные» без указания, что именно и в каком поле - бесполезное сообщение.

8. Блокировка кнопки сабмита без объяснения

Серая кнопка «Отправить» без пояснения, почему она неактивна - источник замешательства. Если блокируете - добавьте tooltip или inline-hint, объясняющий условие.

9. Успешное состояние поля там, где оно не нужно

Зелёная галочка после ввода имени «Вася» выглядит странно - что здесь «успешно»? Состояние success уместно для полей с проверкой уникальности (имя пользователя, email) или сложных требований (пароль).

10. Подсказки в placeholder, которые исчезают при вводе

Если пользователю нужно помнить требование к полю при вводе - это hint, а не placeholder. Placeholder - только для примера формата.

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

Чеклист дизайнера перед сдачей формы

ТАЙМИНГ
✓  Ошибки не появляются во время ввода (кроме счётчика символов)
✓  При blur показывается валидация для полей с форматом
✓  При сабмите показываются все пропущенные обязательные поля
✓  После первого сабмита - инлайн-валидация при исправлении

ТЕКСТЫ
✓  Каждое сообщение об ошибке говорит, что именно не так
✓  Каждое сообщение говорит, как исправить
✓  Нет технического жаргона и кодов ошибок
✓  Тон нейтральный, не обвинительный

ВИЗУАЛЬНЫЙ ДИЗАЙН
✓  Ошибка обозначена не только цветом - есть иконка и текст
✓  Сообщение об ошибке находится прямо под полем
✓  Все состояния поля проработаны: default, focused, error, success
✓  Фон поля не перекрашивается агрессивно при ошибке

ПОДСКАЗКИ
✓  Hint под полем виден всегда, не только при фокусе - там, где нужен
✓  Placeholder использован только для примеров формата
✓  Требования к полю указаны до ввода, не после ошибки

ДОСТУПНОСТЬ
✓  aria-invalid на невалидных полях
✓  aria-describedby связывает поле с его сообщением об ошибке
✓  При сабмите фокус переходит к первой ошибке
✓  Ошибки читаются скринридером (role="alert" или aria-live)

МОБИЛЬНЫЕ
✓  Тип поля и inputmode задан корректно для каждого поля
✓  Сообщение об ошибке видно при открытой клавиатуре
✓  Минимальный размер touch-цели для кнопок рядом с полями - 44px

ОБЩЕЕ
✓  Данные не очищаются при ошибке
✓  При длинной форме есть суммарный блок ошибок с якорной навигацией
✓  Форма проверена на реальных пользователях (хотя бы 3 человека)

Частые вопросы о проектировании валидации

Когда стоит показывать «зелёную галочку» как успех?

Только для полей, где успех неочевиден без явного подтверждения: поле пароля (все требования выполнены), имя пользователя (доступно), email (не занят). Для обычных текстовых полей зелёная галочка избыточна и создаёт визуальный шум.

Нужна ли валидация в реальном времени для номера телефона?

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

Как обрабатывать серверные ошибки?

Нужно ли помечать обязательные поля звёздочкой?

Это устаревший паттерн с рядом проблем: пользователи часто не знают, что значит звёздочка, и приходится добавлять сноску «* - обязательное поле». Лучшая практика - помечать необязательные поля словом «(необязательно)», а все остальные считать обязательными по умолчанию. Если форма состоит почти полностью из необязательных полей - используйте звёздочку в обратном смысле или просто помечайте всё явно.

Как обрабатывать серверные ошибки?

Серверная ошибка должна отображаться так же, как inline-ошибка - рядом с полем, которого касается. Если ошибка общая (сервер недоступен, лимит запросов) - отображается в отдельном блоке над формой. Никогда не показывайте просто «что-то пошло не так» без деталей. Всегда предлагайте пользователю конкретное действие: «попробуйте ещё раз» или «обратитесь в поддержку». Данные формы при серверной ошибке должны сохраняться - пользователь не должен заполнять всё заново из-за проблемы на стороне системы.

Нужно ли помечать обязательные поля звёздочкой?

Это устаревший паттерн. Пользователи часто не знают, что значит звёздочка, и приходится добавлять сноску. Лучшая практика - помечать необязательные поля словом «(необязательно)», а все остальные считать обязательными по умолчанию. Ещё лучше - убирать из формы всё, что не обязательно: форма должна содержать только те поля, без которых действие невозможно.

Итог

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

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

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

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

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