Интерфейс — это не только кнопки и картинки. Часто пользователь видит «ОК» и думать о том, что происходит дальше. Или видит «Что-то пошло не так» и не понимает, что исправить. UX-текст – это не украшение, а часть пути, который ведёт человека к цели.
Плохие формулировки тормозят действие, путают в формах и вызывают раздражение. Хорошие — экономят время и уменьшают количество ошибок. В этой статье вы найдёте рабочие шаблоны для кнопок, подсказок и сообщений об ошибках. А ещё — критерии приёмки и чек-лист для передачи текстов разработчикам.
Материал будет полезен тем, кто делает дизайн интерфейсов, ставит задачу исполнителю или принимает готовые макеты и хочет, чтобы пользователь понимал, что делать на каждом шаге.
📌 По данным W3C (WCAG 2.2), сообщения об ошибках должны не только указывать на проблему, но и объяснять, как её исправить (SC 3.3.1).
Что входит в тексты интерфейса
Тексты в интерфейсы попадают не «для красоты». Они сопровождают действие и подсказывают следующий шаг. Микротексты живут в навигации, формах, статусах, уведомлениях и на пустых экранах. Это подписи полей, названия пунктов меню, подтверждения, системные сообщения. Каждый такой фрагмент — часть диалога, а не случайная надпись.
Важно отличать тексты интерфейса от маркетинговых формулировок. Их цель — помочь завершить задачу: заполнить форму, сохранить данные, понять причину сбоя. Они не убеждают и не продают. Они снимают вопросы здесь и сейчас. Поэтому в них меньше эмоций и больше ясности.
Хороший UX-микротекст держится на трёх критериях. Первый — понятность с первого чтения. Пользователь не должен перечитывать или гадать о смысле. Второй — предсказуемость. Формулировки совпадают с тем, что реально произойдёт после клика. Третий — единый тон. Если в одном месте «Сохранить», а в другом «Подтвердить», человек ожидает разные действия и путается.
Роль дизайн-команды здесь — не «вписать слова», а встроить их в сценарий. Когда тексты рассматривают отдельно от экранов и состояний, диалог ломается. Это особенно заметно в формах и уведомлениях, где важна последовательность и логика взаимодействия.
Мини-пример, как одна и та же фраза ломает диалог:
- В кнопке: «ОК».
- В уведомлении: «ОК».
- В ошибке: «ОК».
В результате человек не понимает, подтвердил он действие, согласился с ошибкой или просто закрыл окно.
Микрокопирайт — это не набор слов, а система. Он учитывает контекст экрана, состояние UI и ожидания человека. Поэтому одинаковые элементы не должны называться по-разному, а разные действия — одинаково.
текст — часть сценария, а не подпись к кнопке.
Написание текстов в UX/UI: процесс
Чтобы микротексты работали, их делают не «по ходу», а по шагам. Процесс простой и повторяемый. Он экономит время на правки и снижает риск противоречий между экранами.
Мини-алгоритм выглядит так:
- цель экрана и продукта;
- пользовательская задача в одном действии;
- список экранов, где задача решается;
- список состояний для каждого экрана;
- черновые формулировки;
- проверка в макете и в логике переходов.
Такой порядок важен. Сначала понимают, что делает пользователь, и в каких точках может «споткнуться». Потом появляются слова. Не наоборот.
Перед тем как начинать писать, соберите вводные. Они задают рамки и избавляют от споров в конце. Важно договориться о длине строк и кнопок, терминологии и допустимом тоне. Отдельно фиксируют юридические ограничения, требования к локализации и языковые версии. Если этого нет, одни и те же формулировки будут править бесконечно.
Работа в паре «заказчик — фрилансер» держится на ясных ролях. Исполнитель предлагает варианты и следит за логикой сценария. Заказчик утверждает тон, ключевые термины и спорные слова. Если решение принимают «всем чатом», тексты теряют единый голос и ломают опыт взаимодействия.
Короткий шаблон брифа для микротекстов:
- цель экрана и результат для человека;
- действие, которое нужно совершить;
- список экранов и состояний;
- ограничения по длине и тону;
- обязательные термины и запреты;
- кто принимает финальную версию.
Этот формат понятен и дизайнеру, и разработчику. Он помогает встроить тексты в UI, а не приклеить их в конце.
Иначе правки бесконечные.
Процесс кажется формальным, но именно он делает тексты частью сценария. Когда шаги соблюдены, микрокопирайт поддерживает действие, а не спорит с интерфейсом.
Кнопки: как назвать действие
Кнопка — это точка решения. В этот момент человек либо делает шаг дальше, либо останавливается. Поэтому кнопки называют не объект, а действие. «Сохранить», «Отправить», «Создать». Названия вроде «Данные» или «Форма» не дают понимания, что произойдёт после нажатия, и ломают сценарий.
Хорошая формулировка отвечает на простой вопрос: что именно случится после клика. Если действие сложное или необратимое, его называют прямо. Это повышает понятность и снижает страх ошибки. Особенно в формах, оплате и удалении данных.
Primary и secondary
У основной кнопки задача одна — вести сценарий вперёд. Здесь допустима краткость, если смысл очевиден из контекста экрана. У вторичной кнопки роль другая: отменить, вернуться, пропустить. В этих местах точность важнее длины. Лучше длиннее, но без двусмысленности.
Разные типы кнопок не должны конкурировать по смыслу. Если рядом стоят «Продолжить» и «Сохранить», человек тратит время на расшифровку. Это прямой удар по пользовательскому вниманию и доверию к интерфейсу.
Как убрать двусмысленность
Слова вроде «Отправить», «Применить», «Готово» часто требуют расшифровки. Что именно отправляется? Куда применяются изменения? В таких случаях название уточняют объект или результат. Это базовое правило того, как писать тексты на кнопках, чтобы они работали без подсказок.
Короткий список «плохо → лучше»:
- «Отправить» → «Отправить заявку»
- «Сохранить» → «Сохранить изменения»
- «Готово» → «Завершить настройку»
- «Далее» → «Перейти к оплате»
- «ОК» → «Подтвердить выбор»
- «Применить» → «Применить фильтр»
- «Удалить» → «Удалить файл»
Такие замены снимают вопросы и упрощают выбор. Формулировки становятся частью логики, а не декоративным элементом.
Название кнопки всегда проверяют в контексте экрана. Без соседних полей и заголовков даже хорошее слово может потерять смысл. Поэтому текст смотрят прямо в макете и читают как реплику диалога.
✅ Быстрая проверка кнопки: можно ли прочитать её вслух как команду? Если команда звучит странно или неполно, название стоит переписать.
Подсказки и пустые состояния
Подсказки и пустые экраны — это моменты, где интерфейс либо помогает, либо бросает человека одного. Здесь важно не количество слов, а точность. Текст должен снимать вопрос и вести дальше, а не объяснять очевидное.
Подсказка нужна там, где есть риск ошибки или новое действие. Это сложный формат ввода, нестандартное правило, первый контакт с функцией. В таких местах человек сомневается и замедляется. Короткая фраза помогает продолжить без проб и возвратов.
Подсказка мешает, если дублирует заголовок или повторяет подпись поля. Ещё хуже — когда она описывает проблему, но не подсказывает выход. Фразы без ответа на вопрос «что делать дальше» не работают и ухудшают взаимодействие с интерфейсом.
Подсказки и empty states
— это помощь до ошибки. Они появляются рядом с действием и объясняют правило заранее. Хорошая подсказка экономит попытку и не требует перечитывания. Плохая — добавляет текст, но не добавляет смысла.
Пустые состояния — это помощь после отсутствия результата. Когда экран пуст, человек не должен упираться в тупик. Вместо «Здесь пока ничего нет» показывают следующий шаг и пример. Это снижает тревогу и сохраняет понятность сценария.
Мини-кейс из практики:
Цель: заполнить форму профиля без поддержки.
Что написали: «Введите данные» под каждым полем.
Что изменили: подсказки с примерами формата и пустой экран с шагом «Добавьте первый элемент».
Результат: человек реже возвращается к полям и быстрее завершает настройку.
Важно смотреть на такие тексты в контексте UI. Одна и та же фраза может работать в форме и быть лишней на пустом экране. Оценка всегда идёт через поведение, а не через красоту формулировки.
👉 Подсказка должна экономить попытку, а не добавлять чтение.
Ошибки и системные сообщения
Ошибки — самый чувствительный участок интерфейса. В этот момент человек уже столкнулся с проблемой и ждёт помощи. Поэтому текст здесь обязан быть точным и спокойным. Его задача — объяснить ситуацию и подсказать следующий шаг, а не констатировать факт сбоя.
Сообщения в интерфейсе делятся на несколько типов. Ошибки ввода возникают в формах и полях. Системные появляются при сбоях сессии или сети. Ограничения предупреждают о правилах и лимитах. Подтверждения фиксируют успешное действие. Для всех типов работает одна логика: указать, что не так, где это произошло и как исправить. Это базовый принцип WCAG (SC 3.3.1), который напрямую влияет на понятность взаимодействия.
Тон таких текстов всегда нейтральный. Без обвинений и оценок. Слова «неверно» и «ошибка пользователя» создают давление и раздражают. Юмор допустим только в безопасных сценариях. Там, где затронуты деньги, данные или доступ к аккаунту, он недопустим.
Структура и примеры
Рабочие шаблоны, которые легко адаптировать под разные сценарии и сохранить единый стиль сообщения.
- «Не удалось ___, потому что ___. Попробуйте ___».
- «Поле ___: укажите ___ (пример: ___)».
- «Файл не загружен. Размер превышает ___».
- «Сессия истекла. Войдите снова».
- «Недостаточно прав для выполнения действия».
- «Действие отменено. Изменения не сохранены».
Такая структура помогает пользовательу быстро понять ситуацию и не терять контекст. Текст не должен требовать догадок или повторной попытки «наугад».
Блок «было → стало»:
- «Ошибка» → «Не удалось сохранить изменения. Проверьте подключение к сети».
- «Неверные данные» → «Поле “Телефон”: укажите номер в формате +7…».
- «Что-то пошло не так» → «Не удалось отправить форму. Попробуйте ещё раз через несколько секунд».
- «Доступ запрещён» → «Недостаточно прав. Обратитесь к администратору».
- «Ошибка сервера» → «Сервис временно недоступен. Мы уже работаем над восстановлением».
- «Недопустимое значение» → «Поле “Возраст”: введите число от 18 до 99»
- «Сбой» → «Сессия истекла. Войдите снова, чтобы продолжить».
Каждая замена добавляет конкретику. Человек понимает причину и видит выход. Это напрямую улучшает опыт работы с продуктом и снижает количество повторных ошибок.
❗ Ошибка — это помощь. Если человек не понял, что исправить, это не “сообщение”, а шум.
Проверка и передача в разработку
Даже хорошие формулировки могут «сломаться» на этапе внедрения. Поэтому UX-тексты проверяют и передают в разработку по правилам. Цель простая — сохранить смысл, тон и логику сценария после верстки и релиза.
Приёмка начинается с короткого чека. Текст читается с первого раза. Тон одинаковый на всех экранах. Нет двусмысленных слов и скрытых обещаний. Формулировки помещаются в макет и не обрезаются. Для каждого экрана прописаны состояния: loading, empty, error, success. Если хотя бы один пункт не выполнен, текст возвращают на доработку.
В разработку передают не «набор строк», а структуру. Нужен список экранов и состояний. Для каждого — готовые формулировки и условия показа. Отдельно фиксируют тексты, которые пойдут в логи или системные события, если продукт это использует. Такой подход снижает риск, что слова заменят «по месту» и изменят смысл микрокопирайту для интерфейсов.
Договорённости с фрилансером лучше фиксировать заранее. Указывают количество экранов и состояний, число итераций правок, срок и формат файла. Это защищает обе стороны и упрощает контроль качества. Ответственность за итоговый тон должна быть закреплена сразу, иначе правки будут бесконечными и размытыми.
Единая таблица для передачи в разработку:
| Элемент | Состояние | Что написать | Критерий приёмки |
|---|---|---|---|
| Кнопка | default | «Сохранить изменения» | Читается как команда, помещается в макет |
| Форма | error | «Поле “Email”: укажите адрес в формате …» | Понятно, что исправить |
| Экран | empty | «Добавьте первый элемент» | Есть следующий шаг |
| Система | loading | «Загружаем данные…» | Нет лишних обещаний |
Такой формат понятен дизайнеру, разработчику и тестировщику. Он сохраняет опыт пользователя и снижает количество правок после релиза.
FAQ
Сколько слов на кнопке?
Столько, сколько нужно для ясности. Обычно 1–3, но смысл важнее длины.
Можно ли шутить в ошибках?
Только в безопасных сценариях. Деньги, данные и доступ — без юмора.
Кто отвечает за тон?
Один человек. Заказчик или продукт-оунер. Это фиксируется заранее.
Что важнее: краткость или ясность?
Ясность. Если нужно больше слов — значит, так и должно быть.
Чёткая приёмка и аккуратная передача в разработку делают тексты частью UI, а не случайным слоем поверх интерфейса.
Итоги
Микротексты работают тогда, когда встроены в сценарий, а не добавлены в конце. Они ведут человека от шага к шагу, снимают сомнения и помогают завершить действие без лишних попыток. В этом смысле тексты — такая же часть логики продукта, как экраны и переходы между ними.
Единый тон держит диалог целым. Когда формулировки согласованы между собой, UX становится предсказуемым. Человек быстрее ориентируется, реже ошибается и не тратит время на расшифровку слов. Разнобой в названиях и сообщениях всегда ощущается как сбой, даже если интерфейс выглядит аккуратно.
Отдельное внимание стоит уделять состояниям. Loading, empty, error и success — это не исключения, а обычные этапы пути. Если они описаны заранее, продукт не оставляет человека в неопределённости и не требует догадок.
Приёмка по чек-листу фиксирует качество. Она помогает сохранить смысл при передаче в разработку и избежать правок «по вкусу». В результате микротексты поддерживают логику интерфейса и работают на задачу, а не отвлекают от неё.
Вам нужна биржа копирайтинга для работы копирайтером или хотите оформить написание статей на заказ?
Комментарии