Всем привет! Меня зовут Аня Ведяпина — я UX-писатель слэш контент-дизайнер, сейчас в QIC, до этого в Movavi, Кошельке и Т-Банке. Вот уже 5 лет кручу смыслы вокруг проблем бизнеса вместе с дизайнерами, аналитиками и продактами и упаковываю результат в складный интерфейсный текст. А иногда и нет, и это тоже часть моей работы.
Я была первым и долгое время единственным специалистом в двух компаниях, где внедряла процессы с нуля. Поэтому решила собрать уроки, которые я из этого вынесла. Статей на тему написано неприлично много, поэтому никакой претензии на game-changing insights, только личный опыт. Погнали!
Кратко по базе
Если вы впервые встречаетесь с таким сочетанием букв, как UX-писатель, то вот небольшая вводная для вас.
Определение по первой ссылке в гугле
UX-писатель — это специалист, который создаёт тексты для интерфейсов. Его главная задача — написать так, чтобы пользователям было проще взаимодействовать с сайтом или приложением.
Моя интерпретация
UX-писатель — специалист, который в последнюю очередь создаёт тексты для интерфейсов, а сначала он:
Изучает продукт, его целевую аудиторию, конкурентов. Вникает в суть проблемы, с которой приходит бизнес.
Подключается в самом начале работы, помогает дизайнеру строить логику и информационную архитектуру интерфейса. Важно, чтобы на экранах всё было интуитивно понятно без вдумчивого чтения текста и решалась бизнесовая задача.
Пишет первую итерацию текста.
Бонус пункт! В идеальных условиях — тестирует решения вместе с дизайнерами (да-да, текст не живет отдельно от дизайна) на реальных пользователях. Затем улучшает свой вариант на основе инсайтов. Но тут как повезёт — всё зависит от времени и темпов проекта. В стартапе большинство решений придется проверять на бою или же довериться аналитике/своей интуиции (нужное подчеркнуть).
Собирает фидбек от продактов/дизайнеров/аналитиков, дошлифовывает финальный вариант.
Дальше уже будут комплаенсы, локализации, релиз ноутсы и другие боссы — всё зависит от команды, но база такова.
Подробнее про роль, задачи, кейсы можно почитать у коллег по цеху, статей много, а мы пойдем дальше.
Как быстро встроиться в команду и сразу быть полезным
Короткий ответ — никак.
Я была первым райтером в двух командах, где моей задачей было не просто вкрутить винтик в большой работающий механизм, быстро написать стайлгайд и провести аудит текущего положения дел. Это важно, но это лишь вершина айсберга, и спешка может навредить.
Что стоит сделать
Познакомиться с продактами. Многие почему-то сначала идут к дизайнерам, что в целом тоже полезно, но весь кладезь хранится именно у продактов — ниточке между командой и бизнесом. Это человек, который знает, почему продукт такой сейчас, и каким мы хотим, чтобы он стал. Он подскажет, какие боли уже есть и на что обращать внимание.
Пройтись по флоу самостоятельно, желательно на проде. Это кажется очевидным, но многие новички сразу бегут в фигму или в бэклог. А лучше сначала попробовать пройти путь пользователя: где затыки, что непонятно, какие тексты вызывают вопросы.
Разобраться, как тут вообще всё устроено. Какие процессы уже есть? Как работают над фичами в командах? А сколько их вообще? Где тексты хранятся? Кто до этого их писал?
Собрать боли, которые уже есть. Перед тем как предлагать что-то глобальное, нужно собрать информацию: какие проблемы уже замечали? Где пользователи теряются? Потом коротко рассказать команде, что уже увидел. Это поможет сразу показать, что ты не «корректор буков», а человек, который пришёл делать лучше и думать шире.
Предложить формат взаимодействия. В той же презентации можно описать, как ты предлагаешь работать с текстами: как их обсуждать, на каком этапе подключать, куда их складывать. Это поможет сразу задать рамки, а не ждать, когда тебя позовут (или забудут позвать).
Я всегда стараюсь использовать понятные метафоры, например силу трех из сериала 90-х «Зачарованные». Представьте команду UX, где у каждого участника свой уникальный дар, но вместе они обретают настоящую суперсилу — создают классный и доступный пользовательский опыт.
А что не стоит
Идти сразу в бой и делать задачи. Без контекста любые правки будут пальцем в небо.
Влетать с ноги со своим уставом. Кажется, что уже всё знаешь и сейчас всех научишь? Лучше сначала послушать, как тут всё устроено, и понять, какие предложения получится реализовать. Какие-то вещи придется отложить на потом — пусть сначала команда привыкнет, и пользу твою прочувствуют.
Пытаться работать сразу со всеми командами. Да, было. И было больно восставать из пепла после. Хочется начать нести пользу как можно быстрее, но практика показывает, что эффективнее идти шаг за шагом. Например, в QIC было четкое разделение на веб и мобайл, когда я только вышла в команду. Сначала я взяла под крыло все мобильные команды, и только спустя время начала вливаться в веб-направление.
Итого
Сначала разбираемся с продуктом, затем пробуем что-то писать.
Изучаем текущие процессы, кто занимался текстом раньше, есть ли база всех текстов в одном месте.
Собираем боли, показываем находки команде, предлагаем решения. А если еще покажете, что умеете в дата-дривен подход и укажете, какую метрику это может улучшить — +100 очков и уважение продактов.
Едим слона по кусочкам во имя сохранения ментального здоровья. Расфокус и попытки быть везде и сразу очень быстро приведут к выгоранию.
Быть первым — непросто, но возможно. Не спешите сразу менять мир: изучите систему, поймите её слабые места — и тогда всё получится.
