Как создавать тексты для интерфейса правильно

Материал подготовлен по докладу Натальи Гермогентовой, Lead UX-Writer Яндекса, который прошел на онлайн-конференции UX-Марафон, посвященный текстам.

Свежий выпуск онлайн-конференции UX-Марафон про тексты в интерфейсе состоится 17 декабря 2022 года.

Любопытно, что с фразой «текст – последнее дело» могут согласиться как заказчики текста, так и сами редакторы. Правда, смотрят при этом на ситуацию они с абсолютно разных сторон.

Что понимает под этой фразой заказчик? Как правило, для него это означает, что редактор будет последним человеком, которого подключат к работе над проектом. Обычно это выглядит так: уже на завершающем этапе редактору демонстрируют готовый интерфейс и говорят – смотри, вот что мы сделали, вот тут нужно объяснить, как всё работает, а здесь мы оставили место под описание трёх главных продуктовых фичей.

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

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

Теперь посмотрим на фразу «текст – последнее дело» с точки зрения UX-редактора. Для редактора она означает, что создание конкретных формулировок – это самый последний этап долгого и трудоёмкого процесса работы с информацией.

Сначала нужно разобраться со смыслами – что мы хотим донести до пользователя, о чём хотим ему рассказать, какие действия получить? Затем расставить приоритеты: что из этой информации действительно важно пользователю, что можно отодвинуть на второй план или передать, используя другие каналы?

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

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

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

Ещё один вопрос, который волнует многих руководителей продуктовых команд – сколько времени нужно, чтобы проработать качественный UX-текст?

Наверно, каждый редактор не раз сталкивается с ситуацией «слушай, мне там всего ничего текста нужно, можешь быстренько набросать?» И действительно, если смотреть с точки зрения заказчика, то и вправду кажется – ну что там делать? Заголовок, один-два лейбла, чекбокс, две кнопки и пара маленьких абзацев текста – максимум 200 знаков. Работы минут на 15-20.

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

Однако, готовый текст – это лишь видимая, надводная часть айсберга, по которой обычно измеряют объём работы редактора, забывая при этом, что подводная часть значительно больше.

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

Затем необходимо прикинуть предварительную версию текста, в идеале – показать её пользователям, получить фидбэк и на его основе что-то добавить или изменить… И только после этого можно приниматься за тексты в их финальном выражении, чтобы написать те самые 200 знаков.

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

Когда мы говорим о UX-тексте, необходимо помнить ещё и о том, что зона влияния текста не ограничивается интерфейсом, а охватывает весь продукт. В неё входит, например, то, как ваша служба поддержки общается с пользователями по телефону, в письмах и в мессенджерах.

Текст присутствует во всех письмах, смс и push-уведомлениях, которые отправляются пользователю, в социальных сетях и даже в оффлайне. Буклеты, листовки письма, которые пользователь получает в конверте вместе с банковской картой – это тоже определённым образом оформленная текстовая информация, которая может вызывать у человека те или иные эмоции, а значит, тоже формировать его UX и впечатление от продукта.

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

Как это понимать?

«Нам нужно получить от юзера вот такие данные» – это задача, потому что здесь речь идёт о том, какая у нас цель. Нам нужно получить от пользователя данные – как именно, каким способом, мы не знаем и не указываем. Придумать, как это сделать лучше всего – дело UX-редактора.

«Вот форма с набором данных, надо подредактировать» – а вот это решение, здесь редактору заранее указывают, в какой форме, каким способом ему нужно выполнить задание.

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

Наглядным примером эффективности стратегии «давать задачу, а не решение» может служить процесс регистрации в Яндекс Драйв. Вместо, казалось бы, очевидного решения – стандартной формы с лейблами, полями и кнопками, продуктовая команда использовала простой, понятный и живой диалог с чат-ботом, который постепенно запрашивает все необходимые данные и даже показывает, как правильно сделать селфи с паспортом.

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

Правильно формулировать UX-тексты поможет маленький чек-лист из четырёх коротких вопросов:

Этот чек-лист прекрасно подходит не только для крупных проектов, но и для проработки одного небольшого блока в интерфейсе.

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

Чтобы исправить этот дисбаланс, достаточно вместо безликого «Email» поставить «Куда прислать чек». В результате мы получаем решение, которое учитывает обе стороны. Мы хотим получить почту – мы спрашиваем почту. Человеку нужно получить чек – мы пишем про чек. И вероятность того, что человек заполнит это поле, представляется в этом случае гораздо выше.

Как быть, если у вас нет UX-редактора; где найти редактора, что делать, пока вы его ищете, и как правильно составить тестовое задание; как человеку, работающему с текстами для интерфейса, прокачать свои профессиональные скиллы и какие принципы учитывать в работе – смотрите докладе Натальи Гермогентовой.

И приглашаем на новое событие про тексты в интерфейсе, которое состоится 17 декабря 2022 года.

Темы докладов:

Микрокопирайтинг в дизайне.

Дарк паттерны и другие неприятности в интерфейсном тексте.

Как написать хороший текст, если ты не UX-писатель.

Инструкции и чек-листы по написанию текстов для интерфейса.