Тексты для форм и интерфейсов

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

UX-правила для текстов форм

Метки всегда видны: label, а не placeholder в тексте формы

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

Сообщения об ошибках — конкретные и без обвинений

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

• Неверно: «Некорректный email» — Верно: «Введите email в формате name@example.com»
• Неверно: «Поле обязательно» — Верно: «Укажите телефон — перезвоним в рабочее время»
• Неверно: «Вы ввели неверный пароль» — Верно: «Пароль — минимум 8 символов, включая цифру»

Текст кнопки отправки: глагол плюс результат

Кнопка «Отправить» обезличена: пользователь не понимает, что произойдёт после нажатия. Конкретный текст снижает страх ошибиться и повышает готовность нажать.

• Форма заявки — «Отправить заявку»
• Подписка — «Подписаться на рассылку»
• Регистрация — «Создать аккаунт»
• Оплата — «Оплатить 2 900 ₽»
• Обратный звонок — «Жду звонка»

Help-текст: только там, где он нужен

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

Тон и голос бренда в интерфейсах

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

Формальный и неформальный стиль текста формы

Выбор между «вы» и «ты» зависит от аудитории и характера продукта. B2B-платформа, банк, медицинский сервис — «вы». Молодёжное приложение или стартап с персонажем — возможно «ты». Зафиксируйте выбор в tone of voice и применяйте его во всех элементах: labels, placeholders, ошибки, кнопки, уведомления — без исключений.

Три принципа тона в форме и текста интерфейса

• Краткость. Label из 1–3 слов лучше, чем объяснение. «Дата рождения» — достаточно; «Пожалуйста, введите вашу дату рождения» — избыточно.
• Нейтральность ошибок. Сообщение описывает ситуацию, а не обвиняет: «Телефон введён неверно» вместо «Вы ввели неверный телефон».
• Последовательность терминов. Если в одном месте «Отмена» — везде «Отмена», не «Закрыть», не «Назад», не «Нет».

Примеры: код текста для сайта

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

<div class="field">
  <label for="email">Email для связи</label>
  <input
    type="email"
    id="email"
    name="email"
    placeholder="name@company.com"
    aria-describedby="email-hint email-error"
    aria-required="true"
  />
  <span id="email-hint" class="hint">
    Пришлём подтверждение на этот адрес
  </span>
  <span id="email-error" class="error" role="alert" aria-live="assertive">
    Введите email в формате name@company.com
  </span>
</div>
<button type="submit">Отправить заявку</button>

aria-describedby связывает поле сразу с подсказкой и блоком ошибки: скринридер прочитает оба при фокусе. role="alert" вместе с aria-live="assertive" гарантируют, что ошибка озвучивается сразу после появления — без дополнительного действия пользователя.

A/B-тесты текстов форм

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

Что тестировать в первую очередь в текстах формы

Как читать результат тестирования текста формы

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

Доступность: текст как основа инклюзивного интерфейса

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

Обязательные атрибуты и их текстовое наполнение

• label[for] привязан к input[id] — без этого скринридер не объявляет поле корректно.
• aria-required="true" на обязательных полях — вместо звёздочки, которую скринридер не интерпретирует как «обязательно».
• aria-describedby связывает поле с help-текстом и блоком ошибки — оба будут прочитаны при фокусе.
• role="alert" на блоке ошибки — динамическое сообщение озвучивается без дополнительного действия пользователя.

Текст для кнопок-иконок и элементов без видимой надписи

Кнопка «×» без текста получает aria-label="Закрыть". Иконка без подписи — aria-label с описанием действия, а не внешнего вида: не «иконка корзины», а «Удалить из заказа». Это правило распространяется на все интерактивные элементы без видимого текста: иконки-стрелки, гамбургеры, кнопки воспроизведения.

Уровень читабельности сообщений

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