Telegraf.design продолжает публиковать конспекты лекций о дизайне от школы Projector. Переходим к следующей теме – UX Writing.

Богдан Гречановский в течение последних девяти лет совмещает несколько околопродуктовых ролей в компании MacPaw, одна из которых – UX Writing. На лекции в Projector он рассказал о тонкостях написания UX-текстов, работе с гайдлайнами, тоне общения с потребителем и важных нюансах создания текстов для интерфейсов. Публикуем ключевые мысли Богдана в конспекте встречи, а ее полную видеоверсию – по ссылке.

UX Writing vs. UX Copywriting

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

Вопросы и ответы о UX Writing

Что такое UX Writing?

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

Где встречается UX Writing?

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

Когда запускать процесс UX Writing?

Одновременно с зарождением идеи продукта. Чем позже будут написаны правильные тексты, тем больше лишней работы предстоит дизайнерам и разработчикам в дальнейшем. Как следствие – лишние итерации и затраты человеко-часов.

Основной сценарий работы с программой по очистке компьютеров CleanMyMac изначально строился на словесной трехшаговости: scan – clean – done. Это влияло на организацию всех экранов и их состояний. Учитывая, что внутри продукта более десяти модулей, такой подход помог сохранить их консистентными и сэкономить время на ненужные итерации.

Как делать UX-текст?

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

«Краткий» – слово 2017 года

Цели UX-текста:

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

Чтобы быть хорошим писателем интерфейсов нужны:

• понимание ценности продукта;
• способность предусмотреть поведение пользователя на определенном экране;
• способность писать для глобальной аудитории.

Всегда начинайте с двух вопросов, независимо от масштаба задачи:

• что здесь нужно пользователю?
• что здесь нужно нам?

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

Задав два основных вопроса, мы, как правило, сделаем экран проще, ценнее, а иногда просто поймем, что он нам вовсе не нужен.

В этой форме регистрации я ставлю под сомнение необходимость поля “Name” как такового. Мы задаем себе вопрос: что нужно пользователю на этом экране? Ему нужно уже начать работать с тем, что его на данном этапе заинтересовало. Дополнительное поле – это стоппер. Что нужно нам? Мы хотим заполучить пользователя, но сами подставляем ему дополнительную ступеньку до того, как он очутился на борту. Почему бы не спросить имя после регистрации, если оно вообще нам нужно? И заодно найти для этого более подходящее место в сценарии использования.

Tone of voice

У большинства компаний есть свои voice и tone. Часто их пытаются в равной степени придерживаться для всей продуктовой линейки компании. Но это не всегда корректно. К примеру, стоит помнить, что под крылом одного voice and tone могут быть весьма разные по своей «опасности» продукты, и это должно находить выражение в текстах.

Например, в CleanMyMac достаточно сухой и сдержанный tone of voice, не отвлекающий от серьезности процесса очистки, так как мы работаем с системными файлами. В то же время в программе для поиска дубликатов Gemini, которая работает с потенциально менее опасными вещами, допустим более раскованный тон.

Для кого мы пишем?

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

Нельзя забывать о корректном использовании “he” и “she”. Старайтесь избегать сексизма красиво. Допускается использование множественного “they” для описания действий “user” в единственном числе.

Носители языка

Должны ли иностранные тексты составляться носителями языка? Даст ли это лучший результат? Абсолютно нет, если писатель не обладает навыками, описанными выше в статье. Более того, слишком развитое знание языка может стать дополнительной преградой, так как будет сложнее оценить читабельность и восприятие текста с точки зрения глобальной аудитории. Носителю языка любые тексты могут казаться понятными.

Команда и взаимодействие

Наилучший результат с минимумом итераций на этапе разработки, как правило, получается в том случае, когда писатель UX-текстов, Product Owner и дизайнер работают единой командой.

Не проходите мимо отдела поддержки

Опыт работы в «суппорте», пожалуй, лучше любых рекомендаций помогает научиться понимать поведение пользователей. И это ни для кого не утраченная возможность. Независимо от своей основной роли в команде, просто освободите себе неделю и отработайте её в техподдержке вашего (а можно и любого другого) продукта. У сотрудников MacPaw, кто уже испробовал это на себе – исключительно положительные отзывы.

Гайдлайны

Ваши тексты должны соответствовать гайдлайнам системы для которой вы пишете, но это соответствие, ни в коем случае, не должно быть беспрекословным. Гайдлайны и стилистические требования нужно знать и использовать, но не стоит ставить их выше здравого смысла и банальной логики. А такие недостатки бывают. Как на частые и яркие примеры таких нестыковок, можно обратить внимание на рекомендации от Apple:

Каждое слово основного текста любого сообщения рекомендуется писать с заглавной буквы. Да, это и правда хорошо работает для коротких заголовков. Но, в свою очередь, строчное написание выглядит чище. Вот пример явно не лучшего сообщения от самих же Apple:

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

Кнопки, части речи, длина текстов, лишний фан и другая боль

Хороший диалог, как правило, имеет одну-две кнопки. Три – максимум. Если у вас четыре кнопки – вы явно делаете что-то не так. И не только для пользователя. Отдаляя его от получения ценности, вы сами не получите того, чего хотели. Будьте прямолинейно понятными, один вопрос – одно действие;

В английском важно не путать глаголы с существительными;

Выбранная вами перспектива обращения: my или your. Как правило, если вы являетесь владельцем контента, с которым работает приложение, то будет подходящим использование My Library, My Photos, etc.. С другой стороны, есть продукты, которые просто дают нам ценность, обслуживают нас как пользователей, но не хранят внутри лично наших данных. В таких случаях более уместно обращение “Your”;

Чтобы попасть в нужную длину с вашим текстом, особенно, если требуется много однотипных строк в узкой части интерфейса, рекомендую создавать собственные вспомогательные микро-приложения. По сути программа с кусочком нашего экрана в приложении и свободными полями ввода, из которых текст будет сразу отображаться «как в приложении». Это займет некоторое время ваших разработчиков, зато вы сможете потом просто вводить текст и сразу видеть, хорошо ли он ляжет в продукте. Это в долгосрочной перспективе экономит очень много ресурсов, тем более, этими «помощниками» можно делиться с переводчиками. Мы же знаем, что не всегда текст можно уместить только по количеству символов;

Помещать в тексты своего продукта много «фана» – очень популярная практика, хотя она и достаточно опасна, если отдаляет пользователя от достижения его цели. Развлекательный элемент уместен тогда, когда пользователь находится на пути к ценности продукта. Например, в программе происходит процесс сканирования или удаления, без которых всё равно не обойтись. Это хороший момент для того, чтобы развлечь пользователя. К примеру, так в Gemini появляется текст: “Sit back and relax”;

Выстраивая ряд больших гипотез, основываясь только на опыте, очень часто случается, что и опыт и гипотезы рушатся. В таких ситуациях на помощь приходит А-В-тестирование.

Локализация

Локализация – это не перевод, а адаптация текста. Фактически, вы заново делаете копию интерфейса на новом языке. Да, все уже спроектировано, но тон коммуникации может при переводе меняться. На это влияют национальные особенности, шутки внутри продукта и прочие детали, привязанные к языку. Не стоит бояться кардинально менять то, что пишете. Цель переводчика всё та же – привести пользователей к ценности продукта максимально быстро и понятно. Соответствие английскому оригиналу – не в приоритете.

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

Заключение

Помните, ваша способность писать – это лишь инструмент во всем процессе UX Writing.

Раньше Telegraf.design писал о том, как UX writing помогает делать продукты лучше. Если захотите изучить UX Writing на практике – присоединяйтесь к курсу UX Writing в Projector.