Привет, Хабр! Представляю вашему вниманию перевод статьи «What do UX writers do all day?» автора Yael Ben-David.
Осознавая тот факт, что существование такой должности, как UX-писатель, довольно спорно, непонятно, и подходит далеко не любому проекту, я все же решил рискнуть, и предложить сообществу статью, которая приоткрывает контекст работы UX-писателей. Заранее всем спасибо, кто уделит время прочтению.
Еще 10 лет назад создание UX-текстов не было особенным процессом. Можно предположить, что и сейчас не все понимают, что из себя представляет эта работа. На вечеринках, когда меня спрашивают о работе, я люблю отшучиваться: «Когда вы открываете приложение… слова, которые вы видите на экране… я пишу их». Но на экранах большинства успешных приложений и программ не так много слов. Поэтому я могу представить, что людям сложно сообразить, как написание UX-текстов может занимать все рабочее время.
Это самое главное, чем мы занимается. После 2-3 недельных спринтов (при разработке по методике Agile. Надеюсь, сейчас так работают все) продукты обрастают новыми функциями, в своей стратегии учитывая задачи бизнеса и целевые количественные показатели к следующему релизу.
Слова крайне важны, если мы говорим о том, как ввести новые функции и объяснить их пользователям (при этом интересы UX-писателя и пользователя должны быть взаимосвязаны). Мы пишем эти слова. Мы пишем их быстро, учитывая информацию от всех заинтересованных сторон. Мы пользуемся своим продуктом, чтобы быть уверенными, что понимаем цели и контекст наших слов; мы работаем с дизайнерами, чтобы убедиться, что продукт подходит для использования и организован наиболее эффективно; взаимодействуем с разработчиками, чтобы убедиться, что мы не создаем необоснованные технические проблемы своими обещаниями; с переводчиками, чтобы убедиться, что сообщение воспринимается на других языках точно также. Список можно продолжать и продолжать. При этом, функция всегда не одна, и каждый спринт необходимо писать сразу для многих функций.
В команду разработки, как правило, входит менеджер по продукту, аналитики, разработчики, QA-инженеры и дизайнеры. У команды нет собственного UX-писателя; скорее, рабочий ресурс писателя разделяют сразу несколько команд разработчиков. На сколько команд работает автор? Ну, это по-разному. В одной компании я была единственным UX-писателем для 10 команд разработчиков. Я не ела, не спала и не ходила в туалет, но зато получала адреналин в течение года, и это я никогда не забуду. В другой компании я писала для 3 команд. У меня было так много свободного времени, что поначалу я была парализована от осознания огромной возможности инициировать свои собственные проекты. У меня получилось быстро справиться с новыми реалиями и наполнить свои часы теми проектами, в которые я всегда хотела погрузиться, но не предоставлялось возможности.
Чтобы написать новый текст для функции:
Это повторяется для каждой функции, для каждого менеджера проекта, каждого спринта.
Давайте рассмотрим подробнее шаги 7 и 8.
Когда мой вариант текста уходит в продукт, это не означает, что я могу забыть о нем. Ни за что. Я уже видела огромную разницу в качестве между первой итерацией и последней, поэтому я знаю, что все, что я написала, всегда можно улучшить. Главное, чем я занимаюсь во время перерывов между спринтами: улучшение уже существующих текстов.
Существуют отличные инструменты, помогающие нам понять, что работает, что нет, а что может работать лучше. Мы можем наблюдать, как наши пользователи взаимодействуют с нашими экранами, просматривая записи Full Story. На основе этого мы можем выдвинуть гипотезу об альтернативных вариантах, которые могут улучшить показатели, и запустить их для участников usertesting.com. И, конечно же, мы смотрим на цифры. MixPanel, Google Analytics и Tableau – сервисы, где можно получить представление о том, насколько эффективны тексты и интерфейсы, и где мы могли бы внести изменения.
Нет границ возможным улучшениям. Всегда есть ключевые показатели эффективности, которые нужно улучшить; всегда есть исключения, которые мы отрабатываем не так хорошо, как могли бы; всегда есть пространство для движения вперед.
Работа над тональностью и голосом продукта (Voice & Tone) – гораздо более крупный и менее срочный тип задачи. Если вам повезло работать в молодой компании, вы можете быть ответственным за создание и поддержание голоса и тона. Проект может занять месяцы и включает в себя интервью, семинары и многое другое.
Если вы работаете в компании, которая продолжает разрабатывать продукты, каждому из них может потребоваться собственная политика общения с внешним миром. Если вы работаете в компании, которая проходит ребрендинг, вы можете нести заняться обновлением голоса/тона. В любом случае, вы всегда будете нести ответственность за то, чтобы все тексты соответствовали общей идее.
Работа над этим требует много времени на обдумывание, мозговой штурм, исследования, сбор информации от руководителей и служб, работающих напрямую с пользователями, например, техподдержка. Эта работа идет гораздо медленнее, чем описание новых функций и их оптимизация, но она оказывает гораздо большее влияние, чем любая функция, причем непрерывно. Это то, что вы (также) всегда делаете.
По мере роста компании поддержание унификации всех частей продукта занимает все больше времени. Чтобы убедиться, что ваш продукт обеспечивает беспроблемное взаимодействие с пользователем, важна последовательность.
Совместите старое с новым. При написании новых текстов лучше всего поддерживать согласованность с существующими экранами. Но иногда новая копия становится намного лучше, тогда лучше подтягивать старое до уровня нового. Вероятно, вы начнете с исследования, чтобы подтвердить, что улучшение действительно является улучшением, а затем убедитесь с помощью менеджера проекта, что команды разработчиков имеют возможность для выполнения задачи. Однако, чтобы определить размер задачи, сначала нужно наметить все места в продукте, где существует соответствующий текст. И тогда вы начинаете унифицировать.
Совместите маркетинг с продуктом. Голос – это индивидуальность продукта, а тон – то, как вы звучите в различных точках соприкосновения и сценариях в процессе работы пользователя с продуктом. Но путь пользователя проходит не только внутри продукта – совсем нет! И когда мы видим разницу между маркетингом и тем, что происходит в продукте, это плохой UX. Вы хотите продолжить взаимодействие с поставщиком услуг с расстройством личности? Будете ли вы доверять им, когда есть так много других вариантов? Сотрудничество с маркетингом является первым шагом в предотвращении этого диссонанса. Сделайте это однажды и регулярно синхронизируйтесь.
Совместите техподдержку и продажников с продуктом. Опыт взаимодействия пользователя с командами техподдержки и продаж тоже очень важен. Что техподдержка, что продажники должны говорить о продукте точно так же, и с тем же тоном, что и маркетинг. Хороший способ решить эту задачу – синхронизировать команды по мере появления новых функций. Каждый раз, когда появляется новая функция или выходит релиз, всем тем, кто напрямую общается с пользователями, будет необходимо актуализировать информацию о продукте; возможно, скорректировать скрипты обзвона, шаблоны электронной почты, страницу FAQ и т.п. Никто не понимает новую функцию лучше, чем человек, который ее написал, поэтому UX-писатель находится в идеальном положении, чтобы поддерживать согласованность всех пользовательских команд.
Масштабируйте. По мере роста организации ваша команда будет расти, но у вас не будет больше часов в день (к сожалению, это правда… я проверяла). Из-за этого вы не можете одновременно контролировать язык/унификацию сообщений и остальные задачи своей работы. Несколько инструментов, которые мне показались полезными для решения этой проблемы: база данных со всеми текстами продукта и ознакомительная документация (Onboarding documentation). База данных может размещаться, например, в Google Sheet, где вы храните свои тексты, разделяя их на текущие, прошлые и будущие. Получается своего рода словарь, на который может ссылаться каждый, и позволяющий не расходиться понятиям и тону сообщений. Короче говоря, делает процесс удобнее. Разумеется, могут найтись исключения, но с организованной базой данных, даже когда вы пишете что-то новое, вы можете начать с четкого представления о том, что уже существует. Ознакомительная документация помогает быстро обучить и ввести в текущие дела любого новичка в команде. Сюда можно включить ссылки на образцы Voice & Tone, руководство по стилю, базу данных сообщений, перечни заинтересованных лиц и что угодно еще, что поможет новым голосам в продукте звучать так же, как старые. Эти два инструмента могут быть невероятно ценными, но только если они обновляются. И это отнимает время (лично я обновляю базу данных раз в месяц, а документацию с каждым новым наймом).
Как и в любой профессии, особенно в области ИТ, непрерывное образование является важной частью работы UX-писателя. Развитие подразумевает чтение и слушание ведущих специалистов; посещение конференций, вебинаров и семинаров; участие в жизни профильных сообществ; поиск наставников и учеников; создание собственного контента как для тренировки, так и поддержки важных тем сообщества. Это требует времени, но эффект неоценим, так как вы получаете возможность убедиться, что ваш продукт не остался в пыльном облаке мчащихся вперед конкурентов.
UX-писатели выполняют множество задач, особенно если в зоне ответственности сразу несколько команд/продуктов. Наша деятельность нишевая, она отличается от копирайтинга или создания контента. Конечно, есть общие черты, но мы живем в эпохе специалистов, а не универсалов. Единороги остались в прошлом.
Чтобы получить лучшие тексты для продуктов используйте UX-писателя. Не только для того, чтобы избежать сценария «мастер на все руки, но не мастер в чем-то конкретном», но и потому, что UX-писатель получает удовольствие от такой работы, чем не может похвастаться, например, маркетолог. Страсть позволяет создавать классные вещи.
Осознавая тот факт, что существование такой должности, как UX-писатель, довольно спорно, непонятно, и подходит далеко не любому проекту, я все же решил рискнуть, и предложить сообществу статью, которая приоткрывает контекст работы UX-писателей. Заранее всем спасибо, кто уделит время прочтению.
Еще 10 лет назад создание UX-текстов не было особенным процессом. Можно предположить, что и сейчас не все понимают, что из себя представляет эта работа. На вечеринках, когда меня спрашивают о работе, я люблю отшучиваться: «Когда вы открываете приложение… слова, которые вы видите на экране… я пишу их». Но на экранах большинства успешных приложений и программ не так много слов. Поэтому я могу представить, что людям сложно сообразить, как написание UX-текстов может занимать все рабочее время.
- Если вы слышали, что работа над текстами с точки зрения UX важна для вашей компании, и думаете о найме UX-писателя – эта статья про то, что вы можете ожидать от них.
- Если вы планируете стать UX-писателем, эта статья должна помочь вам понять, сделает ли эта работа вас счастливым.
- Если уже UX-писатель и делаете что-то, о чем в статье не упомянуто: пожалуйста, дайте мне знать – возможно, я забыла добавить это, или, может быть, я этого не делаю, а должна!
Новые функции
Это самое главное, чем мы занимается. После 2-3 недельных спринтов (при разработке по методике Agile. Надеюсь, сейчас так работают все) продукты обрастают новыми функциями, в своей стратегии учитывая задачи бизнеса и целевые количественные показатели к следующему релизу.
Слова крайне важны, если мы говорим о том, как ввести новые функции и объяснить их пользователям (при этом интересы UX-писателя и пользователя должны быть взаимосвязаны). Мы пишем эти слова. Мы пишем их быстро, учитывая информацию от всех заинтересованных сторон. Мы пользуемся своим продуктом, чтобы быть уверенными, что понимаем цели и контекст наших слов; мы работаем с дизайнерами, чтобы убедиться, что продукт подходит для использования и организован наиболее эффективно; взаимодействуем с разработчиками, чтобы убедиться, что мы не создаем необоснованные технические проблемы своими обещаниями; с переводчиками, чтобы убедиться, что сообщение воспринимается на других языках точно также. Список можно продолжать и продолжать. При этом, функция всегда не одна, и каждый спринт необходимо писать сразу для многих функций.
В команду разработки, как правило, входит менеджер по продукту, аналитики, разработчики, QA-инженеры и дизайнеры. У команды нет собственного UX-писателя; скорее, рабочий ресурс писателя разделяют сразу несколько команд разработчиков. На сколько команд работает автор? Ну, это по-разному. В одной компании я была единственным UX-писателем для 10 команд разработчиков. Я не ела, не спала и не ходила в туалет, но зато получала адреналин в течение года, и это я никогда не забуду. В другой компании я писала для 3 команд. У меня было так много свободного времени, что поначалу я была парализована от осознания огромной возможности инициировать свои собственные проекты. У меня получилось быстро справиться с новыми реалиями и наполнить свои часы теми проектами, в которые я всегда хотела погрузиться, но не предоставлялось возможности.
Чтобы написать новый текст для функции:
- Вы участвуете в брифинге или проводите интервью. Менеджер проекта объясняет функцию, как она сделана, и зачем.
- Вы задаете вопросы.
- Приступаете к работе: проводите необходимые исследования, формируете понятия, объединяетесь с необходимыми специалистами, повторяете и повторяете снова, снова и снова… и снова.
- Потом вы презентуете текст.
- Разработчики задают вопросы как это реализовывать, а вы отвечаете на них.
- А потом ваше дитя начинает жить, и вы сами проверяете как это получилось, потому что вам все равно.
- Вы отслеживаете ключевые метрики взаимодействия с продуктом.
- Если (когда) вы найдете как улучшить метрику через текст, вы передадите эти данные менеджеру проекта.
Это повторяется для каждой функции, для каждого менеджера проекта, каждого спринта.
Оптимизация
Давайте рассмотрим подробнее шаги 7 и 8.
Когда мой вариант текста уходит в продукт, это не означает, что я могу забыть о нем. Ни за что. Я уже видела огромную разницу в качестве между первой итерацией и последней, поэтому я знаю, что все, что я написала, всегда можно улучшить. Главное, чем я занимаюсь во время перерывов между спринтами: улучшение уже существующих текстов.
Существуют отличные инструменты, помогающие нам понять, что работает, что нет, а что может работать лучше. Мы можем наблюдать, как наши пользователи взаимодействуют с нашими экранами, просматривая записи Full Story. На основе этого мы можем выдвинуть гипотезу об альтернативных вариантах, которые могут улучшить показатели, и запустить их для участников usertesting.com. И, конечно же, мы смотрим на цифры. MixPanel, Google Analytics и Tableau – сервисы, где можно получить представление о том, насколько эффективны тексты и интерфейсы, и где мы могли бы внести изменения.
Нет границ возможным улучшениям. Всегда есть ключевые показатели эффективности, которые нужно улучшить; всегда есть исключения, которые мы отрабатываем не так хорошо, как могли бы; всегда есть пространство для движения вперед.
Голос и тон
Работа над тональностью и голосом продукта (Voice & Tone) – гораздо более крупный и менее срочный тип задачи. Если вам повезло работать в молодой компании, вы можете быть ответственным за создание и поддержание голоса и тона. Проект может занять месяцы и включает в себя интервью, семинары и многое другое.
Если вы работаете в компании, которая продолжает разрабатывать продукты, каждому из них может потребоваться собственная политика общения с внешним миром. Если вы работаете в компании, которая проходит ребрендинг, вы можете нести заняться обновлением голоса/тона. В любом случае, вы всегда будете нести ответственность за то, чтобы все тексты соответствовали общей идее.
Работа над этим требует много времени на обдумывание, мозговой штурм, исследования, сбор информации от руководителей и служб, работающих напрямую с пользователями, например, техподдержка. Эта работа идет гораздо медленнее, чем описание новых функций и их оптимизация, но она оказывает гораздо большее влияние, чем любая функция, причем непрерывно. Это то, что вы (также) всегда делаете.
Унификация
По мере роста компании поддержание унификации всех частей продукта занимает все больше времени. Чтобы убедиться, что ваш продукт обеспечивает беспроблемное взаимодействие с пользователем, важна последовательность.
Совместите старое с новым. При написании новых текстов лучше всего поддерживать согласованность с существующими экранами. Но иногда новая копия становится намного лучше, тогда лучше подтягивать старое до уровня нового. Вероятно, вы начнете с исследования, чтобы подтвердить, что улучшение действительно является улучшением, а затем убедитесь с помощью менеджера проекта, что команды разработчиков имеют возможность для выполнения задачи. Однако, чтобы определить размер задачи, сначала нужно наметить все места в продукте, где существует соответствующий текст. И тогда вы начинаете унифицировать.
Совместите маркетинг с продуктом. Голос – это индивидуальность продукта, а тон – то, как вы звучите в различных точках соприкосновения и сценариях в процессе работы пользователя с продуктом. Но путь пользователя проходит не только внутри продукта – совсем нет! И когда мы видим разницу между маркетингом и тем, что происходит в продукте, это плохой UX. Вы хотите продолжить взаимодействие с поставщиком услуг с расстройством личности? Будете ли вы доверять им, когда есть так много других вариантов? Сотрудничество с маркетингом является первым шагом в предотвращении этого диссонанса. Сделайте это однажды и регулярно синхронизируйтесь.
Совместите техподдержку и продажников с продуктом. Опыт взаимодействия пользователя с командами техподдержки и продаж тоже очень важен. Что техподдержка, что продажники должны говорить о продукте точно так же, и с тем же тоном, что и маркетинг. Хороший способ решить эту задачу – синхронизировать команды по мере появления новых функций. Каждый раз, когда появляется новая функция или выходит релиз, всем тем, кто напрямую общается с пользователями, будет необходимо актуализировать информацию о продукте; возможно, скорректировать скрипты обзвона, шаблоны электронной почты, страницу FAQ и т.п. Никто не понимает новую функцию лучше, чем человек, который ее написал, поэтому UX-писатель находится в идеальном положении, чтобы поддерживать согласованность всех пользовательских команд.
Масштабируйте. По мере роста организации ваша команда будет расти, но у вас не будет больше часов в день (к сожалению, это правда… я проверяла). Из-за этого вы не можете одновременно контролировать язык/унификацию сообщений и остальные задачи своей работы. Несколько инструментов, которые мне показались полезными для решения этой проблемы: база данных со всеми текстами продукта и ознакомительная документация (Onboarding documentation). База данных может размещаться, например, в Google Sheet, где вы храните свои тексты, разделяя их на текущие, прошлые и будущие. Получается своего рода словарь, на который может ссылаться каждый, и позволяющий не расходиться понятиям и тону сообщений. Короче говоря, делает процесс удобнее. Разумеется, могут найтись исключения, но с организованной базой данных, даже когда вы пишете что-то новое, вы можете начать с четкого представления о том, что уже существует. Ознакомительная документация помогает быстро обучить и ввести в текущие дела любого новичка в команде. Сюда можно включить ссылки на образцы Voice & Tone, руководство по стилю, базу данных сообщений, перечни заинтересованных лиц и что угодно еще, что поможет новым голосам в продукте звучать так же, как старые. Эти два инструмента могут быть невероятно ценными, но только если они обновляются. И это отнимает время (лично я обновляю базу данных раз в месяц, а документацию с каждым новым наймом).
Совершенствование
Как и в любой профессии, особенно в области ИТ, непрерывное образование является важной частью работы UX-писателя. Развитие подразумевает чтение и слушание ведущих специалистов; посещение конференций, вебинаров и семинаров; участие в жизни профильных сообществ; поиск наставников и учеников; создание собственного контента как для тренировки, так и поддержки важных тем сообщества. Это требует времени, но эффект неоценим, так как вы получаете возможность убедиться, что ваш продукт не остался в пыльном облаке мчащихся вперед конкурентов.
UX-писатели выполняют множество задач, особенно если в зоне ответственности сразу несколько команд/продуктов. Наша деятельность нишевая, она отличается от копирайтинга или создания контента. Конечно, есть общие черты, но мы живем в эпохе специалистов, а не универсалов. Единороги остались в прошлом.
Чтобы получить лучшие тексты для продуктов используйте UX-писателя. Не только для того, чтобы избежать сценария «мастер на все руки, но не мастер в чем-то конкретном», но и потому, что UX-писатель получает удовольствие от такой работы, чем не может похвастаться, например, маркетолог. Страсть позволяет создавать классные вещи.
