Текст на кнопке: как назвать кнопку на оплате, удалении и доступе

На ревью оплаты всё выглядит спокойно.

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

В команде никто не спотыкается. Все знают, что после клика будет ещё один шаг подтверждения. Деньги не спишутся сразу. Тариф можно отменить.

Пользователь этого не знает.

Он видит Подключить и за секунду пытается угадать: это уже оплата или ещё следующий шаг? будет подтверждение? можно ли вернуться назад?

Если кнопка не отвечает, человек начинает защищаться. Перечитывает экран. Откладывает клик. Уходит спросить коллегу. Выбирает более безопасный вариант.

Текст кнопки — не подпись на красивом прямоугольнике. Это маленький договор между интерфейсом и человеком: что будет после клика и можно ли это отменить.

Поэтому CTA в оплате, удалении, доступах и других чувствительных шагах нужно проверять до разработки. Пока одну строку можно поменять в Figma, а не распутывать уже собранный сценарий.

Если нужна рамка шире (как проверять прототип до разработки и чем отличаются подходы), вот базовая статья: /blog/testirovanie-interfeisa-prototipa-do-razrabotki.

А если вы готовите Figma-прототип к проверке (состояния, данные, “не шуметь недоделками макета”), пригодится: /blog/podgotovka-figma-prototipa-k-yuzabiliti-testirovaniyu.

Почему люди боятся нажать (и почему это не «про цвет кнопки»)

В теории кнопка — просто действие.

На практике кнопка часто означает:

• спишут деньги;
• удалят данные;
• откроют доступ кому-то ещё;
• опубликуют что-то публично;
• запустят процесс, который потом сложно отменить.

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

Команда внутри продукта знает контекст. Пользователь — нет. Внутри команды очевидно, что «Подключить» откроет подтверждение, а не списание. Снаружи — не очевидно. И это не вопрос эстетики. Это вопрос доверия.

Кнопка как обещание: что человек пытается понять за секунду

Текст на кнопке — это обещание результата.

Представьте, что CTA — это ручка двери. По ней человек должен понимать, что за дверью: коридор, выход или «служебное помещение».

Кнопка должна отвечать хотя бы на один из вопросов:

• что именно произойдёт (действие + объект);
• когда это произойдёт (сразу / после подтверждения / после проверки);
• на какую цену вы подписываете человека (если это деньги);
• можно ли откатить (если шаг необратимый).

Если вокруг кнопки всё уже объясняет и риск низкий — можно короче.

Если кнопка стоит в «моменте решения» — короткий текст становится опасным.

Пять зон риска, где нельзя писать «ОК» и «Продолжить»

Ниже — простая карта. Если кнопка попадает в одну из этих зон, текст должен быть конкретнее обычного.

1) Деньги

Плохие кнопки: Подключить, Продолжить, ОК.

Вопросы, которые остаются без ответа:

• деньги спишутся сейчас или будет подтверждение?
• это разовая оплата или подписка?
• есть ли пробный период?
• можно ли отменить?

Рабочие варианты текста:

• Перейти к оплате (если дальше будет выбор способа/подтверждение);
• Оплатить 990 ₽ за месяц (если это действительно действие оплаты);
• Начать пробный период (если списания пока не будет).

2) Данные

Когда у вас «удалить», «очистить», «сбросить», «заменить», «перезаписать».

Если текст кнопки не называет объект, мозг дорисует самый дорогой вариант.

Вместо:

• ОК
• Подтвердить

лучше:

• Удалить проект
• Удалить черновик
• Архивировать проект
• Сбросить настройки уведомлений

3) Доступ

Приглашения, роли, «дать доступ», «сделать админом», «поделиться».

Самая частая ошибка — скрыть объект действия за «Пригласить». Пригласить куда? С какими правами? На какой срок? Можно ли отозвать?

Хорошо работает связка:

• кнопка: Пригласить в проект
• рядом текстом (не на кнопке): «можно отозвать доступ в любой момент»

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

4) Публичность

Опубликовать, отправить всем, показать клиентам, сделать видимым.

Там, где есть аудитория, есть страх: «я нажму и будет поздно».

Вместо Опубликовать иногда честнее:

• Посмотреть перед публикацией (если дальше предпросмотр);
• Опубликовать для всех / Опубликовать для команды (если есть режимы).

5) Необратимость

Запуск миграции, закрытие периода, отправка отчёта, выпуск релиза.

Если шаг реально необратимый, текст должен быть таким же честным.

Короткое «Запустить» без объекта — почти всегда плохая идея.

Чеклист: 10 вопросов к тексту кнопки

Этот чеклист нужен не UX writer’у. Он нужен PM и дизайнеру на ревью прототипа — в момент, когда исправление стоит один комментарий в Figma.

1. Понятно ли, что произойдёт, если читать только кнопку? 2. Есть ли глагол + объект там, где без объекта неясно? 3. Если это деньги: ясно ли «сейчас списание или будет подтверждение»? 4. Если это деньги: нужно ли показать сумму/период на кнопке или рядом? 5. Если это удаление: назван ли объект («Удалить проект», а не «ОК»)? 6. Если это доступ: ясно ли, кому и какой доступ выдаём? 7. Если это публикация: ясно ли, для кого станет видно? 8. Если действие отложено (откроется модалка/настройки): не обещает ли кнопка «сделать», хотя она на самом деле «перейти»? 9. Есть ли рядом короткое «успокоение», если шаг тревожный: «можно отменить», «спишем после подтверждения», «ничего не удалим без подтверждения»? 10. Не конфликтует ли кнопка с заголовком/текстом выше (обещаем одно, делаем другое)?

Как быстро проверить CTA до разработки (три дешёвых способа)

1) Прочитать экран как чужой

Закройте всё, кроме скрина. Не объясняйте себе контекст.

Ответьте одной фразой: «Что будет после клика?».

Если ответ строится только из памяти команды — это красный флаг.

2) Прогнать через 3–5 «слепых» вопросов

Спросите человека (или даже коллегу не из команды) без вводной лекции:

• Что означает эта кнопка?
• Что произойдёт после клика?
• Есть риск, что что-то спишется/удалится/разошлётся?
• Если вы ошиблись — как вернуться назад?

Если ответы разные — дело не в человеке. Дело в тексте.

3) Быстрый прогон через AI-респондентов

Не чтобы получить «оценку дизайна».

А чтобы поймать повторяющийся страх и неясность, пока это ещё не релиз.

Как прогнать текст кнопки через UXDog (быстрый сценарий)

Сценарий проверки:

1) Возьмите один экран из прототипа: оплата, удаление, приглашение, публикация. 2) Сформулируйте задачу в одну фразу: «вы хотите X». 3) Попросите респондента:

• объяснить, что произойдёт после клика;
• назвать риск, который он видит;
• сказать, чего ему не хватает для уверенности.

4) Посмотрите, какие формулировки повторяются между респондентами.

Если повторяется «страшно нажать» / «непонятно, что будет» / «вдруг спишут» — это не косметика. Это UX-риск сценария.

На практике такой прогон — это быстрый способ снять «командную слепоту»: когда всем внутри очевидно, а внешнему человеку — нет.

Пример: «Подключить» на тарифе (до/после)

Сцена из жизни SaaS:

На экране тарифов всё выглядит прилично. Список преимуществ есть. Цена есть. Кнопка есть.

Проблема начинается в голове пользователя.

Кнопка Подключить без контекста читается как «сейчас начнётся списание».

До

• кнопка: Подключить
• рядом: ничего, кроме списка преимуществ

После (один из рабочих вариантов)

• кнопка: Перейти к оплате
• рядом мелко: «спишем после подтверждения»

или:

• кнопка: Оплатить 990 ₽ за месяц
• рядом мелко: «можно отменить в любой момент»

Это не «магия копирайтинга». Это снятие неопределённости. В теории человек и так “должен понять”. На практике он просто выбирает кнопку, которой меньше всего не доверяет.

FAQ (коротко)

«ОК» — когда можно

Когда действие безопасное и контекст очевиден. Например, закрыть информационное сообщение «Сохранено». Там «ОК» не ломает ожидания.

Когда шаг рискованный — «ОК» почти всегда экономит секунду для команды и съедает доверие пользователя.

«Продолжить» vs «Дальше»

Если за кнопкой нет риска и пользователь в линейном сценарии, оба варианта живут.

Если это «момент решения» (оплата, удаление, доступ) — лучше назвать объект: Перейти к оплате, Удалить проект, Пригласить в команду.

Нужно ли писать сумму на кнопке

Если это финальный шаг оплаты — часто да: сумма на кнопке снижает риск неожиданности.

Если сумма может поменяться на следующем экране, лучше не обещать на кнопке то, чего вы ещё не зафиксировали.

Вывод

Текст кнопки — не место для творчества. Это место для ясности.

Если шаг безопасный — можно короче.

Если шаг про деньги, данные или доступ — конкретика дешевле, чем переделка после релиза.

И это можно поймать на прототипе. Ещё до разработки.

Дёшево.

До разработки.