Хабрахабр

Редактор в UX: тру стори, риал лайф

Я пишу этот текст, потому что больше не могу молчать о своей работе. Привет, это Наташа, лид-редактор в UX Яндекс.Денег.

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

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

Ну и что тебе не нравится, Наташ?

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

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

Мне (нам) чертовски не хватает людей, которые понимают, что конкретный текст — это суперважный, но всё-таки последний этап в работе UX-редактора.

Макет — не отдельная картинка в рамочке: это почти всегда часть какого-то процесса. Нельзя просто взять и «написать одну кнопку», или «придумать вот сюда заголовок», или «поправить буквы на макете». А процесс — часть продукта, для которого мы все (дизайнеры, редакторы, аналитики и продакт-менеджеры) прорабатываем UX.

В самом начале, на уровне смысла

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

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

Вот тут в игру вступает маленькая UX-team: дизайнер и редактор.

При чём тут вообще техрешение

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

Но мы в паре с UX-дизайнером полезем в другое — вот, например:

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

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

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

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

С технического на человеческий

Есть система, которая это может: но для начала ей нужно что-то взамен. Есть человек, и человек хочет что-то сделать.

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

Про общий смысл

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

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


Моя идеальная футболка для встреч

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

Но после серии «почему» вполне может оказаться, что логику можно поменять, а ограничения обойти. Другие будут завязаны на сложную внутреннюю логику или ограничения системы. Тру стори, риал лайф. Так редактор повлияет на сценарий, и вместо пяти экранов (семи кнопок) останется два экрана (кнопки — три).

Про текст

Кнопка — глагол. Навскидку, если не очень глубоко погружаться, кажется: интерфейсные тексты должны подчиняться строгим правилам. Ссылка — указание на место. Тумблер — вкл/выкл. Вроде всё просто.

Мы верим в другое: интерфейсные тексты — отражение человеческой манеры вести диалог.

Я как человек хочу сказать ей, что мне «Понятно».
— Система хочет сказать: ошибка, неправильный номер. — Система хочет, чтобы пользователь «ознакомился с условиями» и нажал «Подтвердить». Я хочу увидеть: здесь опечатка — проверьте номер ещё раз.

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

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

Это не кончится никогда (привет, чат)

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

Теперь я знаю, что так не бывает.

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

Один продуктовый: там PO, PM, аналитик, человек от саппорта и мы с дизайнером от UX. Например, с командой банковских карт у меня два чатика. Второй чатик с фронтендом: там опять мы с дизайнером, PM и разработчики.

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

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

И ты под рукой. В итоге вся команда у тебя под рукой. Удобно.

Коллективный разум, +1

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

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

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

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

Если у вас есть на примете такой человек, или вы сами такой человек, посмотрите нашу вакансию.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть