Чем занимается UX-писатель?

    Привет, Хабр! Представляю вашему вниманию перевод статьи «What do UX writers do all day?» автора Yael Ben-David.

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

    image

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

    • Если вы слышали, что работа над текстами с точки зрения UX важна для вашей компании, и думаете о найме UX-писателя – эта статья про то, что вы можете ожидать от них.
    • Если вы планируете стать UX-писателем, эта статья должна помочь вам понять, сделает ли эта работа вас счастливым.
    • Если уже UX-писатель и делаете что-то, о чем в статье не упомянуто: пожалуйста, дайте мне знать – возможно, я забыла добавить это, или, может быть, я этого не делаю, а должна!

    Новые функции


    Это самое главное, чем мы занимается. После 2-3 недельных спринтов (при разработке по методике Agile. Надеюсь, сейчас так работают все) продукты обрастают новыми функциями, в своей стратегии учитывая задачи бизнеса и целевые количественные показатели к следующему релизу.

    Слова крайне важны, если мы говорим о том, как ввести новые функции и объяснить их пользователям (при этом интересы UX-писателя и пользователя должны быть взаимосвязаны). Мы пишем эти слова. Мы пишем их быстро, учитывая информацию от всех заинтересованных сторон. Мы пользуемся своим продуктом, чтобы быть уверенными, что понимаем цели и контекст наших слов; мы работаем с дизайнерами, чтобы убедиться, что продукт подходит для использования и организован наиболее эффективно; взаимодействуем с разработчиками, чтобы убедиться, что мы не создаем необоснованные технические проблемы своими обещаниями; с переводчиками, чтобы убедиться, что сообщение воспринимается на других языках точно также. Список можно продолжать и продолжать. При этом, функция всегда не одна, и каждый спринт необходимо писать сразу для многих функций.

    В команду разработки, как правило, входит менеджер по продукту, аналитики, разработчики, QA-инженеры и дизайнеры. У команды нет собственного UX-писателя; скорее, рабочий ресурс писателя разделяют сразу несколько команд разработчиков. На сколько команд работает автор? Ну, это по-разному. В одной компании я была единственным UX-писателем для 10 команд разработчиков. Я не ела, не спала и не ходила в туалет, но зато получала адреналин в течение года, и это я никогда не забуду. В другой компании я писала для 3 команд. У меня было так много свободного времени, что поначалу я была парализована от осознания огромной возможности инициировать свои собственные проекты. У меня получилось быстро справиться с новыми реалиями и наполнить свои часы теми проектами, в которые я всегда хотела погрузиться, но не предоставлялось возможности.

    Чтобы написать новый текст для функции:

    1. Вы участвуете в брифинге или проводите интервью. Менеджер проекта объясняет функцию, как она сделана, и зачем.
    2. Вы задаете вопросы.
    3. Приступаете к работе: проводите необходимые исследования, формируете понятия, объединяетесь с необходимыми специалистами, повторяете и повторяете снова, снова и снова… и снова.
    4. Потом вы презентуете текст.
    5. Разработчики задают вопросы как это реализовывать, а вы отвечаете на них.
    6. А потом ваше дитя начинает жить, и вы сами проверяете как это получилось, потому что вам все равно.
    7. Вы отслеживаете ключевые метрики взаимодействия с продуктом.
    8. Если (когда) вы найдете как улучшить метрику через текст, вы передадите эти данные менеджеру проекта.

    Это повторяется для каждой функции, для каждого менеджера проекта, каждого спринта.

    Оптимизация


    Давайте рассмотрим подробнее шаги 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-писатель получает удовольствие от такой работы, чем не может похвастаться, например, маркетолог. Страсть позволяет создавать классные вещи.
    Поделиться публикацией

    Комментарии 2

      +1
      Спасибо за перевод статьи.

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

      Однажды я увлёкся видеосъемкой, а где видеокамера — там и программы монтажа видео сами собой напрашиваются. Смотреть в интернете «туториалы» я не стал — прежде чем разбираться с программами, хорошо бы «изучить матчасть», то бишь теорию. Как смонтировать фильм, чтобы он был не мельтешением, а чем-то таким, что и посмотреть приятно (пусть не шедевр, но хотя бы с соблюдением основных канонов кино)? Пришлось искать книги по искусству монтажа кинофильмов, и таких нашлось немало (99% — из советских ещё времён).

      Если вы возьмёте книги по монтажу, написанные профессионалами от кино, то ключевыми терминами там будут кадрик (это отдельно взятый «фотоснимок»), план (материал, отснятый «одним дублем», то есть от включения камеры до выключения), кадр (часть плана, которая войдёт в фильм или передачу). Я изучил множество книг по теории и практики киносъёмки и последующего монтажа (с точки зрения кинематографа) — и вот уже было начал подбирать программу, в которой буду всё монтировать…

      И тут у меня случился «великий облом»: вся терминология, принятая отечественным кинематографом, отправлена на свалку куда подальше, а на её место водружены «кальки» (в лучшем случае) с английского. Всякие «футажи», «клипы», «таймлайны» и иже с ними…

      Я, конечно, понимаю, что исторически так сложилось, что ПО для видеомонтажа пришло к нам изначально англоязычное, нашему кинематографу было не до перевода интерфейсов, а любители — как умели (в основном — никак), так и перевели (зачастую — просто сделали кальку: footage (кадр) — футаж).

      В результате мы имеем то, что имеем. Лучше всего эту ситуацию отражает книга И.Кузнецова и В. Познина «Создание фильма на компьютере: технология и творчество», вышедшая в «Питере» в далёком 2005 году: написали её два специалиста, один рассказал про технологию работы в ПО (те самые «клипы», «футажи», «таймлайн» и т.п.), другой подробно описал процесс монтажа с позиций кинематографа (используя при этом слова «кадрик», «кадр», «монтажный стол» и т.д.). В результате порой мозги сломать можно, пытаясь перевести терминологию одного автора на язык второго.
      Ничего не имею против авторов - ни вместе, ни по отдельности. Просто эта книга - уж очень характерный пример сложившейся ситуации.
      На самом деле, очень благодарен и одному, и второму автору — они выполнили очень важную и нужную работу, и сделали это на высшем уровне!

      И вот настал момент, когда я понял, чего хочу от видеоредактора (под линуксом, свободный софт, стабильность работы) — и мой выбор пал на Kdenlive. Оказалось, что информации по самой программе — даже меньше, чем кот наплакал: англоязычные хелпы были написаны немногим больше, чем наполовину — самые «продвинутые» и интересные функции были документированы в лучшем случае наполовину.

      Удалось найти группу единомышленников, увлечённых решением своих задач в этой же программе. Кто-то бросил клич — «а давайте писАть хорошую русскоязычную справку». Я эту идею поддержал — и написал небольшой глоссарий по терминам, используемым в монтаже… Беседы в группе оживились, всё было хорошо, и тут у меня случился небольшой аврал, и я не заходил в группу, а когда зашёл — увидел, что моего глоссария нет. Оказалось — «киношные» термины идеологически не вписываются в терминологию, принятую переводчиком «официального» перевода (речь шла об одном из дистрибутивов, а не о глобальной локализации программы).

      Ну, в общем-то, не хотите даже обсуждать эту проблему — и ладно. Каждый остался при своём, я сейчас не об этом, а о ситуации с переводами UI и формированием UX, которая сложилась в этой сфере (по сути, две «тусовки», у каждой из которых свой «сленг»). Просто такая ситуация явно не способствует ни накоплению и обобщению пользовательского опыта, ни популяризации программного обеспечения, а без этого не будет и должного развития.

      P.S. Не собирался ни мораль читать, ни обвинять кого-то (если я и могу кого обвинить, так только себя — начитался тут книг «киношных» и полез со своим уставом в монастырь «видеографов», понимаешь ли). Просто ИМХО этот случай — хороший пример тех проблем, с которыми может столкнуться UX-писатель.
        0
        Спасибо за развернутый комментарий.
        На самом деле, проблема терминологии очень много где актуальна, и часто на этой почве появляются споры.
        Возможно, есть смысл заняться чем-то вроде business-glossary, который будет содержать значения терминов в разном контексте + другие употребляемые слова в этом значении.

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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое