Редактор как часть продукта: зачем текстам продуктовый подход

Привет! Меня зовут Маша Курявская, я руковожу продуктовой редакцией в Яндекс 360.

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

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

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

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

В нашей редакции четыре направления.

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

Хелпцентр — материалы, которые помогают разобраться в продуктах и самостоятельно решить задачу: статьи в Справке, документация API и документация для on-premises-решений.

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

Блог Яндекс 360 для бизнеса — направление, в котором мы регулярно работаем с маркетинговым контентом. В нём мы публикуем примеры внедрения наших сервисов, практические советы по работе с ними, истории клиентов и другие материалы, которые помогают пользователям получать от продуктов больше пользы.

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

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

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

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

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

Пошагово работа выглядит так:

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

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

Стоит ли оно того? Я думаю, да. Так мы с большей уверенностью можем сказать, что попадаем в потребности аудитории и делаем взаимодействие с нашими продуктами проще и понятнее.

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

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

Сейчас мы также активно развиваем взаимодействие со службой поддержки. Это помогает быстрее получать сигналы о том, где мы не угадали потенциальные вопросы пользователей: что оказалось непонятным, какие сценарии мы не описали, какие формулировки стоит уточнить. Так Справка не превращается в статичный набор инструкций, а постоянно достраивается вокруг реального пользовательского опыта.

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

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

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

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

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

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

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

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

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

Ещё мы создаём регулярные точки для рефлексии. В конце недели редакторы ведут небольшую «пятничную газету». Это наша внутренняя неформальная история, когда человек в конце недели просто составляет такой мини-отчётик сам для себя — чего делал, как получилось и прочее. Здоровая рефлексия перед выходными никому не помешает. Особенно, если человек отмечает там, зачем он что-то сделал и какой эффект получил. Или не получил, но хотел.

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

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

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

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