ux-copy

UX-тексты на русском языке: кнопки, формы, ошибки, пустые состояния, онбординг, подтверждения, уведомления, пуши и микрокопия. Use this skill whenever the user asks to write, rewrite, review, choose,

SKILL.md

GitHub

UX-copy

Задача скилла — тексты интерфейса. Текст в интерфейсе отвечает на два вопроса пользователя: что происходит и что мне делать. Хорошая микрокопия пишется от сценария: важно, что было до экрана, что будет после действия и что пользователь сейчас чувствует.

Метод основан на практиках Людмилы Сарычевой (gladlax.ru) и собран совместно с Никитой Архиповым (niar42.com).

Шаг 0. Контекст

Если в проекте есть файл .agents/redpolitika.md — прочитай его первым: там словарь продукта, обращение к пользователю и тональность. Если файла нет, а интерфейсных текстов много, предложи создать его скиллом redpolitika.

Перед текстом выясни:

  1. Что за экран или сообщение.
  2. Что пользователь сделал до этого.
  3. Что должно произойти после.
  4. Что пользователь может чувствовать: спешит, злится, боится потерять данные, просто выбирает.
  5. Какие ограничения есть: длина, платформа, кнопки, юридический текст.

Режимы

  • Варианты (options) — дать 2–3 формулировки и объяснить разницу.
  • Правка (rewrite) — было/стало/правило для существующих текстов.
  • Аудит (audit) — найти проблемы сценария и текста без полной переписи.

Если режим не назван, дай варианты: для интерфейса полезно выбрать из нескольких точных решений.

Глубина разбора

Подстраивай ответ под собеседника. Редактору можно отвечать терминами метода. Если пользователь не из редакторского мира — объясняй по-простому: не «голословное утверждение», а «здесь написано "многие считают", но непонятно, кто и откуда это известно». Термины либо избегай, либо поясняй в скобках, разбор давай короче: три главные правки полезнее пятнадцати.

Процесс

1. Сценарий

Опиши сценарий словами пользователя: «я хочу…», «я сделал…», «я не понимаю…». Детали — в references/printsipy.md.

Правило сценарий впереди экрана: сначала путь пользователя, затем текст элемента.

2. Элемент

Определи тип элемента: кнопка, заголовок, поле, плейсхолдер, чекбокс, тултип. Детали — в references/elementy.md.

Правило каждый элемент делает свою работу: кнопка называет действие, заголовок объясняет состояние, текст рядом даёт детали.

3. Ошибки и состояния

Если это ошибка, пустое состояние, загрузка или опасное действие, проверь, что текст объясняет случившееся и следующий шаг. Детали — в references/oshibki-i-sostoyaniya.md.

Правило что случилось и что делать: пользователь должен понять ситуацию без внутреннего кода системы.

4. Уведомления

Для пушей, писем, тостов и снекбаров проверь, нужно ли вообще писать. Если сообщение не меняет действие пользователя, часто лучше молчать. Детали — в references/uvedomleniya.md.

Правило польза сообщения: уведомление вмешивается во внимание пользователя и должно окупать это вмешательство.

5. Тональность

Сверься с ../redaktura/references/tonalnost.md: без вины, давления, ложной срочности и «упс». Слова пользователя важнее слов системы.

Формат ответа

В колонках «Почему» и «Правило» называй правила метода по имени («событие и шаг», «действие на кнопке», «слова пользователя», «последствие видно») — так пользователь учится, а не просто получает строки.

Варианты

| Элемент | Вариант 1 | Вариант 2 | Почему |
|---|---|---|---|

Правка

| Было | Стало | Правило |
|---|---|---|

Аудит

## Диагноз
[2–4 предложения о сценарии и главной проблеме]

## Главные правки
| Элемент | Проблема | Как исправить |
|---|---|---|

## Что ещё нужно узнать
[сценарные дыры, ограничения, системные причины]

Чего не делать

  • Не писать от экрана. Сначала сценарий, затем текст элемента.
  • Не выдумывать системные факты. Сроки («несколько минут»), каналы ответа («напишем на почту») и поведение системы легко подставить по привычке — но если они не заданы пользователем, это выдумка. Пиши плейсхолдер «[срок: уточнить]» или задай вопрос.
  • Не винить пользователя. Текст помогает выйти из ситуации и сохранить контроль.
  • Не ставить «ОК» там, где есть действие. Кнопка должна говорить, что произойдёт.
  • Не шуметь уведомлениями. Если пользователь не должен ничего делать, часто лучше молчать.

Связанные скиллы

  • redaktura — финально проверить тональность, слова и ритм интерфейсных текстов
  • redpolitika — словарь продукта и тональность
  • statya — статьи, посты и длинные объясняющие материалы