Привет, это Наташа, лид-редактор в UX Яндекс.Денег. Я пишу этот текст, потому что больше не могу молчать о своей работе.
Раньше про нас думали, что мы копирайтеры. Пишем получше, чем менеджеры. Умеем проверять грамотность. Редактируем, чтобы стало понятнее. Убираем лишние слова.
Теперь думают, что мы писатели микротекста. Изобретаем правильный коллтуэкшн для кнопки. Проверяем, правильно ли называется ссылка. Режем всё, что плохо лежит.
Ну и что тебе не нравится, Наташ?
Я не отрекаюсь от кнопок, ссылок, лейблов и тултипов. Я их люблю, выпиливаю лобзиком, складываю и раскладываю, разве что по барам не вожу.
Но это всё — примерно шестая часть моей (нашей) работы. Последняя. Когда пройдено пять шестых. Как-то так: сначала сходил в магазин за продуктами, помыл овощи, снял кожуру, нарезал кубиками и соломкой, сделал бульон, раз в десять минут прибегал посмотреть, не убежало ли. И вот наконец добавляешь соль, перец и лаврушку. Кнопки, ссылки, тултипы. Буквы.
Мне (нам) чертовски не хватает людей, которые понимают, что конкретный текст — это суперважный, но всё-таки последний этап в работе UX-редактора.
Нельзя просто взять и «написать одну кнопку», или «придумать вот сюда заголовок», или «поправить буквы на макете». Макет — не отдельная картинка в рамочке: это почти всегда часть какого-то процесса. А процесс — часть продукта, для которого мы все (дизайнеры, редакторы, аналитики и продакт-менеджеры) прорабатываем UX.
В самом начале, на уровне смысла
У редакторов в Деньгах есть такая условная раскладка:
— сначала ты работаешь на уровне общего смысла,
— потом решаешь, как разложить этот смысл по шагам и приоритетам,
— в конце переходишь к формулировкам и тональности.
Первый этап — про смысл — подразумевает, что UX-редактор подключается к проекту в самом начале. И когда я говорю «в самом начале», я не про точку «дизайнер начинает прорабатывать макеты». Я про реальное начало: есть обоснование, идея и общий концепт, началась проработка техрешения (или даже не началась).
Вот тут в игру вступает маленькая UX-team: дизайнер и редактор.
При чём тут вообще техрешение
Я не аналитик, не разработчик, не продакт-оунер. Я не полезу в то, как компоненты системы должны общаться между собой или как новая техническая схема повлияет на бизнес-показатели.
Но мы в паре с UX-дизайнером полезем в другое — вот, например:
— какие состояния пользователя нужно учесть на форме: этих людей можно сразу отправить платить, других нужно провести через анкету с персональными данными,
— какие данные подтянуть на конкретную страницу: вот здесь важен остаток долга по кредиту, а там — адрес почтового отделения, куда приедет банковская карта,
— какую логику заложить для статусных сообщений: вот здесь точно нужна отдельная страница с подробностями (и туда, кстати, надо пробросить данные с первого шага), а там логичнее просто вернуть в раздел и повесить маленькую подсказку к конкретному пункту.
Это не значит, что кроме нас про логику и нюансы некому подумать. Это значит, что редактор и дизайнер всегда обсуждают техрешение, чтобы убедиться: нужные нам данные, статусы, параметры на месте. Значит, можно работать дальше.
С технического на человеческий
Есть человек, и человек хочет что-то сделать. Есть система, которая это может: но для начала ей нужно что-то взамен.
Одна из главных задач UX-редактора — помнить, что он работает на человека. Поэтому всё, что система хочет от человека, редактор переводит на человеческий язык. Сначала — на уровне смысла, потом на уровне текста.
Про общий смысл
Огромная часть нашей работы проходит под знаком созвездия «Почему». Вероятно, это вообще любимый вопрос UX-редактора.
— Почему мы считаем, что людям это важно, спросит редактор у продакт-менеджера.
— Почему обязательно проводить человека через эту точку, спросит у аналитика.
— Почему мы валидируем вот эти данные по-разному, спросит у разработчика.
— Почему мы вообще хотим, чтобы человек это указал, спросит у кого-то ещё.
Моя идеальная футболка для встреч
Некоторые «потому что» будут простыми и понятными: человек и система хотят примерно одного и того же, просто формулируют это по-разному. Дальше — дело текста.
Другие будут завязаны на сложную внутреннюю логику или ограничения системы. Но после серии «почему» вполне может оказаться, что логику можно поменять, а ограничения обойти. Так редактор повлияет на сценарий, и вместо пяти экранов (семи кнопок) останется два экрана (кнопки — три). Тру стори, риал лайф.
Про текст
Навскидку, если не очень глубоко погружаться, кажется: интерфейсные тексты должны подчиняться строгим правилам. Кнопка — глагол. Тумблер — вкл/выкл. Ссылка — указание на место. Вроде всё просто.
Мы верим в другое: интерфейсные тексты — отражение человеческой манеры вести диалог.
— Система хочет, чтобы пользователь «ознакомился с условиями» и нажал «Подтвердить». Я как человек хочу сказать ей, что мне «Понятно».
— Система хочет сказать: ошибка, неправильный номер. Я хочу увидеть: здесь опечатка — проверьте номер ещё раз.
Конечно, это возможно не всегда, и работает не всегда. Кроме всего прочего ещё и потому, что человечность текста — чертовски субъективная штука.
К примеру, нам долгое время казалось, что для технических ошибок есть отличный заголовок — «Что-то пошло не так». Подходит для любых кейсов, указывает на факт ошибки, при этом в нём ни капли роботизированности. Но время и фидбэк показали: людей очень раздражает, когда «что-то идёт не так». Что, спрашивают они, что именно? В общем, в новых ошибках «чего-то» больше нет (а старые мы понемногу отлавливаем).
Это не кончится никогда (привет, чат)
Раньше мне казалось: ты начал проект, ты работал, ты дошёл до запуска — можно выдохнуть и переключиться на следующую задачу.
Теперь я знаю, что так не бывает.
Редактор (и дизайнер) остаются в режиме хронической поддержки, потому что: а) продукт всё время меняется, б) пользователи приходят с новыми вопросами или даже в) какая-то фича в итоге сработала не так, как мы ожидали.
Например, с командой банковских карт у меня два чатика. Один продуктовый: там PO, PM, аналитик, человек от саппорта и мы с дизайнером от UX. Второй чатик с фронтендом: там опять мы с дизайнером, PM и разработчики.
Продуктовый чат нужен, чтобы всё продуктовое не проходило мимо. Например: саппорт сигналит, что люди начали часто приходить с похожим вопросом. Мы тут же обсуждаем, чем это лечить: дизайном, текстом, доработками на бэках (или вообще всем сразу).
В чате с фронтендом решаем потоковые задачи: не хватает подсказки для поля, где-то выравнивание поехало. Или даже — какую проверку на бэках лучше использовать с точки зрения UX в этом конкретном месте: синхронную или асинхронную (мне объяснили разницу, теперь при каждом удобном случае я показываю, что в теме).
В итоге вся команда у тебя под рукой. И ты под рукой. Удобно.
Коллективный разум, +1
UX-редакторы — это не идеальные машины по обработке информации. Мы ошибаемся, тупим, забываем учесть что-то важное. Или наоборот, так глубоко погружаемся в контекст, что почти невозможно вынырнуть и посмотреть на собственную работу свежим взглядом пользователя.
Есть очевидные способы, как с этим бороться. Дай посмотреть коллеге, который не знает деталей, понаблюдай за пользователем на исследовании, переключись на другую задачу и возвращайся, когда немного отвыкнешь от контекста.
Есть менее очевидные: собирай удачные решения в библиотеку, выводи алгоритмы, на которые сможешь опираться в новых проектах.
И ещё есть команда — как коллективный мозг. И этой команде нужно больше UX-редакторов: изучать техрешения, думать про смысл, вытачивать слова (и тупить периодически, куда без этого).
Если у вас есть на примете такой человек, или вы сами такой человек, посмотрите нашу вакансию.
Комментарии (38)
Zverevivan
08.02.2019 10:44+1Стало понятнее в чём ценность работы UX-редактора и как всё это у вас устроено. Не думал, что вы ещё тех решения читаете)
cyber_roach
08.02.2019 11:02+1Люблю читать про различные узкие направления в IT.
В Яндексе на каждом сервисе свой UX-редактор? Если так, то здорово наверно под рукой иметь армию коллег по цеху.Tasha-txt Автор
08.02.2019 15:29Ну, вот внутри Яндекс.Денег каждый редактор принадлежит нескольким продуктовым командам. И, конечно, страхуем друг друга)
dom1n1k
08.02.2019 12:10Насколько же разительно отличаются статьи — даже такие обзорно-поверхностные — людей в теме от писанины журналиста, который сам только вчера узнал о предмете.
Tasha-txt Автор
08.02.2019 21:24Спасибо)
И, кстати, да: я понимаю, что обзорно-поверхностная. Но с чего-то нужно начинать)
Marnin
08.02.2019 12:22Спасибо! А как вы пришли в UX-редактуру?
Tasha-txt Автор
08.02.2019 15:37Из обычной :) Просто в самом начале, конечно, вот этого понимания роли и этого набора задач не было — росло и крепло со временем.
JerryJJ
08.02.2019 18:17А почему вы продолжаете называть себя «редактором»? Обычная работа проектировщика взаимодействия — путь по сервису, состояния, сообщения. Все стандартно, все по книжкам
Tasha-txt Автор
08.02.2019 21:27Ну, не сказала бы, что обычная. Потому что мы же в итоге всё-таки погружаемся в формулировки на каждом шаге.
То есть UX-редактор в итоге отвечает и за общий смысл (вместе с дизайнером), и за каждое слово, и за tone of voice.JerryJJ
09.02.2019 00:44Так любой проектировщик взаимодействия погружается в формулировки. Если не погрузится, у него получится какое-нибудь неоднозначное, а то и непредсказуемое взаимодействие :) Дизайнера вообще можно не привлекать, пока до графики не дошло. Так что, в классическом варианте это все на проектировщике. Вот общий tone of voice, соглашусь, проектировщики не задают, как правило. Но тогда под большим вопросом приставка «UX» — вы ведь не называли себя так, работая в издательстве (журнале или газете, простите, я не в курсе), хотя именно там напрямую определяли «UX» читателей :) В общем, я к чему это — в рамках взаимодействия с профессиональным сообществом должность «UX-редактор» всех только путает и вызывает вопросы, причем странные :)
Tasha-txt Автор
09.02.2019 15:10Честно говоря, в первый раз сталкиваюсь с мнением, что путает. По-моему, всё наоборот :)
За пределами IT (ну вот в издательствах, например) нет продакт-менеджеров, нет программистов. Когда человек говорит: «Я программист», ни у кого не возникает вопросов, в чём суть этой работы.
А вот редакторы как раз есть и в издательствах, и в интернет-журналах, и в корпоративных блоках — ну где угодно. Если я скажу: «Я редактор», проще всего решить: она редактор в журнале. Поэтому, опять: приставку UX не отдам, она моя :)
wyric
08.02.2019 14:31+2Уважаемый редактор. Поясните, пожалуйста, термин UX-редактор.
Я понимаю что от написанных текстов зависит пользовательский опыт… Но он зависит и от качества реализованного бекенда, не тупит ли сервис. Мы же не называем бекендера UX-бекендером. И от решений продакт менеджер тоже многое зависит, в том числе и пользовательский опыт. Он уже точно принимает решения которые влияют на него (например экономит ресурсы и выпиливает фичу из релиза). Но почему его не называют UX-продакт-менеджер?Tasha-txt Автор
08.02.2019 15:35А я с вами полностью согласна: на UX влияют все в компании — каждый разработчик, каждый менеджер, тестировщик, аналитик, саппортёр и так далее.
Просто в итоге-то пользователь не работает с чистым кодом, или бизнес-планом, или техническим решением. Он сталкивается с тем, как редактор + дизайнер перевели вот это всё внутреннее с технического на человеческий, трансформировали сценарии, разложили смысл по полочкам.
Так что приставку UX не отдам, она моя :)
stanislavkulikov
08.02.2019 14:52А расскажите, насколько и как в начале работы учитываются пользовательские ожидания. Т.е. вы проводите какие-то исследования пользовательской активности или придумываете сценарии из головы?
Tasha-txt Автор
08.02.2019 16:56А вот про это мы немного рассказывали в статье про редизайн нашего приложения
kababok
08.02.2019 18:10А что бы вы предложили почитать на UX-тему помимо "Ководства" и "Бизнес-линча"? :)
Tasha-txt Автор
08.02.2019 20:48Какие-то сечас суперстандартные варианты озвучу: «Не заставляйте меня думать», «Психбольница в руках пациентов» (ну, потому что они, может быть, не про конкретные инструменты, а скорее про общий принцип).
А про работу с текстом, конечно, Максим Ильяхов чертовски полезный (если без фанатизма). И мы вот сейчас парочку зарубежных книг ждём, они конкретно про UX-writing: Conversational Design (Erika Hall), The Content Strategy Toolkit (Meghan Casey). Анонсы звучали круто — посмотрим, что внутри :)
dzsysop
08.02.2019 18:57Всегда приятно увидеть и услышать профессионала в своем деле!
И просто мысли вслух по поводу UX:
«Подтвердить». Я как человек хочу сказать ей, что мне «Понятно».
Тут еще одна проблема есть, просто инерция. Если 90% таких же кнопок по всему интернету «Подтвердить», а в нашем проекте пусть и понятнее, но не так как везде — это порой сильно путает пользователя.Tasha-txt Автор
08.02.2019 20:42+1Спасибо)
И про путаницу: мне кажется, всё дело в контексте. Если речь про какой-то формальный шаг (и главное, чтобы человек просто его прошёл — максимально быстро), то да: привычные паттерны «как везде» наверняка работают лучше. Хотя, опять-таки, не хочу обобщать — про каждый кейс стоит отдельно подумать и прикинуть варианты.
Если нам важно, чтобы человек на конкретном шаге обратил на что-то внимание — неожиданная «человеческая» кнопка может с этим помочь. Ну, и лучший вариант, на мой взгляд — прямо на кнопке обозначать целевое действие. Условно: не «Подтвердить», а «Да, удаляю карту». Как-то так :)
ragequit
08.02.2019 20:59Все же влияние микротекста сказывается :) Очень много коротких и\или перечисляющих что-либо предложений. Предложения-тезисы из одного слова, общая «раздробленная» структура (много мелких абзацев).
А как же сторителлинг? Неужели вся эта кропотливая, до кровавого пота, бесконечная возня с ссылками, проектами, кнопками и не бог весть чем еще все же убила внутреннего Льва Толстого?Tasha-txt Автор
08.02.2019 21:03Нет, не убила — у меня просто его и не было никогда.
А сторителлинг хорош: в письмах, на лэндингах и эбаутах. Интерфейсный процесс — это всё-таки совсем же другая история :)
4tlen
08.02.2019 21:41+1При чём тут вообще техрешение
Вся глава про попытку угадать намерения пользователя. Не угадаете. Нет ничего хуже когда интерфейс основываясь на статистике пытается помочь. Все предиктивные системы ввода до сих пор работают через жопу, а вы тянете этот подход в другой уровень абстракции, вместо простых человеческих указателей.
Вот абсолютно тупой пример: зачем в меню слева «Денежные переводы», а заходишь туда и там уже нужный мне интерфейс «Перевод денег». Почему сразу не написать «перевести деньги»? Ведь другой функции у интерфейса по этой ссылке нет.Tasha-txt Автор
08.02.2019 21:57Дайте-ка угадаю :) Наверное, этот комментарий не к блоку про техрешение, а к блоку про перевод с системного на человеческий. Потому что в блоке про техрешение ничего про угадывание нет.
Про меню: подумаю про это, спасибо за фидбэк. Но вообще меню — это же набор сущностей. Есть оплата услуг, есть банковские карты, есть переводы. Ну и внутри переводов — возможность перевести.4tlen
08.02.2019 22:14+1Потому что в блоке про техрешение ничего про угадывание нет
— какие состояния пользователя нужно учесть на форме
— какие данные подтянуть на конкретную страницу
— какую логику заложить для статусных сообщений
Это вот все про угадывание. Вы не сможете учесть все состояния. Да и не нужно. Для UX-копирайтинга есть одно отличное правило — опиши максимум в двух словах что будет если нажать. Применительно к сервису я.деньги там вообще нужны всего три кнопки: пополнить счет, оплатить что-то и перевести куда-то. Потом уже вокруг этого минималистичного интерфейса навешивать бизнес-задачи.Tasha-txt Автор
09.02.2019 15:14Состояние пользователя и данные процесса — это не угадывание, это логика. Я же не про эмоциональное состояние, «пользователь грустит» :) Я про характеристики: вот версия для незалогиненных, вот для тех, кто уже выпустил карту, вот для тех, у кого смс-пароли и так далее.
Мы не угадываем, мы предусматриваем максимум из возможного.4tlen
09.02.2019 20:29+1Могу сейчас ошибиться: посмотрите статистику (карты кликов, тепловые карты, вебвизор) тех 20% которые генерят 80% прибыли я.денег. Чуйка подсказывает что там много чего можно сократить в customer jorney. Потому что я активный пользователь сервиса с пониманием темы UX и UX-копирайтинга в частности, и я даю вам фидбэк — все не очень хорошо. Ну или можете продолжать фокус-группы собирать.
lxsmkv
08.02.2019 22:42+2Спасибо за статью. Про копирайт и составление текстов мало пишут. А это действительно очень важная и трудная задача, которая сродни поэзии. В хорошем тексте ни добавить ни убавить нечего. А какие есть ёмкие слоганы! «Das Auto» одно чего стоит.
Про «человечность» текстов, есть такой тренд тексты делать более неформальными, но иногда это в неподходящих местах доходит до неподобающей фамильярности — и вот тут нужно остановиться.
Когда я вижу кнопку «понятно» — я прежде чем ее нажимаю думаю — «Блин, мне же на самом деле нихрена не понятно, я это соглашение мельком пролистал! Но не нажать на эту кнопку нельзя, иначе пользоваться приложением не смогу. Эх, ладно, *тыц*.» И вроде бы всё, закончились мучения мысли, но какой-то осадок остается. Тут лучше бы подошло честное «продолжить». Да, тексты должны быть в первую очередь честными.
Или при завершение, скажем, туториала какого-нибудь — «Ну, поехали!». Даже если это игра — слишком фамильярно. Пользователь должен ощущать себя абсолютным повелителем приложения. Компьютер — молчаливый раб. И нельзя ни на секунду заставить пользоваться усомниться в этой власти. Если тексты сформулированы на несерьезном языке, то и о приложении и компании создается такое-же впечатление. И это мы еще толком не познакомились.Tasha-txt Автор
09.02.2019 15:22+1Полностью с вами согласна: тексты прежде всего должны быть честными. Поэтому мы не используем «Понятно» для акцепта длинных юридических условий.
Я стараюсь всегда напоминать себе, что восприятие текста чертовски субъективно. Если что-то нравится (или не нравится) мне, это ещё ничего не значит. Поэтому в первую очередь мы решаем информационную задачу: самое главное, чтобы всё было понятно. А вот дальше на это «понятно» можно накинуть (или не накинуть) что-то эмоционально окрашенное. С осторожностью :)
ArgentMind
Всё идет к алгоритмам. Это не хорошо и не плохо — это факт.
и яваскриптом генерится текст, а вместо цветовой темы для оформления — смысловая.Начали с дизайна и приведения его в порядок: работа вылилась в БЭМ, Бутстрап и иже. Теперь прям серьезная тенденция по работе с текстами, а начиналось все с, выцарапывающих глаза уже на 70% сайтов, «Наши преимущества и гарантии». Даже интересно, дорастет это до «текстового фреймворка» или нет? Типа
С другой стороны, стандартизация интерфейса, при правильном подходе, позволит передавать в мозг пользователю информацию на порядки быстрее, когда формулировки фраз не отвлекают от смысла. Прям обучение пилотированию вертолёта как в «Матрице» получится. Мечты.
Но творчество окончательно покинет отделы интернет-маркетинга, оставаясь только у компаний создающих паттерны…
Tasha-txt Автор
Хм, не думаю, что в ближайшем будущем тексты будут генериться автоматически.
Мне кажется, мы скорее движемся к систематизации опыта. Например, мы поняли, для определённых кейсов хорошо работает <вот такое> объяснение, или мы нашли удачный заход для подтверждения действий, или что-то ещё верхнеуровневое придумали — вполне можно использовать это как шаблон для похожих задач. Ну, чтобы save brain power для чего-то более сложного :)
ArgentMind
Ну, оформление в бутстрапе тоже автоматически не генерируется, однако стандартизация «элемент — внешний вид — действие» есть. В этом, собственно суть.
Это применимо и к тексту, благо клише, штампов, принятых формулировок, а также сервисов на проверку и редактирование текстов — аж контекстной рекламой продвигаются.
Фреймворк и есть систематизация опыта, кейсов, стандартных наработок =)
Tasha-txt Автор
Ну вот клише и штампы — это всё-таки из другой темы, на мой взгляд. И сервис по проверке текста не продумает за тебя смысл, это скорее про финальное наведения порядка.
Но полностью согласна про «стандартизацию «элемент — внешний вид — действие»»: всё об этом, ага :)