Как оформить ошибку в мобильной форме: поле, пояснение и исправление

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

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

Практичная ошибка состоит из пары «место + пояснение»: поле электронной почты выделено, а под ним написано «Введите адрес в формате имя@домен.ru». Если поле обязательно, но пусто, сообщение «Заполните это поле» точнее, чем «Неверное значение». Если система не принимает конкретный формат, назовите правило или пример. Избегайте сообщений, которые описывают внутреннее состояние программы, но не помогают человеку: «Код 104», «Ошибка валидации», «Недопустимый ввод».

Это согласуется с рекомендациями W3C по идентификации ошибок: автоматически обнаруженная ошибка должна быть определена и описана текстом. Если способ исправления известен, критерий 3.3.3 об указании ошибки рекомендует сообщить подсказку, если она не раскрывает чувствительные данные. Эти материалы описывают WCAG для веб-контента; для нативного приложения это полезная проверочная модель, а не автоматическое заявление о соответствии.

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

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

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

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

Тон сообщения должен быть нейтральным и уважительным. «Вы неправильно заполнили поле» обвиняет человека, хотя причина может быть в неясной подписи, неожиданном формате или сбое связи. Apple в рекомендациях по текстовым полям и написанию интерфейсных текстов советует показывать ошибку рядом с полем и объяснять, как ввести данные корректно. Фраза «Неверное имя» сообщает вердикт; «Используйте буквы и дефис, например Анна-Мария» сообщает действие — если именно такое ограничение поддерживает поле.

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

Короткая ошибка вроде «Укажите индекс» может поместиться в одну строку, а пояснение к адресу — занять три или четыре. Макет должен расти по высоте, а не обрезать конец или накладывать сообщение на кнопку. Не задавайте фиксированную высоту контейнеру ради аккуратной сетки. Проверяйте длинный перевод и крупный системный размер шрифта: в локализованной версии объяснение может стать заметно длиннее, а увеличение текста меняет количество строк.

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

Для экранного диктора визуальная близость сама по себе не создаёт программную связь. Команда разработки должна связать подпись, состояние ошибки и сообщение средствами платформы, а появление ошибки после отправки — сделать доступным для объявления. Проверьте порядок чтения: название поля, его значение и сообщение не должны озвучиваться как независимые, непонятно кому принадлежащие фразы. Конкретная реализация зависит от UIKit, SwiftUI, Android Views или Compose; визуальный макет должен поддерживать эту связь, а не заменять её.

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

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

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

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

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

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

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

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

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

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