На ревью прототипа экран выглядит готовым к разработке.
Поля на месте. Кнопки из дизайн-системы. Ошибки предусмотрены. Даже пустое состояние не забыли.
Потом кто-то читает текст вслух:
Недостаточно прав для выполнения операции.
И комната на секунду замолкает.
Каких прав? У кого? Что теперь делать? Это проблема с ролью в команде или просто сервис не успел сохранить изменения?
Команда знает ответ, потому что неделю обсуждала сценарий. Пользователь видит эту фразу впервые. У него нет бэклога, Slack-треда и объяснения дизайнера рядом.
В этот момент текст перестаёт быть косметикой.
Он либо ведёт человека дальше, либо заставляет его додумывать.
В этой статье — практичный разбор для PM и дизайнера: как проверить текст интерфейса на прототипе до разработки, где чаще всего ломаются подсказки, ошибки, подтверждения и empty states, и какие вопросы задавать, чтобы не чинить микрокопирайт уже после релиза.
Текст интерфейса — это не “слова на макете”
Текст интерфейса — это всё, чем продукт разговаривает с человеком в момент действия.
Не только заголовки и кнопки. Ещё:
- подписи полей;
- подсказки в интерфейсе;
- ошибки и валидация;
- подтверждения и предупреждения;
- пустые состояния;
- статусы, успехи и системные сообщения.
У каждого такого фрагмента есть работа. Не “звучать приятно”, а снять конкретную неопределённость:
- что это за экран;
- что от меня хотят;
- что будет после клика;
- почему возникла ошибка;
- можно ли вернуться назад.
Если текст не отвечает, человек отвечает за него сам.
Обычно — самым тревожным способом.
Почему в команде всё понятно, а пользователь застревает
Внутри команды контекст всегда толще.
Вы помните обсуждения. Знаете ограничения бэка. Понимаете, что Доступ — это роль внутри команды, а не публикация наружу. Догадываетесь, что Продолжить ведёт на шаг подтверждения, а не сразу списывает деньги.
Пользователь этого не знает.
Он видит экран впервые и читает буквально.
Три частые поломки:
1. Командный язык. Синхронизировать, применить, развернуть, активировать. 2. Результат не назван. ОК, Готово, Продолжить, Подтвердить. 3. Риск спрятан. Человек не понимает, что изменится, удалится, отправится или станет видно другим.
Это видно не в редакторе текста, а в сценарии. Пока человек не дошёл до клика, ошибки, формы или подтверждения, текст может казаться нормальным.
Поэтому проверять нужно не “все тексты продукта”, а один путь пользователя.
Быстрый аудит текста: 20 минут на один сценарий
Это не вычитка.
Вычитка ловит опечатки. UX-аудит текста ловит места, где пользователь не понимает, боится нажать или не знает, как исправить ошибку.
Шаг 1. Выберите один сценарий и один риск
Слабо: “проверим тексты в продукте”.
Лучше: “новый пользователь впервые подключает тариф для команды”.
Ещё лучше: “новый пользователь выбирает тариф, доходит до оплаты и должен понять, когда спишутся деньги”.
Один сценарий = один экранный путь + одна задача + один главный страх.
Шаг 2. Дайте прототип без устных объяснений
Если дизайнеру нужно проговаривать смысл голосом, текст не работает.
Прототип должен сам объяснять:
- куда попал человек;
- что он может сделать;
- что изменится после действия;
- как выйти из ошибки.
Шаг 3. Выписывайте вопросы, а не мнения
Не “текст непонятный”.
А:
- “с меня сейчас спишут деньги?”
- “это удалит файл или весь проект?”
- “почему сервис просит доступ к контактам?”
- “что значит недостаточно прав?”
- “где исправить ошибку?”
Вопросы полезнее вкусовых оценок. По ним видно, какую неопределённость должен закрыть текст.
Шаг 4. Переведите вопросы в правки
У хорошей правки есть задача:
- назвать объект;
- назвать момент;
- назвать последствие;
- назвать путь назад.
Не “сделать понятнее”, а “написать, что деньги спишутся после подтверждения”.
Пять зон, где текст чаще всего ломает сценарий
Ниже — не теория UX-копирайтинга. Это карта мест, где интерфейс чаще всего заставляет человека додумывать.
1) Кнопки и CTA
Кнопка должна объяснять действие, а не прятаться за общим словом.
ОК и Продолжить иногда нормальны. Но в оплате, удалении, доступах и публикации они часто создают тревогу: человек не понимает, что произойдёт сразу после клика.
Отдельно эту тему мы разобрали в статье: текст на кнопке: как назвать CTA.
2) Подсказки в интерфейсе
Плохая подсказка повторяет очевидное:
Введите email.
Пользователь и так видит поле email. Ему нужна не подпись ради подписи, а ответ на сомнение:
- зачем вы просите эти данные;
- кто их увидит;
- можно ли пропустить;
- что будет, если заполнить не так.
Например:
Рабочий email нужен, чтобы отправить приглашения команде. Клиенты его не увидят.
Такая подсказка не украшает форму. Она снимает риск.
3) Текст ошибки в интерфейсе
Плохая ошибка сообщает, что интерфейс сдался:
Что-то пошло не так.
Пользователь остаётся один на один с тупиком. Он не знает, виноват ли он, сломался ли сервис, стоит ли нажимать ещё раз и можно ли не потерять данные.
Рабочий текст ошибки в интерфейсе отвечает на четыре вопроса:
- что случилось;
- почему это могло случиться;
- что делать дальше;
- как вернуться в безопасное состояние.
Например, вместо:
Ошибка валидации.
Лучше:
Ссылка уже занята. Добавьте слово или цифру — например, uxdog-demo-2.
Текст ошибки валидации должен быть ближе к инструкции, чем к диагнозу.
4) Подтверждения и предупреждения
Слабое подтверждение спрашивает:
Вы уверены?
Но человек часто не понимает, в чём именно должен быть уверен.
Хорошее подтверждение называет объект, действие и последствие:
Удалить проект “Весенний запуск”? Все отчёты проекта исчезнут. Это действие нельзя отменить.
Если отмена есть — её тоже нужно назвать:
Отключить тариф? Доступ сохранится до 30 июня, деньги за следующий месяц не спишутся.
Подтверждение не должно пугать. Оно должно честно показать цену действия.
5) Пустые состояния и статусы
Пустой экран — не просто “ничего нет”.
Это место, где пользователь легко решает, что он ошибся, продукт сломан или ему пока нечего делать.
Плохой empty state:
Список пуст.
Хороший:
Здесь появятся отчёты по UX-аудитам. Создайте первый проект, чтобы проверить сценарий или прототип.
Статус работает так же. В обработке слабее, чем Проверяем прототип. Обычно это занимает 2–3 минуты.
Пример: один сценарий оплаты
Возьмём экран выбора тарифа.
В макете есть кнопка Подключить, короткая подпись и модальное подтверждение. Команда знает, что после клика будет ещё один шаг и деньги не спишутся сразу.
Пользователь этого не знает.
Слабая версия:
- кнопка:
Подключить; - подпись рядом:
Продолжить; - подтверждение:
Вы уверены?.
Что человек додумывает:
- “я уже плачу?”
- “можно ли отменить?”
- “что именно подключается?”
Версия сильнее:
- кнопка:
Перейти к оплате; - подсказка:
Деньги спишутся после подтверждения; - подтверждение:
Подключить тариф 990 ₽/мес. Можно отменить в любой момент.
Разница не в красоте текста.
Разница в том, что человек понимает следующий шаг до клика.
Как использовать UXDog аккуратно
Такой сценарий удобно проверять до разработки.
Не обещать себе “истину”. Не пытаться заменить все исследования. А быстро посмотреть, где текст заставляет человека угадывать.
В UXDog для этого можно использовать AI-респондентов как предварительный аудит: дать один сценарий, показать экран или прототип и собрать повторяющиеся сомнения, вопросы и страхи.
Сильный результат такого прогона — не “пользователям нравится текст”.
Сильный результат — список мест, где нужно назвать объект, момент, последствие или путь назад.
Чеклист: что должно быть ясно по тексту
Перед передачей макета в разработку пройдите один сценарий и спросите:
- что произойдёт после клика;
- какой объект изменится, удалится или отправится;
- когда произойдёт действие: сейчас или после подтверждения;
- можно ли отменить действие;
- почему возникла ошибка и что делать дальше;
- зачем интерфейс просит поле, роль или доступ;
- что будет, если ничего не заполнить или пропустить шаг.
Вывод
Хороший текст интерфейса не пытается быть остроумным.
Он делает скучную, но важную работу: снижает неопределённость.
Если человек понимает, что будет дальше, он быстрее проходит сценарий, реже ошибается и меньше боится нажать.
А команда чинит одну строку в Figma, а не целый сценарий после релиза.