UX-копирайтинг для интерфейса: чек-лист микротекстов для кнопок, ошибок, подтверждений и пустых состояний с примерами до/после и быстрыми проверками.
Пользователь редко думает: «Ух ты, какой хороший текст». Зато он сразу чувствует, когда ему неясно, что произойдет дальше. В такие моменты решение простое: не нажимать, закрыть, отложить.
Интерфейс читают не как статью. Его сканируют. Глаза цепляются за короткие ориентиры: «Оплатить», «Далее», «Ошибка», «Бесплатно». Если микротекст не совпадает с ожиданием, мозг тормозит. Лишняя секунда сомнения на шаге оплаты или регистрации легко превращается в выход.
Есть парадокс: «непонятно, что нажмется» иногда хуже мелкого бага. Баг может случаться у 1% пользователей. А неясная кнопка пугает всех 100%. Когда подпись размыта (например, «Продолжить» без уточнения) или звучит рискованно («Подтвердить» без суммы и периода), человек предполагает худшее: спишут деньги, отправят всем, удалят данные. И выбирает безопасный вариант - ничего не делать.
Обычно метрики проседают там, где у пользователя и так есть тревога или нагрузка: регистрация, оплата, формы, первые шаги и активации. На этих этапах пользователь особенно остро спрашивает себя: «Я контролирую ситуацию или интерфейс сейчас сделает что-то за моей спиной?»
Простой пример: человек оформляет подписку. Кнопка «ОК» и подпись мелким шрифтом «условия» создают ощущение подвоха. Та же кнопка, но с текстом «Оплатить 990 ₽ за месяц» и коротким пояснением «можно отменить в любой момент» снимает главный страх и возвращает движение.
Если вы делаете продукт, где важны быстрые решения (например, в TakProsto пользователь создает проект, подключает домен или запускает деплой), микротексты становятся частью доверия. Они отвечают на главный вопрос: что именно произойдет после клика.
UX-тексты чаще всего ломаются не в длинных описаниях, а в микротекстах: там, где нужно быстро понять, что будет дальше и безопасно ли нажимать.
Типовые проблемные места:
Мини-сценарий: человек заполняет форму и видит «Некорректное значение». Он не понимает, речь про номер, дату или индекс. Потом нажимает «Продолжить» и боится, что отправит не то. Даже если все работает, текст создает ощущение риска.
Быстрая проверка: в каждой точке спросите себя, отвечает ли текст за 2 секунды на два вопроса - что сейчас произошло и что мне делать дальше. Если нет, пользователь, скорее всего, остановится.
Хороший UX-копирайтинг убирает лишние вопросы в голове пользователя. Если на экране человек одновременно пытается понять, что от него хотят, что будет дальше и не потеряет ли он деньги, конверсия падает даже без багов.
Одна главная мысль на экран. Если это оплата, не смешивайте ее с обучением и рекламой. Лишнее переносите на следующий шаг.
Пишите действием: что случится после клика. Не «Продолжить», а «Перейти к оплате» или «Создать аккаунт».
Добавляйте конкретику вместо общих слов. Где нужно: срок, сумма, формат. «Код из 6 цифр» понятнее, чем «Введите код».
Снижайте тревогу. Коротко объясните, что безопасно и что можно отменить: «Деньги спишутся после подтверждения», «Можно отменить в любой момент».
Держите один тон во всем продукте. Выберите «вы» или «ты», формально или по-простому, и не прыгайте между стилями.
Конкретика особенно важна там, где цена ошибки высока. «Сохранить» не говорит, что именно сохранится. Лучше «Сохранить изменения». А если действие необратимое, так и пишите: «Удалить проект навсегда».
Пример из сценария: пользователь создает приложение в TakProsto и видит кнопку «Далее». Если заменить ее на «Сгенерировать черновик» или «Открыть план» (когда включен planning mode), человек понимает результат клика и меньше сомневается.
Текст на кнопке - это обещание результата. «ОК» или «Отправить» почти ничего не говорят, поэтому действие чаще откладывают.
Мини-примеры для типовых действий:
Состояния кнопки тоже требуют слов. В загрузке важно показать процесс, а не «подвисание»: «Сохраняем...», «Создаем аккаунт...». Для недоступной кнопки одного серого вида мало: добавьте подсказку, что нужно сделать, чтобы продолжить, например «Заполните телефон, чтобы продолжить».
Вторичная кнопка не должна спорить с основной. Если рядом «Сохранить» и «Отмена», приоритет ясен. Но «Далее» и «Назад» часто путают. Лучше: основная - «Оплатить 990 ₽», вторичная - «Вернуться к тарифам». Если действие рискованное, вторичная кнопка должна быть безопасным выходом: «Отмена», «Не сейчас».
Еще один частый случай: в TakProsto пользователь нажимает «Создать», а дальше непонятно - проект, экран или приложение. Точнее: «Создать приложение» или «Создать проект», а в загрузке - «Готовим проект...». Меньше сомнений - выше шанс, что клик состоится.
Ошибки в интерфейсе читают быстрее, чем любой текст на лендинге. Если сообщение звучит грубо или непонятно, человек не будет разбираться - он уйдет. Хорошая ошибка не пугает и не оправдывается, а помогает закончить действие.
Рабочая структура почти всегда одна и та же: что случилось, что сделать сейчас, что будет с данными (сохранено или нет). Причину добавляйте только если она действительно помогает.
Тон важнее, чем кажется. «Вы ввели неправильно» звучит как обвинение. «Не получилось» или «Не удалось» снижает напряжение и оставляет человека в диалоге.
Форма (телефон)
До: «Неверный формат»
После: «Не удалось сохранить: номер телефона должен быть в формате +7 900 000-00-00. Проверьте код страны и количество цифр.»
Авторизация (пароль)
До: «Ошибка 401»
После: «Не удалось войти: неверная почта или пароль. Попробуйте еще раз или восстановите пароль.»
Оплата
До: «Платеж отклонен»
После: «Платеж не прошел. Банк мог отклонить операцию или не хватило лимита. Попробуйте другой способ оплаты или повторите попытку через пару минут - заказ не потеряется.»
Предупреждение про удаление
До: «Вы уверены?»
После: «Удалить проект? Действие нельзя отменить. Если сомневаетесь, сделайте снимок или экспортируйте исходники.»
Если ошибка на стороне сервера, человеку не нужен диагноз. Ему нужен план. Особенно в продуктах, где пользователь что-то создает (например, приложение в TakProsto): важно прямо сказать, что работа не пропадет.
Что полезно предложить в таких случаях: «Повторить», «Сохранить черновик» или «Сохранено автоматически», «Попробовать позже», «Скопировать детали ошибки» для поддержки (без пугающих кодов на первом экране).
Сообщение об успехе должно подтверждать результат, говорить, где его найти, и подсказывать следующий шаг. Если этого нет, пользователь сомневается, повторяет действие или уходит проверять вручную.
Держите в голове разницу между «успешно» и «принято в работу». «Сохранено» означает, что данные уже записаны. А «Заявка создана» означает только старт процесса. Не обещайте лишнего, если результат появится позже.
Undo помогает там, где ошибки частые и не критичные: удаление, очистка поля, отключение опции, перемещение. Если отмена невозможна, честно скажите почему и предложите безопасный путь (например, «создать копию»).
Пример из TakProsto: вместо «Деплой выполнен» точнее «Деплой запущен. Статус в "Развертывание". Если что-то пошло не так, откатитесь к снимку».
Пустое состояние часто выглядит как баг, даже если все работает правильно. Человек видит пустой экран и думает: «Где мои данные? Я не туда нажал? Оно вообще работает?» Здесь одна фраза может снять тревогу и подсказать следующий шаг.
Хорошее пустое состояние отвечает на два вопроса: почему здесь пусто и что делать дальше. Причина должна быть простой и правдивой: «Вы еще не добавили товары» звучит спокойнее, чем «Список пуст». Затем дайте первое действие, которое реально помогает: создать, импортировать, добавить пример, попробовать демо-данные.
Что проверить в тексте пустого состояния:
Мини-примеры:
Список (проекты, задачи)
До: «Ничего не найдено»
После: «Пока нет проектов. Создайте первый или импортируйте из файла, чтобы продолжить».
Корзина
До: «Корзина пуста»
После: «В корзине пока нет товаров. Вернитесь в каталог и добавьте нужное».
История
До: «Нет данных»
После: «Истории еще нет. Она появится после первого входа или действия в аккаунте».
Аналитика
До: «0»
После: «Пока нет статистики. Подключите источник данных, и здесь появятся графики за выбранный период».
Если вы делаете продукт вроде TakProsto, пустой список приложений не должен выглядеть как ошибка. Лучше прямо сказать: «Вы еще не создали приложение. Нажмите “Создать”, чтобы начать с чата».
Человек заходит в сервис, регистрируется и хочет оплатить подписку. Он уже почти готов, но сомневается: безопасно ли это, что будет дальше, можно ли отменить, что делать, если платеж не пройдет. В этот момент тексты решают больше, чем цвет кнопки.
Типичный путь ломается на мелочах:
Пользователь не чувствует опоры. Он не уверен, что контролирует ситуацию, и чаще закрывает вкладку.
Те же экраны без нового дизайна и разработки, только текст:
Так вы закрываете главные страхи: деньги спишут неожиданно, платеж завис, поддержка не поможет, доступ не появится.
Чтобы писать точнее, соберите живые вопросы из поддержки и продаж. Обычно достаточно пяти:
Чтобы аудит не растянулся, задайте рамки: одна воронка, один сценарий, один день. Например: регистрация - создание первого проекта - оплата.
Соберите все экраны, где у пользователя есть шанс передумать: формы, модалки, ошибки, подтверждения, пустые состояния, платежные шаги. Затем выпишите все микротексты в один документ: заголовки, подсказки, кнопки, ошибки, успехи. Рядом отметьте, отвечает ли текст на вопросы «что будет дальше» и «что от меня хотят прямо сейчас».
Порядок действий на день:
Шаблоны, которые экономят время:
В конце сделайте два быстрых теста. Прочитайте тексты вслух: если вы спотыкаетесь, пользователь тоже. И дайте человеку не из команды пройти сценарий: пусть он своими словами объяснит, что будет после нажатия каждой ключевой кнопки.
Плохие микротексты мешают сильнее, чем кажется: человек не понимает, что будет дальше, и просто уходит.
На кнопке много слов, но мало смысла. «Нажмите здесь, чтобы продолжить оформление заявки» выглядит как абзац и не добавляет ясности. Лучше назвать действие коротко, а детали вынести рядом.
Одно и то же названо по-разному. «Профиль», «Аккаунт» и «Кабинет» в одном продукте заставляют сомневаться. Выберите один термин и используйте его везде.
Пассивные формулировки. «Будет выполнено», «данные будут обработаны» звучит холодно и непонятно. Проще: «Мы сохраним изменения», «Мы проверим оплату и покажем результат».
Обещания, которые сложно выдержать. «Готово за 2 минуты» повышает ожидания и потом вызывает злость. Если срок зависит от чего-то, так и пишите: «Обычно 2-5 минут, иногда дольше».
Ошибка есть, а выхода нет. «Что-то пошло не так» без следующего шага превращает экран в тупик. Дайте маршрут: что делать сейчас и что будет с данными.
Пример: в TakProsto при публикации проекта вместо «Ошибка деплоя» полезнее «Не удалось развернуть приложение: не хватает прав на домен. Выберите другой домен или подключите свой. Мы сохранили изменения, вы не потеряете работу».
Не нужно переписывать весь продукт сразу. Достаточно регулярно проверять микротексты там, где больше всего трафика и денег.
Короткий чек-лист:
Проверка на 10 секунд: прочитайте кнопку и вслух ответьте на вопрос «Что произойдет после клика?». Если ответ получается длинным или неуверенным, текст нужно уточнить.
Мини-план внедрения на день:
Выберите 5 экранов с максимальным трафиком или деньгами (вход, регистрация, оплата, восстановление).
Для каждого экрана отметьте 3 точки риска: CTA, самая частая ошибка, первое пустое состояние.
Сделайте 2-3 варианта текста для каждой точки и выберите самый ясный.
Согласуйте тексты до разработки: так обсуждают конкретные формулировки, а не «идею».
Внедряйте по очереди и фиксируйте изменения.
Если вы работаете в TakProsto, удобно быстро собрать экраны в одном сценарии, попробовать формулировки в planning mode и при необходимости откатиться через snapshots и rollback. Это позволяет проверять гипотезы про тексты без долгих итераций.
Если после правок стало меньше вопросов в поддержку и выросла доля успешных действий (оплат, регистраций, отправок формы), значит, вы попали в правильные точки. Дальше повторяйте тот же цикл для следующих экранов.
Обычно ломают конверсию слишком общие подписи: «ОК», «Далее», «Продолжить», «Подтвердить». Они не обещают результат действия, поэтому пользователь начинает сомневаться и откладывает клик. Заменяйте их на глагол + понятный итог, а для платежей добавляйте сумму или четко показывайте ее рядом.
Потому что в интерфейсе люди не читают, а сканируют и принимают решения за секунды. Если микротекст не отвечает на вопрос «что будет после клика», мозг выбирает безопасный вариант — ничего не делать. Даже небольшая пауза на регистрации или оплате легко превращается в уход.
Хорошая ошибка говорит простыми словами, что не получилось, и сразу дает следующий шаг. Самое полезное — указать конкретное поле или формат и коротко объяснить, потерялись данные или нет. Диагнозы вроде «401» оставьте для деталей, но не делайте их главным текстом сообщения.
Снимайте главный страх: что произойдет с деньгами и можно ли отменить. Лучше всего работают тексты, где прямо сказано действие и результат, например «Оплатить 990 ₽ за месяц», и рядом одно короткое уточнение про контроль, например что списание будет после подтверждения или подписку можно отменить.
Пишите честно и конкретно: что именно произошло и что дальше делать пользователю. «Готово» почти ничего не дает, а «Оплата прошла, доступ активен до…» или «Деплой запущен, статус можно проверить в…» возвращает ощущение контроля. Если это не финальный результат, так и называйте: «принято в работу», «в процессе».
Пустой экран часто выглядит как поломка, поэтому важно объяснить причину и дать первое действие. Простая формула: «почему здесь пусто» плюс «что сделать сейчас», без шуток и обвинений. Например, в списке проектов можно прямо сказать, что проектов еще нет, и предложить создать первый.
Если действие необратимое, говорите об этом прямо и без эвфемизмов. Пользователь должен понимать масштаб последствий до клика, иначе он либо не нажмет, либо потом будет злиться. Дополнительно помогает безопасная альтернатива: предложить снимок, экспорт или перенос в корзину, если это реально есть в продукте.
Выберите одну форму обращения и не меняйте ее между экранами, иначе это выглядит как «разные продукты» и снижает доверие. Дальше держите одинаковые названия сущностей: если вы решили, что это «проект», не называйте то же самое «приложением» или «рабочей областью» в соседнем шаге. Это особенно важно в сценариях, где пользователь делает быстрые действия, например создает проект и запускает деплой в TakProsto.
Пройдите один ключевой сценарий как новый пользователь и выпишите все микротексты: кнопки, подсказки, ошибки, успехи, пустые состояния. Затем для каждой фразы ответьте на два вопроса: «что сейчас произошло» и «что мне делать дальше». Если ответ не помещается в одно предложение, текст обычно стоит уточнить.
Самый простой способ — наблюдать, где пользователи замирают или возвращаются назад, и сверить это с текстом на экране. Дополнительно смотрите рост обращений в поддержку по одному и тому же вопросу и долю повторных попыток в формах. Если после правок стало меньше ошибок ввода и больше завершенных действий, значит, микротекст попал в проблему.
