UX-редактура в клиентском сервисе

Автор: Алина Трофимцова

Лид UX-редакторов в клиентском сервисе
Провела 50+ консультаций для специалистов уровня junior, middle, senior
Ментор программы Woman in Tech
Спикер и член программного комитета UX-марафона по направлению UX-редактура
Автор телеграм-канала Дольче вита в Авито

Вы хоть раз обращались в поддержку Авито?

Переписывались с чат-ботом, общались с голосовым помощником, искали нужную статью в Помощи?

Если да, то вы — мои клиенты, приятно познакомиться. Сейчас я тимлид UX-редакторов (дальше я буду иногда называть их UXW, UX Writers) клиентского сервиса и моя команда работает с CX-контентом, который помогает снижать обращения в поддержку и работать с удовлетворенностью пользователей.

И нет, я не знаю, почему заблокировали ваше объявление. Но давайте с самого начала.

Часть первая
Место UX-редактора в клиентском сервисе

Сейчас UX-редактура существует в двух основных направлениях: продуктовые интерфейсы и клиентский сервис.

UX-редакторы интерфейсов отвечают за все тексты, которые вы видите в приложениях: кнопки, ссылки, тултипы, плейсхолдеры, пустые состояния, экраны ошибок и успеха. Задача интерфейсных текстов — провести пользователя от точки входа до целевого действия так, чтобы он нигде не споткнулся.

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

Цель UX-редактора: сделать так, чтобы информация в максимально полном, неискажённом и понятном виде попала от создателей продуктового изменения к её пользователям. Для этого мы много общаемся с продакт-менеджерами и бизнес-аналитиками, разбираемся в сути каждого изменения, а затем — принимаем решение, где и каким образом его осветить. И хотя в описании задач чаще других будет звучать глагол «пишем», UX-редакторы проводят полноценный цикл работы с задачей, начиная с этапа дискавери, когда с помощью аналитики или исследования мы получаем данные, помогающие принять решения, заканчивая пост-поддержкой — анализом того, как именно наши изменения повлияли на фокусные метрики.

Часть вторая

Мифы о UX-редакторах

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

Давайте обсудим самые частые из них.

1. Написать текст может любой

В такой формулировке я иногда слышу невысказанный вопрос, зачем нанимать отдельного человека под такую незначительную задачу, ведь писать умеют все — и вы, и я.

И правда, и неправда. Написать текст может любой, но в клиентском сервисе текст должен выполнять определенную задачу — например, влиять на CR, или приучать клиентов к селф-сервису, или сохранять лояльность компании. И никто из UX-редакторов не пишет тексты интуитивно и без подготовки (поэтому мы так не любим задачи «здесь дел на 5 минут» — таких не бывает).

Если представлять нашу работу в виде айсберга, текст будет той самой верхушкой, которая торчит над водой. Оставшиеся 90% — рисёрч аналитики, наше взаимодействие с продакт-менеджерами и аналитиками, изучение контекста пользовательского пути, согласование с юристами и PR-службой, пост-поддержка и регулярная актуализация и оптимизация данных. Можно попросить написать текст кого угодно, но кто займется оставшейся частью работы?

2. Если продукт хороший, неважно, какие тексты

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

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

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

3. У текста нет влияния на метрики

… а значит нет смысла прорабатывать эту сферу продукта (эту часть фразы обычно не говорят вслух, но подразумевают). И это действительно сложный миф, ответ на который я дам в следующей части нашей главы вместе с подробным разбором метрик, над которыми мы работаем.

Часть третья

Метрики контентных продуктов

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

1. Раздел Помощь

Один из разделов сайта, в котором собраны ответы на часто задаваемые вопросы в виде статей. Каждая статья посвящена конкретному кейсу, с которым может столкнуться пользователь.

Метрики Помощи:

Flow — количество просмотров определенной статьи за период. В динамике мы понимаем медиану, которую ожидаем каждый месяц и возможные триггеры, которые могут дать здоровый рост к просмотрам — например, временная акция, значительное продуктовое изменение, технические неполадки или даже сезонность.

CR или конверсия — % пользователей, которые заходили в Помощь и после этого написали в поддержку. Для снижения конверсии UX-редакторы регулярно вычитывают обращения, чтобы найти часто повторяющиеся вопросы, ответы на которые можно отразить в Помощи. При этом мы пониманием, что не во всех статьях или тематиках можно (и нужно) снижать CR, потому что статьи отличаются по степени активной пользовательской включенности.

Мы классифицируем статьи Помощи так:

1. Пользователь может всё сделать сам

Это частая разновидность и самая позитивная с точки зрения влияния на CR выборка статей. Например, статья «Как забронировать товар» приводит пользователя в карточку объявления, где он может выбрать соответствующий пункт. Это на 100% потенциальный селф-сервис.

2. Пользователь обычно всё делает сам, но в части кейсов нужна помощь

Такое бывает, когда статус пользователя или, например, технические устройства его смартфона не дают возможности выполнить инструкция и незначительная часть обращений для решения вопроса пройдёт через поддержку. Этот % — наш минимальный CR, который очень сложно снизить только с помощью контента.

3. В статье предусмотрено обращение в поддержку

Например, по процессу агент поддержки должен получить от пользователя пакет документов, чтобы подтвердить достоверность объявления. В таких статьях стабильно высокий CR, потому что обращение здесь — этап пользовательского пути

Снижение CR здесь выступает как метрика перевода обращений в селф-сервис, когда человек решает свой вопрос самостоятельно, компания экономит косты на поддержке и не теряет клиента.

2. Чат-боты

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

Метрики ботов:

Автоматизация — одна из основных метрик. Это % обращений, которые смогли решить без переключения на агента поддержки. Чтобы повысить автоматизацию, UX-редактор использует те же самые навыки и принципы работы — знание контекста и рисёрч реальных обращений. UX-редакторы работают в паре с бизнес-аналитиками, чтобы выбрать максимально импактные сценарии. Автоматизация позволяет закрывать часть вопросов без привлечения агентов поддержки, используя агентское время максимально эффективно.

3. Сценарии и шаблоны

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

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

Метрики сценариев и шаблонов:

CSAT/DSAT (Customer Satisfaction/Dissatisfaction Score) — метрика удовлетворённости, выставляется после того, как пользователь пообщался с поддержкой в чате или звонке. Обычно после общей оценки мы выводим уточнение, чтобы понять, что именно понравилось/не понравилось и у какого департамента есть возможность влиять на ситуацию. Например, если пользователю не понравились правила Авито, становится понятно, что у отдела контента здесь мало влияния.

FCR — % обращений, которые были решены с первого же касания без реопенов (то есть повторных обращений по той же или схожей тематике). Чтобы такое случилось, ответ должен быть конкретным и полным, иногда включать ответы на вопросы, которые пользователь ещё не задал. Работа с регламентами и шаблонами в таком формате будет проактивной, «предсказывающей», учитывающей одновременно несколько факторов.

Работа со сценариями и шаблонами влияет в том числе на LTV (Life Time Value) — объём прибыли, которую клиент принесёт за всё время взаимодействия с компанией. Чем это время дольше, тем больше потенциальная прибыль, поэтому через коммуникации с поддержкой нам важно растить лояльность. Высокий FCR показывает, что мы как компания умеем а) распознавать интент пользователя — то есть тот запрос, с которым он к нам обратился б) давать на этот запрос полный, корректный и понятный ответ. Низкий FCR, в свою очередь, даёт понять, что на одном из этапов (распознавание или сам ответ) у нас есть сложности. И пользовательская лояльность, а вместе с ней и шанс, что клиент с нами надолго, падает.

***

А теперь давайте ответим на вопрос «есть ли у текста влияние на метрики»?

Если мы говорим об изолированном тексте — то есть когда одни слова мы заменили на другие слова, не включая работу с контекстом, логикой, возможностями и ограничениями пользовательского пути, то влияния часто или нет, или оно настолько невелико, что его почти невозможно посчитать.

Но я думаю, вы уже поняли: UX-редактор никогда не работает с изолированным текстом.

Давайте разберём кейс: в Помощи Авито есть статья о том, как правильно вводить VIN (Vehicle Identification Number) автомобиля. Этот номер состоит из 17 символов и указывается арабскими цифрами и буквами латинского алфавита за исключением букв I, O и Q, чтобы не перепутать их с цифрами 1 и 0 — то есть возможностей ошибиться при вводе полным-полно.

При этом по процессу, если пользователь ошибся в VIN несколько раз или введённый VIN не совпал с остальными указанными данными, мы просим прислать документ, чтобы убедиться, что автомобиль вообще существует и есть в наличии — это естественным образом растит CR, то есть конверсию в поддержку.

Чтобы снизить количество ошибок при вводе, сперва мы пошли простым путём:

написали инструкцию, как вводить VIN;
приложили скриншоты, где искать VIN;
вынесли отдельно все ошибкоопасные места: писать только латиницей, не использовать буквы I, O и Q, заполнять все 17 символов.

CR незначительно снизился и встал на плато. Пришлось идти в более глубокий рисёрч — делать выгрузку обращений, вычитывать и искать повторяющиеся запросы. Тут-то мы обнаружили ~~Эльдорадо~~ ещё один крупный кейс, который не был проработан в статье: автомобили, у которых вообще нет VIN. Мы запросили позиционирование у продукта, обогатили статью дополнительной инструкцией, что делать владельцам таких автомобилей, и увидели долгожданное падение CR.

Так текст повлиял на метрики.

Часть четвёртая

Навыки UX-редактора

Роль UX-редактора довольно комплексная и объединяет в себе несколько направлений. Два основных понятны из названия: UX и редактура, но давайте посмотрим, какой топ навыков поможет качественно развиться в роли.

1. Системное мышление

Практически все контентные продукты клиентского сервиса — это логически сложные сценарии с большим количеством развилок. Самый яркий пример такого контента: чат-бот. Чем больше бот умеет делать, тем сложнее UX-редактору — должны быть описаны все сценарии с учётом найденных (или не найденных) данных.

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

2. Эмпатия

Создание работающего Tone of Voice (документа, описывающего основные принципы голоса бренда: как мы общаемся с нашей аудиторией) сильно зависит от того, насколько хорошо мы можем спрогнозировать реакцию пользователей на определенные типы кейсов и подобрать те слова, которые помогут сделать ситуацию лучше, а не хуже.

Список таких триггерных ситуаций очень часто один и тот же:

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

3. Коммуникации

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

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

Те, кто приходит в UX-редактуру с ожиданием, что в основном это работа с текстом, бывает сильно удивлён. В зависимости от грейда на 50-90% рабочее время будет занято созвонами.

Часть пятая

Ключевые принципы работы UX-редактора

Предлагаю рассмотреть основные принципы нашей роли на примере 10 эвристик Якова Нильсена, эксперта по пользовательскому опыту.

1. Ясный статус системы

Сэкономив на отображении статусов и сроков решения у обращения в поддержку, можно получить или дубли одного и того же вопроса, или повторные обращения (реопены), которые никак не ускоряют решение обращения, потому что отодвигают его в очереди.

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

2. Соответствие реальному миру

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

Такое соответствие должно быть проработано в общем Tone of Voice или редполитике компании.

3. Контроль и свобода

Для того, чтобы человек мог решить свой вопрос, мы предоставляем ему альтернативы там, где это возможно, чтобы он выбрал лучшую из них — хотите, дадим ссылку на инструкцию в чат? Пришлём письмом на почту? Может, сделаем вместе прямо сейчас, если удобно?

4. Последовательность и стандарты

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

5. Предотвращение ошибок

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

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

6. Узнаваемость, а не запоминание

Есть определённые привычные UX-паттерны, которые не стоит ломать — например, чат с подсказками пользователь ожидает увидеть в правом нижнем углу, а не в верхней панели или где-то глубоко в меню.

7. Гибкость и эффективность

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

8. Эстетичность и минимализм

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

9. Помощь пользователям в распознавании, диагностике и исправлении ошибок

А ещё лучше — в предупреждении, что делать и чего не делать. Массовая ошибка всегда провоцирует рост обращений, UX-редактор в таких случаях готовит текст на главную страницу для плашки ошибки. Чтобы снизить поток, в тексте нужно сообщить несколько вещей:

суть ошибки — прямо сейчас не получается отредактировать объявления;
статус ошибки — мы знаем об этом и уже работаем над тем, чтобы всё исправить;
что делать пользователю — вам ничего не нужно делать с этим, только подождать. попробуйте через час, к этому времени всё должно работать

10. Справка и документация

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

Это то, зачем UX-редактор существует в клиентском сервисе и пишет статьи в раздел Помощь, шаблоны в поддержку и чат-ботов.

Часть шестая
Выводы

Давайте подведём итоги и резюмируем всё, о чём говорили в этой главе:

UX-редактор в клиентском сервисе — это человек, который проектирует клиентский опыт с помощью контента

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

Качество контента можно и нужно измерять с помощью метрик

Хороший контент это тот, с помощью которого можно наилучшим образом решить поставленную задачу. Есть простой пример, многократно протестированный в реальных условиях: конверсия из статьи, написанной без рисёрча обращений пользователей, в разы будет отличаться от той, где мы отвечаем на реальные пользовательские запросы. А в мире клиентского сервиса чем конверсия из статьи ниже — тем лучше, потому что это означает снижение количества обращений.

В роли UX-редактора навык работы с текстом не единственный и не самый главный

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

Ключевые принципы UX-редакторов основаны на базовом качественном взаимодействии пользователя с системой

И ни одного слова о том, как подписывать кнопки, потому что это — не главное.

P.S. Но если вам интересно, по классике текст кнопки должен быть продолжением фразы «я хочу». Например, я хочу [КУПИТЬ] или [ЗАРЕГИСТРИРОВАТЬСЯ].