Текст в интерфейсе

Мы хотим, чтобы все клиенты знали один и тот же Контур — помощника и эксперта, который говорит доброжелательно и понятно. С какой интонацией мы общаемся, что такое текст в стиле Контура и как его написать смотрите в Редполитике.

В этом гайде собраны рекомендации о том, как написать хороший текст для интерфейса.

Когда пишете текст, исходите из того, что:

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

Чтобы хорошо справляться со своей задачей, текст должен быть достаточно простым, достаточно коротким и достаточно полезным. Не пытайтесь убрать как можно больше слов или получить 10 баллов по шкале Главреда. Ищите баланс между крайностями, так вы придёте к хорошему результату.

Текст станет заметно проще, если прибраться в его синтаксисе, то есть разобраться с составом и порядком слов в предложении. Как это делается, описано в разделах Редполитики «Понятные предложения» и «Простые слова».

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

Эти рекомендации касаются окон всех форматов и назначений — полноценных модальных окон, мини-модалок, информационных сообщений и предупреждений.

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

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

Теперь нужно сообщить пользователю об изменениях в законе и предложить ему подписаться на уведомления, чтобы ничего не пропустить. Плохой вариант — начинать с приветствия или обращения к аудитории.

Неправильно

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

Правильно

Если цель в том, чтобы пользователь подписался:

Правильно

Если целей несколько и все важны, придётся выбирать.

Чем опытнее становится пользователь, тем более бегло он читает сообщения сервиса. Он привыкает к набору сообщений, которые ему встречаются, и начинает различать их по первым словам в заголовке.

Формулируйте заголовки разных, и тем более похожих сообщений по‑разному. Тогда продукт будет помогать пользователю использовать себя быстрее.

Неправильно

Правильно

Это поможет и работе поддержки — они спрашивают у пользователя, какую ошибку он видит. Чем меньше заголовки сообщений похожи друг на друга, тем легче сотруднику поддержки определить проблему.

В заголовке мы написали суть, а в основном текстовом блоке можно рассказать подробности:

• что случилось,
• что теперь делать,
• что делать или чего не делать в будущем, чтобы избежать этой проблемы.

Ни один из этих пунктов не обязателен.

Последний пункт необходим, когда появление ошибки зависит от действий пользователя.

Основной текстовый блок может дублировать заголовок, если даёт больше информации.

Неправильно

Правильно

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

Неправильно

Правильно

Если в тексте мы не просим выполнить какое‑то конкретное действие, то задаём вопрос «Что пользователь может захотеть сделать?» и даём ему выходы в эти сценарии.

Правильно

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

Правильно

Подробнее про модальные окна читайте в гайде.

Модалки используются для подтверждения действий в продукте. Это не очень эффективный, но очень простой в реализации способ защитить пользователя от случайного уничтожения данных.

Неправильно

В момент появления такого подтверждения пользователь всё ещё думает, что удаляет то, что нужно. Поэтому такие подтверждения почти не помогают.

Вы немного улучшите ситуацию, если более конкретно опишете последствия, и сделаете это в мире пользователя. Например, у пользователя есть несколько доверенностей для отправки отчётности, и он удаляет доверенность не для тех организаций.

Правильно

Этот приём работает потому, что:

• само появление списка может заинтересовать пользователя, и заставить вникнуть в то, что он делает;
• список с конкретикой может выглядеть «не так» — быть заметно длиннее или короче того, что ожидал пользователь.

Даже при этом подтверждения остаются наивным решением для защиты данных от случайного уничтожения.

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

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

С тостами и хинтами всё просто — там не бывает «длинного» текста. Даже если внутри текст разбит на пару предложений, всё равно это подпись.

В тултипах разброс больше, но почти всегда это тоже подпись.

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

Существуют пограничные случаи, когда текста относительно много, и его можно и набрать одним абзацем, и разделить на два. В первом случае применяется правило для подписи, во втором — обычные правила набора абзаца, когда каждое предложение заканчивается точкой.

Подпись к полю говорит пользователю, какая информация в нем должна быть, а подсказка-плейсходер помогает понять, как именно можно его заполнить. Например:

• какими способами можно ввести данные

• по каким реквизитам работает поиск

• как отформатировать данные, если поле не делает это автоматически,

• также подсказка может помочь пользователю найти нужные данные.


В этом примере — перевод денег за границу через банк-посредник, и нужно указывать не такой же счёт, как для обычных переводов. Это будет ценной подсказкой для предпринимателя, который привык указывать счета, начинающиеся на 407 и 408.

Подсказка не нуждается в глаголах «введите», «укажите», «заполните» и т.д., так как ввод следует из контекста.

Неправильно

Правильно

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

Неправильно

Правильно

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

Неправильно

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

Правильно

Правильно

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

• с пользователем разговаривает компания Контур,
• «робот» сообщает пользователю о чём‑то.

Каждая модальность уместна в определённом наборе случаев. Робот сообщает о событиях сервисе, в том числе на почту или по СМС. Контур объясняет, что происходит, рассказывает о фичах и предупреждает об изменениях в работе сервиса.

Если цель текста — коротко сообщить о результате действия, которое пользователь совершил недавно, то персонифицировать текст не нужно, говорит робот. Коротко и по делу.

Неправильно

Правильно

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

Неправильно

Правильно

В рассылках с пользователем говорит компания Контур или команда продукта. Так удобнее рассказывать о новых возможностях, но это ещё важнее, если тема непростая. Например, изменения в тарифах или в условиях обслуживания.

Пишите от первого лица: «мы», «Контур», используйте название сервиса.

Неправильно

Правильно

Раз мы пишем от первого лица, уместны и формы вежливости — нужно здороваться и прощаться, а из подписи в конце письма должно быть понятно, кто эти «мы».

Когда мы рассказываем пользователю о том, что и почему произошло, или как работает какой‑то процесс, то говорит Контур. И он делает это в интонации помощника.

Для этого мы убираем страдательный залог и добавляем действующее лицо: про себя пишем от первого лица и явно указываем других действуюищх лиц.

Неправильно

Правильно

Спецэффект такого подхода: текст может обрастать важными подробностями. Потому что когда мы «пришлём» ссылку, хочется указать, как именно, а когда она «придёт» (сама), то способ отправки не напрашивается.

А ещё, явное указание действующего лица помогает не допускать разночтений.

Неправильно

Правильно

В этом примере пользователь точно будет знать, что комиссию возьмёт госорган, а не Контур.

Тем более это полезно, когда в одном сообщении больше одного действующего лица. Это могут быть пользователь, Контур и третьи лица — госорганы, партнёры, сотрудники нашего клиента.

Местоимение «вы» пишется со строчной буквы, если не стоит первым словом в предложении.

Уважение к пользователю мы передаём смыслом и тональностью текста.

Если это не первое слово в предложении, также пишутся со строчной: «клиент», «компания».

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

Правильно

Не склоняется только «СКБ Контур», из-за аббревиатуры. Зато можно просклонять родовое слово перед ним.

Неправильно

Правильно