Привет, это Наташа, лид-редактор в UX Яндекс.Денег. Я пишу этот текст, потому что больше не могу молчать о своей работе.
Раньше про нас думали, что мы копирайтеры. Пишем получше, чем менеджеры. Умеем проверять грамотность. Редактируем, чтобы стало понятнее. Убираем лишние слова.
Теперь думают, что мы писатели микротекста. Изобретаем правильный коллтуэкшн для кнопки. Проверяем, правильно ли называется ссылка. Режем всё, что плохо лежит.
Ну и что тебе не нравится, Наташ?
Я не отрекаюсь от кнопок, ссылок, лейблов и тултипов. Я их люблю, выпиливаю лобзиком, складываю и раскладываю, разве что по барам не вожу.
Но это всё — примерно шестая часть моей (нашей) работы. Последняя. Когда пройдено пять шестых. Как-то так: сначала сходил в магазин за продуктами, помыл овощи, снял кожуру, нарезал кубиками и соломкой, сделал бульон, раз в десять минут прибегал посмотреть, не убежало ли. И вот наконец добавляешь соль, перец и лаврушку. Кнопки, ссылки, тултипы. Буквы.
Мне (нам) чертовски не хватает людей, которые понимают, что конкретный текст — это суперважный, но всё-таки последний этап в работе UX-редактора.
Нельзя просто взять и «написать одну кнопку», или «придумать вот сюда заголовок», или «поправить буквы на макете». Макет — не отдельная картинка в рамочке: это почти всегда часть какого-то процесса. А процесс — часть продукта, для которого мы все (дизайнеры, редакторы, аналитики и продакт-менеджеры) прорабатываем UX.
В самом начале, на уровне смысла
У редакторов в Деньгах есть такая условная раскладка:
— сначала ты работаешь на уровне общего смысла,
— потом решаешь, как разложить этот смысл по шагам и приоритетам,
— в конце переходишь к формулировкам и тональности.
Первый этап — про смысл — подразумевает, что UX-редактор подключается к проекту в самом начале. И когда я говорю «в самом начале», я не про точку «дизайнер начинает прорабатывать макеты». Я про реальное начало: есть обоснование, идея и общий концепт, началась проработка техрешения (или даже не началась).
Вот тут в игру вступает маленькая UX-team: дизайнер и редактор.
При чём тут вообще техрешение
Я не аналитик, не разработчик, не продакт-оунер. Я не полезу в то, как компоненты системы должны общаться между собой или как новая техническая схема повлияет на бизнес-показатели.
Но мы в паре с UX-дизайнером полезем в другое — вот, например:
— какие состояния пользователя нужно учесть на форме: этих людей можно сразу отправить платить, других нужно провести через анкету с персональными данными,
— какие данные подтянуть на конкретную страницу: вот здесь важен остаток долга по кредиту, а там — адрес почтового отделения, куда приедет банковская карта,
— какую логику заложить для статусных сообщений: вот здесь точно нужна отдельная страница с подробностями (и туда, кстати, надо пробросить данные с первого шага), а там логичнее просто вернуть в раздел и повесить маленькую подсказку к конкретному пункту.
Это не значит, что кроме нас про логику и нюансы некому подумать. Это значит, что редактор и дизайнер всегда обсуждают техрешение, чтобы убедиться: нужные нам данные, статусы, параметры на месте. Значит, можно работать дальше.
С технического на человеческий
Есть человек, и человек хочет что-то сделать. Есть система, которая это может: но для начала ей нужно что-то взамен.
Одна из главных задач UX-редактора — помнить, что он работает на человека. Поэтому всё, что система хочет от человека, редактор переводит на человеческий язык. Сначала — на уровне смысла, потом на уровне текста.
Про общий смысл
Огромная часть нашей работы проходит под знаком созвездия «Почему». Вероятно, это вообще любимый вопрос UX-редактора.
— Почему мы считаем, что людям это важно, спросит редактор у продакт-менеджера.
— Почему обязательно проводить человека через эту точку, спросит у аналитика.
— Почему мы валидируем вот эти данные по-разному, спросит у разработчика.
— Почему мы вообще хотим, чтобы человек это указал, спросит у кого-то ещё.
Моя идеальная футболка для встреч
Некоторые «потому что» будут простыми и понятными: человек и система хотят примерно одного и того же, просто формулируют это по-разному. Дальше — дело текста.
Другие будут завязаны на сложную внутреннюю логику или ограничения системы. Но после серии «почему» вполне может оказаться, что логику можно поменять, а ограничения обойти. Так редактор повлияет на сценарий, и вместо пяти экранов (семи кнопок) останется два экрана (кнопки — три). Тру стори, риал лайф.
Про текст
Навскидку, если не очень глубоко погружаться, кажется: интерфейсные тексты должны подчиняться строгим правилам. Кнопка — глагол. Тумблер — вкл/выкл. Ссылка — указание на место. Вроде всё просто.
Мы верим в другое: интерфейсные тексты — отражение человеческой манеры вести диалог.
— Система хочет, чтобы пользователь «ознакомился с условиями» и нажал «Подтвердить». Я как человек хочу сказать ей, что мне «Понятно».
— Система хочет сказать: ошибка, неправильный номер. Я хочу увидеть: здесь опечатка — проверьте номер ещё раз.
Конечно, это возможно не всегда, и работает не всегда. Кроме всего прочего ещё и потому, что человечность текста — чертовски субъективная штука.
К примеру, нам долгое время казалось, что для технических ошибок есть отличный заголовок — «Что-то пошло не так». Подходит для любых кейсов, указывает на факт ошибки, при этом в нём ни капли роботизированности. Но время и фидбэк показали: людей очень раздражает, когда «что-то идёт не так». Что, спрашивают они, что именно? В общем, в новых ошибках «чего-то» больше нет (а старые мы понемногу отлавливаем).
Это не кончится никогда (привет, чат)
Раньше мне казалось: ты начал проект, ты работал, ты дошёл до запуска — можно выдохнуть и переключиться на следующую задачу.
Теперь я знаю, что так не бывает.
Редактор (и дизайнер) остаются в режиме хронической поддержки, потому что: а) продукт всё время меняется, б) пользователи приходят с новыми вопросами или даже в) какая-то фича в итоге сработала не так, как мы ожидали.
Например, с командой банковских карт у меня два чатика. Один продуктовый: там PO, PM, аналитик, человек от саппорта и мы с дизайнером от UX. Второй чатик с фронтендом: там опять мы с дизайнером, PM и разработчики.
Продуктовый чат нужен, чтобы всё продуктовое не проходило мимо. Например: саппорт сигналит, что люди начали часто приходить с похожим вопросом. Мы тут же обсуждаем, чем это лечить: дизайном, текстом, доработками на бэках (или вообще всем сразу).
В чате с фронтендом решаем потоковые задачи: не хватает подсказки для поля, где-то выравнивание поехало. Или даже — какую проверку на бэках лучше использовать с точки зрения UX в этом конкретном месте: синхронную или асинхронную (мне объяснили разницу, теперь при каждом удобном случае я показываю, что в теме).
В итоге вся команда у тебя под рукой. И ты под рукой. Удобно.
Коллективный разум, +1
UX-редакторы — это не идеальные машины по обработке информации. Мы ошибаемся, тупим, забываем учесть что-то важное. Или наоборот, так глубоко погружаемся в контекст, что почти невозможно вынырнуть и посмотреть на собственную работу свежим взглядом пользователя.
Есть очевидные способы, как с этим бороться. Дай посмотреть коллеге, который не знает деталей, понаблюдай за пользователем на исследовании, переключись на другую задачу и возвращайся, когда немного отвыкнешь от контекста.
Есть менее очевидные: собирай удачные решения в библиотеку, выводи алгоритмы, на которые сможешь опираться в новых проектах.
И ещё есть команда — как коллективный мозг. И этой команде нужно больше UX-редакторов: изучать техрешения, думать про смысл, вытачивать слова (и тупить периодически, куда без этого).
Если у вас есть на примете такой человек, или вы сами такой человек, посмотрите нашу вакансию.
