Книга Торри Подмайерски «Strategic Writing for UX» предлагает системный подход к созданию текстов в интерфейсах. Автор подчёркивает, что стратегическая цель UX-текста – одновременно решать задачи организации и задачи пользователя. Иными словами, тексты должны помогать бизнесу достигать своих целей и одновременно отвечать потребностям людей.
Например, в транспортном приложении TAPP организация стремится привлечь и удержать пассажиров, а сам человек хочет просто вовремя добраться до нужного места. Успех UX-контента зависит от понимания этой двойственности: тексты выстраиваются так, чтобы, с одной стороны, реализовывать ключевые бизнес-задачи (привлечение, конверсия, вовлечение, повторные посещения), а с другой – облегчать путь пользователя, помогая ему решить его личную задачу.
Этапы взаимодействия можно представить как «добродетельный цикл» (virtuous cycle) организации и пользователя. Организация начинает с привлечения людей, затем проводит онбординг и вовлечение, а в финале стремится превратить активных пользователей в лояльных поклонников, которые сами рекомендуют продукт.
Пользователь же с самого начала просто изучает систему и выбирает нужную опцию – ему важнее проверить, что сервис выполнит обещанное. Задача UX-текста – вести пользователя через эти этапы. На этапе привлечения уместны маркетинговые материалы (реклама, страницы продукта, отзывы и т.д.), которые позволят человеку “разведать” опыт и принять решение. Когда пользователь уже взаимодействует с продуктом, тексты интерфейса (заголовки, подсказки, уведомления и пр.) подсказывают следующие шаги и оформляют брендовый голос. Подбирая текст к этапу пути, дизайнеры и копирайтеры помогают пользователю и бизнесу двигаться вперёд в унисон.
Автор резюмирует: «Повсюду, на всех этапах, контент помогает организации и человеку достигать своих целей; какой именно контент нужен – зависит от того, на каком этапе цикла находится человек». Таким образом, стратегический подход к тексту – это прежде всего выстраивание контента в соответствии с логикой пользовательских сценариев и стратегией бизнеса.
Голос продукта
По словам Подмайерски, важно также установить единый голос продукта. Голос – это совокупность правил и руководств, помогающих тексту отражать ценности бренда и задачи пользователя. Для этого автор рекомендует составить «voice chart» – таблицу с критериями голоса (концепции, словарь, краткость/длину фраз, грамматику, пунктуацию, стиль капитализации) и связать их с ключевыми принципами продукта. В каждой строке таблицы описываются конкретные примеры или правила: например, какой тон употреблять в экстренных сообщениях, каких слов избегать, насколько «разговорным» должен быть язык. Этот инструмент помогает команде принимать решения при написании текста и соотносить фразы с желаемыми ценностями бренда. Так, голос остаётся постоянным, а тон может меняться в зависимости от ситуации: реклама, сообщение об ошибке, удачного завершения – каждый пример требует своего тона, но всё равно ощущается как часть одного бренда. Голос продукта строится на его ключевых принципах (product principles). Эти принципы определяют, какими должны быть эмоции и сообщения в интерфейсе. Если принципы сформулированы с командой заранее, их можно перенести в voice chart; если нет – UX-копирайтер сам может выяснить их через интервью с заинтересованными лицами. В итоге voice chart превращается в «маячок»: при сомнениях, какой фразой оформить кнопку или предупреждение, команда сверяется с таблицей, чтобы текст соответствовал заявленному тону и задачам бренда.
Шаблоны текстов в интерфейсах
Подмайерски выделяет набор паттернов (шаблонов) UX-текста, которые встречаются практически в любом интерфейсе. Для каждого паттерна автор приводит его назначение, определение и примеры. Основные шаблоны:
- Заголовки (Titles). Назначение – сразу дать понять, где находится пользователь и какое действие он может совершить. Заголовок обычно располагается вверху экрана и является первым текстом, который человек читает. Поэтому он должен контекстуально «ориентировать» пользователя: это может быть название приложения (брендовый заголовок на главном экране), название раздела или конкретной задачи. Подмайерски различает четыре вида заголовков (от имени бренда до описания единственного действия), но ключевая идея в том, чтобы заголовок ясно обозначал суть экрана и мотивировал к дальнейшим шагам. Например, если экран предназначен для создания учётной записи, заголовок «Создать аккаунт» сразу сообщает пользователю, какая операция здесь выполняется.
- Кнопки, ссылки и другие команды. Назначение – позволить человеку перейти к следующему шагу или выполнить действие. Это самые интерактивные тексты («рассказы», кнопки, ссылки) – они как бы реализуют «речь» пользователя, задают следующий вопрос системе. Кнопка должна быть короткой (1–2 слова), конкретной и написанной так, как говорили бы сами люди. Обычно используют глагол в повелительном наклонении («Отправить», «Оплатить »), часто с уточнением («Оплатить $308.48»). В книге приводится пример, как в клубном приложении The Sturgeon Club кнопка «Pay $308.48» подчёркивает действие и сумму сразу в тексте кнопки. Важно строить последовательность кнопок как диалог: первостепенное действие ставится выше (или в начало списка), вторичные – ниже. Если экран содержит заголовок вида «Создать аккаунт», то и текст кнопки стоит сделать «Создать аккаунт», а не общий «Сохранить» – такая симметрия убирает неясность.
- Описания (Descriptions). Назначение – дать дополнительную информацию о том, что происходит, чего ожидать, заодно укрепить бренд и снизить юридические риски. Описание – это поясняющий текст (пара фраз, предложения или небольшой абзац), не кликабельный. Он нужен, когда пользователю важно понять контекст или условия действия. Например, если человек ожидает определённого результата или видел какие-то особенности (как в правилах игры ’appee или рекомендациях по льготному проездному в TAPP), описание напомнит или разъяснит эти детали. Автор предупреждает, что описания часто игнорируются («стена текста»), поэтому их нужно делать очень короткими, разбивать на абзацы и писать простыми словами. Также желательно избегать мелких «звёздочек» с «бегущими ссылками» – они снижают доверие. Если в описании всё же много условий, можно предложить их опционально (например, отдельной ссылкой «Все условия»), чтобы пользователь по желанию мог углубиться. Книга иллюстрирует примеры: например, в сообщениях клуба The Sturgeon Club внизу добавлено короткое описание о безопасности системы (удаляются через 30 дней), а в экране правил ’appee выводится длинный список правил (basic rules) для ознакомления и нажимается кнопка «все правила» при необходимости.
- Пустые состояния (Empty States). Назначение – обосновать отсутствие контента и вызвать интерес, когда контента ещё нет. Часто интерфейсы проектируются под идеальную ситуацию, когда у пользователя уже есть наполнение (сообщения, сохранённые изображения и т.п.). Но при первом запуске экран может «пустовать». В пустом состоянии заголовок, иллюстрация и, возможно, описание вместе с призывом к действию объясняют, что нужно сделать. Текст в таких экранах обычно обнадёживает («Кажется, вы здесь впервые») и приглашает к активностям (кнопка «Начать»). Подмайерски подчёркивает, что нужно указать ожидание – это пустота намеренная (а не баг) – и добавить элементов воодушевления или бренд-голоса. Например, на пустом экране календаря можно показать заголовок «Ничего не запланировано» и текст «Приготовьтесь к новому дню!» вместе с кнопкой «Добавить событие».
- Метки (Labels). Назначение – назвать или описать статические элементы интерфейса, чтобы снизить усилия на понимание. Метки – это обычно существительные или словосочетания, поясняющие иконки, поля, секции или статусы (например, «Город» у поля ввода, «Цена» над ценником, «Нет оплаты» в таблице счетов). Они короче описаний и не предлагают действий, а лишь информируют о текущем состоянии. Метки должны использовать конкретные понятные слова без жаргона и соответствовать естественному языку пользователей. Книга советует тестировать метки на понятность: если слово «Баланс» смущает, найти альтернативу. Примеры: в TAPP подписи шагов покупки (Progress Labels) меняются в зависимости от статуса, а в приложении ’appee рядом с иконками показаны числа с сокращениями «1k+» (voice игры – мало слов). При локализации стоит учесть особенности языка (слова типа «by»/«for» могут не работать в других языках).
- Элементы управления (Controls). Назначение – показать возможные настройки и их состояние. Это надписи у переключателей, флажков, слайдеров и т.п. У каждой настройки обычно две части текста: имя настройки и её состояние. Имя – существительное или глагольная фраза, понятная пользователю (например, «Показывать события»). Состояние – например, «включено/выключено», «вкл/выкл», «Красный/Зелёный» и т.д. При этом важно выбирать такие слова, чтобы во всех состояниях сохранялся смысл (если «Активировать» – значит «Неактивно/Активно»). Автор рекомендует группировать похожие переключатели и давать им общий заголовок для контекста (как в настройках The Sturgeon Club, где показано несколько параметров через параллельные формулировки). Также следует давать уникальные и понятные имена каждому элементу управления – это помогает в помощи и доступности (например, каждую функцию в списке настроек называть по-разному, чтобы экранный диктор мог их различить).
- Поля ввода текста. Назначение – помочь ввести верную информацию. Для полей можно заранее подставлять (prefill) известные данные пользователя (имя, email и т.п.), чтобы сэкономить его время. Когда предзаполнение невозможно, автор советует использовать ярлыки над полем и подсказки (hint) внутри поля. Ярлык прямо указывает, что нужно вводить («Номер телефона»), подсказка – пример или инструкцию («Например, +7 123…»). При этом подсказки не должны быть слишком длинными и двусмысленными: слово-подсказку могут принять за уже введённый текст. Книга даёт четыре эффективных варианта текста: просто название поля, пример ввода, глагольная инструкция («Введите номер»), либо подсказка успеха («Важно: данные сохранены»). Иллюстрация: в диалоге смены пароля в The Sturgeon Club стоят метки «Новый пароль» и подсказка «Не менее 8 цифр или букв». Иногда можно обойтись лишь подсказками (для «чистого» дизайна) – в этом случае подсказка должна полностью раскрывать задачу ввода.
- Переходные сообщения (Transitional Text). Назначение – сообщить, что система приняла запрос и работает над ним. Это текст вида «Загружается…», «Отправка…», который показывается во время обработки действия. Такие сообщения подтверждают пользователю, что его действие получено и что ожидание оправдано. Автор советует использовать настоящее длительное время («загружается», «подготовка…») и часто добавлять многоточие, чтобы показать небольшую задержку. Пример: при обновлении платежных данных в The Sturgeon Club появляется сообщение «Обновление…», чтобы человек понял, что система работает, и не пытался повторно нажать старую кнопку. В игре ’appee задержка загрузки следующего раунда сопровождается фразой «Составляем задание…» или даже чуть разогревающим «Больше нет пути назад!» для создания напряжения. Оба приема – простое информирование и чуть «эмоциональное» усиление ситуации – отражают гибкость тональности.
- Сообщения-подтверждения (Confirmation Messages). Назначение – убедить пользователя, что ожидаемое действие завершилось. Это следует сразу после переходного сообщения или после изменения интерфейса: «Успешно сохранено», «Отправлено» и т.п. Подмайерски объясняет: сообщение-утверждение обычно пишется в прошедшем времени от того же глагола, что было в переходном сообщении. Например, после «Сохранение…» появляется «Сохранено». Иногда используется одно слово («Отправлено!»). В совокупности переходные и подтверждающие сообщения дают пользователю уверенность, что всё идёт по плану.
- Уведомления (Notifications). Назначение – ненавязчиво напомнить или побудить пользователя вернуться к приложению. Уведомления прерывают или привлекают внимание к важной информации, когда пользователь находится вне текущего экрана. Они должны нести ценность и актуальность (оповещение о новом письме, дедлайне, событии и т.д.). Обычно уведомление состоит из заголовка (часто начинается с глагола «Просмотреть», «Начать», «Напомнить» и т.д.) и пояснения. Например: «Просмотреть новое сообщение от коллеги». Заголовок привлекает внимание и описывает действие, которое стоит предпринять, описание добавляет дополнительную, но не критичную информацию. В примере The Sturgeon Club уведомляет о новом сообщении: заголовок «Просмотреть новое сообщение» и пояснение «от члена клуба». При этом важно не раскрывать приватный контент в самом уведомлении (чтобы не показывать текст сообщения посторонним), но можно добавить фирменную фразу (в примере – «Детали сообщения в безопасности»), чтобы усилить доверие и бренд.
- Сообщения об ошибках (Error Messages). Назначение – помочь человеку достичь цели, даже если что-то пошло не так. Ошибка – это ситуация, когда пользователь не может продолжить обычный путь. Сообщение об ошибке должно показывать, как «обойти» проблему или какую альтернативу выбрать. Не стоит обвинять пользователя («Вы неправильно ввели…»), лучше просто дать короткую инструкцию. Сохраняйте стиль и голос продукта, но добавляйте понимание. Часто используют короткие фразы с глаголом впереди, например «Введите 10 цифр номера» вместо «Неверный номер». Если ошибка серьёзная и восстановление невозможно, можно кратко извиниться за неудобство и предложить другие пути. Кроме того, для «профессиональной» аудитории можно давать чуть больше деталей (например, код ошибки или ссылку в службу поддержки), но только если это действительно поможет пользователю разобраться. Автор описывает три уровня ошибок: встроенные (inline) – самые мягкие, требуют лишь исправить ввод; детуровые (detour) – требуют совершить дополнительное действие или обход; блокирующие (blocking) – самые жёсткие, когда надо ждать или пробовать позже. Во всех случаях цель одна: объяснить проблему и предложить понятный путь вперёд, сохраняя доверие к системе.
Редактирование текста
Подмайерски призывает не ограничиваться черновым вариантом: редактирование UX-текста – это ключевой этап. При редактировании текст проходит четыре фазы: он должен стать целевым (purposeful), лаконичным (concise), разговорным (conversational) и чётким (clear).
- Purposeful (целеобразным). Уточняются цели текста: помогает ли он пользователю и бизнесу двигаться вперёд? Например, уведомление о истечении скидки должно явно объяснять, какие действия нужны (обновить данные карты, продлить подписку и т.д.). Здесь текст может быть длиннее, чтобы наверняка охватить все необходимые детали.
- Concise (лаконичным). Убираются все лишние слова. UX-текст читают не так, как статью – пользователи «просматривают» интерфейс. Книга указывает, что строка текста не должна превышать ~40–50 символов, а блок описания — ~3–4 строк. На этом этапе остались только нужные слова, изложенные максимально прямолинейно.
- Conversational (разговорным). Текст должен звучать так, как если бы интерфейс отвечал пользователю лично. Избегают перегруженных или слишком формальных конструкций. По возможности используют первое или второе лицо, простую лексику и обороты, характерные для диалога. Пример: вместо «Ошибка авторизации. Проверьте свой логин и пароль» можно сказать «Кажется, логин или пароль введены неверно. Попробуйте снова» – так звучит более дружелюбно.
- Clear (чётким). Финальная проверка на однозначность: будет ли пользователь понимать текст с пол-оборота? Убирают возможные двусмысленности, уточняют абстрактные слова. Автор подчёркивает, что даже технические или юридические термины должны быть простыми и понятными для целевой аудитории. Например, если в уведомлении упоминается «валидный аккаунт», нужно объяснить, что это значит, или дать ссылку «Что такое валидный аккаунт?».
Кроме того, Подмайерски советует редактировать тексты прямо в макетах интерфейсов, чтобы сразу видеть, как изменятся размеры и оформление. Сначала текст может расти (на этапе уточнения цели), а затем укорачиваться и упрощаться. Такой поэтапный метод помогает не упустить ни цели, ни удобочитаемости. В результате хорошо отредактированный UX-текст точно отражает задачи пользователя и бренда, при этом остаётся лёгким и «человечным».
Измерение эффективности UX-текста
Книга также даёт методики оценки того, насколько UX-текст справляется с поставленными задачами. Подход состоит из трёх направлений: прямого измерения, исследований с пользователями и эвристики.
- Прямое измерение (A/B-тестирование и метрики). Суть в том, чтобы менять текст и смотреть на поведение пользователей. Как пример, для приложения ’appee автор приводит ключевые бизнес-метрики (игра, просмотр изображений, реакции, покупки) и объясняет, что любые улучшения текста должны положительно влиять на эти показатели. Практически это реализуется через A/B-тест: одна группа пользователей видит новую версию текста, другая – старую. Например, можно тестировать скорость онбординга (время до первой покупки или лайка), показатели вовлечённости (DAU/MAU, время в приложении), завершения действий (abandonment vs completion), удержание (сколько дней подряд люди возвращаются), рекомендации друзьям и снижение операционных затрат (меньше обращений в поддержку). Если после изменения текста ключевые метрики улучшаются (либо хотя бы не ухудшаются), значит, текст работает лучше. Даже наоборот: если обновление текста снизило вовлечённость, важно об этом узнать – не стоит бояться «слишком длинного текста», тем более что часто правильные изменения лишь улучшают пользовательский опыт.
- Пользовательские исследования. Помимо автоматизированных метрик, важно слушать самих людей. UX-писатель должен знать, какие слова и фразы предпочитает аудитория. Для этого полезны интервью и тестирования: анализ отзывов (в магазинах приложений, соцсетях, службе поддержки), опросы, юзабилити-тесты и кодсёрфинг (card sorting). Особенно важно фиксировать натуральную речь пользователей: как они описывают задачи и элементы интерфейса. Эти слова есть у человека «в голове» и они легче воспринимаются. Например, если в отзывах люди говорят «хочу пригласить друга», то кнопка «Пригласить друга» более понятна, чем «Реферальная программа». Такой фидбек помогает найти удачные формулировки для меток, ошибок, подсказок. По мере развития продукта можно проводить собственные мини-опросы или тесты по новому тексту, анализировать, где возникают недоразумения, и корректировать контент.
- Эвристический анализ. Когда не понятно, с чего начать, применяют общие правила «хорошего текста». Подмайерски предлагает использовать набросок оценочной карты (scorecard) с критериями, совпадающими с целями UX-текста. В ней есть две части: «Юзабильность» (критерии: доступность, целеобразность, краткость, разговорность, ясность, полезность ошибок и т.д.) и «Голос» (критерии голосовой таблицы: концепции, словарь, лаконичность, синтаксис, пунктуация, капитализация). Каждый фрагмент интерфейса («пользовательскую задачу») оценивают по шкале от 0 до 10: насколько он, например, ясно сообщает цель пользователя и достигает цели организации. Так можно локализовать слабые места. Авторы исходят из того, что абсолютный балл неважен – важно увидеть, какие критерии нарушены, и улучшить их, а затем пересчитать. Например, если после внесения правок по «четкости» и «соответствию голосу» суммарная оценка растёт, то есть данные о качественном улучшении интерфейса. Такой подход даёт количественные «до/после» оценки даже без масштабного тестирования.
Все эти методы дополняют друг друга: метрики показывают «что» произошло после изменений, пользовательские исследования подсказывают «почему», а эвристики помогают учесть известные лучшие практики. Подмайерски призывает: «Если вы поверили в UX-текст, придайте ему числовую ценность» – то есть обосновывать его изменение конкретными цифрами и фактами.
Подытожим
Торри Подмайерски в «Strategic Writing for UX» демонстрирует, что тексты в интерфейсах – это не второстепенные детали, а ключевые элементы пользовательского опыта. Главное послание книги: грамотный UX-контент создаётся не «на лету», а стратегически – с учётом целей бизнеса и пользователя, согласованно с голосом бренда и следуя проверенным паттернам. Каждый текст (будь то кнопка, заголовок, подсказка или ошибка) имеет своё назначение и оформляется по строгим правилам: быть уместным, коротким, дружелюбным и понятным. Автора призывает включить в процесс разработки цикл «создания – проверки – измерения»: писать тексты, тестировать их, править по результатам и фиксировать улучшения метриками. Соблюдение этих рекомендаций обеспечивает не только единообразие и лаконичность интерфейсных сообщений, но и реальное повышение вовлечённости и удовлетворённости пользователей. Подытоживая, «словами делают интерфейсы понятными и удобными», и поэтому к каждой фразе нужно относиться как к элементу продукта, обоснованно планируя и улучшая её.
