Чем UX-райтинг отличается от копирайтинга и журналистики, что такое семантическое ядро продукта и почему рекомендациям Apple не всегда стоит доверять? На недавнем этапе в Apollo Design Centre на эти вопросы отвечал Богдан Гречановский, продакт-оунер и UX-писатель компании MacPaw. UNIT Citizen записал самое интересное.

Что такое UX-райтинг? 

UX-райтинг (UX-writing) – это создание всех текстов внутри продукта, на сайте, в десктопных и мобильных версиях, на всех всплывающих окнах, подсказках, меню. 

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

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

Зачем нужны UX-тексты?

Главные задачи UX-райтинга – направлять и инструктировать пользователя, сопровождать все взаимодействия пользователя с продуктом. Часто с помощью текста нужно даже удерживать пользователя в определенном настроении, особенно если ваш продукт требует какого-то времени на выполнение задачи.

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

Как создаются UX-тексты?

Разработчик и главный редактор портала UX Planet Ник Бабич считает, что UX-тексты – главный индикатор качества всего UX-дизайна продукта. Поэтому он советует начинать работу над текстами как можно раньше, параллельно с работой над интерфейсом.

И действительно, если составлять тексты и семантическое ядро продукта на моменте разработки идеи, то это сократит количество итераций и сэкономит много часов работы всей команды. Этого принципа мы придерживаемся в MacPaw. Например, при разработке CleanMyMac мы строили все модули, а сейчас их больше 12 штук, основываясь на семантическом принципе, который вывели при разработке UX-текстов. Эта семантика повлияла на workflow внутри продукта, на дизайн всех прототипов. Можно сказать, что в CleanMyMac текст появился раньше всего остального в продукте. 

Этот принцип формирует и командный подход к работе над продуктом. Как правило, мы работаем втроем с продакт-оунером и дизайнером.

Сейчас мы готовим очередное обновление пользовательского кабинета для Setapp – нашего магазина приложений по подписке. Работа происходит следующим образом: дизайнер в Sketch создает весь workflow, пунктирно, не особо прорабатывая, затем я этот файл дорабатываю с точки зрения текста, и потом дизайнер будет создавать финальный вариант, уже зная всю терминологию и то, как выглядит весь текст.  

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

5 советов UX-райтеру

1. Говорите с аудиторией на ее языке.

Большинство продуктов ориентированы на global audience – мировую аудиторию, поэтому и ориентироваться нужно на нее. Исключайте культурные отличия, пользуйтесь популярными, часто употребляемыми словами. Это обычно довольно сложно для носителей языка и для людей, которые с отличием закончили филологический факультет. Среди всех пользователей вашего продукта носителей английского языка будет максимум 30-40%. Остальные – это люди со всего мира, и у них далеко не идеальный английский. 

Кроме того, стоит абстрагироваться от гендерных различий. Сейчас уже повсеместно употребляют местоимение ‘they’ в единственном числе, это считается грамматические верным, и, главное, избавляет вас от необходимости писать что-то в духе ‘he or she’.

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

2. Поработайте в отделе техподдержки.

В длительной работе с продуктом всегда возникает опасность curse of knowledge. Это так называемое «проклятие знания» – когнитивное искажение восприятия, когда вы знаете свой продукт вдоль и поперек, и некоторые вещи для вас настолько очевидны, что даже не приходит в голову объяснять их пользователю. А пользователь вообще ничего об этом не знает. Так образуется пропасть, в которую «улетает» вся ценность продукта. Поэтому самое главное, что нужно сделать – всегда ставить себя на место пользователя. 

Если вы работаете в компании, где есть свой отдел техподдержки, я рекомендую провести там неделю-две каждому члену команды – дизайнеру, продакт-менеджеру и UX-райтеру. Это необходимый и бесценный опыт для всех, кто соприкасается с продуктом. Так вы узнаете все, что о продукте говорят пользователи, поймете, чего им не хватает, а также где есть проблемы. И главное – вы станете видеть продукт как пользователь и избавитесь от пресловутого curse of knowledge.

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

3. Будьте краткими.

В 2017 году слово conсise – лаконичный, короткий, понятный – было названо словом года. За два года ничего особенно не изменилось. Краткость и лаконичность – основа UX-текстов. Здесь надо помнить, что UX – это не художественная литература, а концентрированная ценность продукта, не больше и не меньше. Если исходить из того, что любой текст должен создаваться под запрос пользователя, то несложно определить, что у читателя художественной литературы и UX-текстов совсем разные запросы.

Если литература – это про эстетическое удовольствие, то UX-тексты – это стопроцентное короткое и точное попадание идеи прямо «в мозг». Человек, читая такой текст, должен даже не успевать осознавать, что именно он читает. Идея, заложенная в тексте, должна молниеносно возникнуть у него в мозгу. 

4. Задайте себе два главных вопроса.

Это важная практика, с которой я рекомендую начинать любую задачу – новый продукт или обновление, все, что угодно. Первый вопрос, который вы должны себе задать – что нужно пользователю на этом экране? И второй — что нужно вам как создателю продукта? Найдя ответы на эти два вопроса, вы напишете максимально правильный текст, который только может быть.

Например, банальная форма регистрации. Если пользователь добрался до формы регистрации, значит маркетинг сработал – клиент уже пришел. Что нам нужно от формы регистрации? Мы хотим, чтобы человек максимально быстро «провалился» в продукт. Что нужно для этого сделать? Убрать все возможные препятствия на его пути к продукту. Поэтому в форме регистрации нужно убрать все поля, без которых можно обойтись. Без e-mail мы не можем запуститься? Оставляем его. Без имени пользователя можем? Можем. Убираем имя. Получаем самую короткую и легкую форму регистрации, которая решает обе задачи – нашу и клиента.

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

5. Что делать с гайдлайнами? Имейте их в виду.

Есть такой важный и спорный момент, как гайдлайны. Это набор единых принципов, правил и рекомендаций от разработчиков той или иной платформы (например, iOS или Windows) о том, как должен выглядеть интерфейс приложений, их стиль, типографика, иконография и так далее. Ориентироваться на них нужно, но не забывая при этом о здравом смысле. Есть некоторые стилистические особенности или термины, которых стоит придерживаться на той или иной платформе. 

Например, если брать гайдлайны iOS, то там важно, чтобы ваш продукт выглядел органично, обязательно использовать title case (тип капитализации слов, когда каждое слово пишется с прописной буквы) во всех кнопках и меню, в одном окне не делать больше трех кнопок. Закрытие приложения на MacOS должно обозначаться только словом quit, выбор элемента меню – только словом choose. А, например, на Windows требуют использовать слово close для закрытия окон. Это небольшие межплатформенные отличия, но о них нужно помнить.

Бывают сложности в случаях, где часто фигурируют действия click/tap/press. Чаще всего ошибочно пишут press везде, но это неверно. Press обозначает только физическое действие на клавиатуре, а tap – это действие на тачскрине. 

Но…

Иногда рекомендации и гайдлайны платформ противоречат сами себе. Ребята из Apple иногда рекомендуют составлять предложения таким образом, который не соответствует принятому порядку слов в английском языке. Например, опция, которая объясняет пользователю, что ему нужно сделать, чтобы получить желаемый результат звучит так:  to create smth, do… – для того чтобы сделать что-то, сделайте то-то. На самом деле, это совсем не по-английски. Мы пробовали писать так, но нам стали в саппорт приходить письма от пользователей с вопросами в духе — какие индусы у вас пишут тексты? Поэтому учитывая все требования гайдлайнов, не забудьте учесть и здравый смысл тоже.