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

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



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


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



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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



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


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


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


    Про текст


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


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


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


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


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


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


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


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


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


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


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


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


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



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


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


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


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


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


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

    Яндекс.Деньги
    172,00
    Как мы делаем Деньги
    Поделиться публикацией

    Комментарии 64

      +2
      Всё идет к алгоритмам. Это не хорошо и не плохо — это факт.

      Начали с дизайна и приведения его в порядок: работа вылилась в БЭМ, Бутстрап и иже. Теперь прям серьезная тенденция по работе с текстами, а начиналось все с, выцарапывающих глаза уже на 70% сайтов, «Наши преимущества и гарантии». Даже интересно, дорастет это до «текстового фреймворка» или нет? Типа
      <p class="sale"></p>
      и яваскриптом генерится текст, а вместо цветовой темы для оформления — смысловая.

      С другой стороны, стандартизация интерфейса, при правильном подходе, позволит передавать в мозг пользователю информацию на порядки быстрее, когда формулировки фраз не отвлекают от смысла. Прям обучение пилотированию вертолёта как в «Матрице» получится. Мечты.

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

        Мне кажется, мы скорее движемся к систематизации опыта. Например, мы поняли, для определённых кейсов хорошо работает <вот такое> объяснение, или мы нашли удачный заход для подтверждения действий, или что-то ещё верхнеуровневое придумали — вполне можно использовать это как шаблон для похожих задач. Ну, чтобы save brain power для чего-то более сложного :)
          0
          Ну, оформление в бутстрапе тоже автоматически не генерируется, однако стандартизация «элемент — внешний вид — действие» есть. В этом, собственно суть.
          Это применимо и к тексту, благо клише, штампов, принятых формулировок, а также сервисов на проверку и редактирование текстов — аж контекстной рекламой продвигаются.

          Фреймворк и есть систематизация опыта, кейсов, стандартных наработок =)
            0
            Ну вот клише и штампы — это всё-таки из другой темы, на мой взгляд. И сервис по проверке текста не продумает за тебя смысл, это скорее про финальное наведения порядка.

            Но полностью согласна про «стандартизацию «элемент — внешний вид — действие»»: всё об этом, ага :)
        +1
        Стало понятнее в чём ценность работы UX-редактора и как всё это у вас устроено. Не думал, что вы ещё тех решения читаете)
          0
          Спасибо! А вот читаем)
          +1
          Люблю читать про различные узкие направления в IT.
          В Яндексе на каждом сервисе свой UX-редактор? Если так, то здорово наверно под рукой иметь армию коллег по цеху.
            0
            Ну, вот внутри Яндекс.Денег каждый редактор принадлежит нескольким продуктовым командам. И, конечно, страхуем друг друга)
            +3
            Насколько же разительно отличаются статьи — даже такие обзорно-поверхностные — людей в теме от писанины журналиста, который сам только вчера узнал о предмете.
              0
              Спасибо)

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

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

                        За пределами IT (ну вот в издательствах, например) нет продакт-менеджеров, нет программистов. Когда человек говорит: «Я программист», ни у кого не возникает вопросов, в чём суть этой работы.

                        А вот редакторы как раз есть и в издательствах, и в интернет-журналах, и в корпоративных блоках — ну где угодно. Если я скажу: «Я редактор», проще всего решить: она редактор в журнале. Поэтому, опять: приставку UX не отдам, она моя :)
                          0
                          Да забирайте хоть всю и навсегда, никому не жаль :) Так даже лучше будет ;)))
                            0
                            Договорились: забрала всю целиком и навсегда.
                          0
                          В нормальных процессах и компаниях такого атавизма как проектировщик не существует (имхо конечно). А есть дизайнеры продукта (ui/ux если угодно) и редакторы — которые отвечают за стиль как компания общается и кучк других нюасах связанных с текстами и языками
                            +1
                            Тут мы можем посмотреть на компетенции, которые запрашивают компании от кандидатов в вакансиях дизайнеров продукта. Упор делается на знание инструментов и визуальный дизайн. Иногда — на несложную аналитику (на сложную все-таки нанимают исследователей). Возникает вопрос — кто решает задачу сведения требований бизнеса и пользователей? В несложных проектах и небольших командах (сайт небольшой компании, начинающий стартап) это может быть и один человек. В корпоративном софте или управлении каким-нибудь технологичсеким процессом у одного человека голова треснет. Да и навыки нужны несколько другие. Тут и возникает на сцене тот самый «атавизм», ибо системные и бизнес-аналитики не владеют методами проектирования интерфейсов, а продуктовый дизайнер обучен визуальной части и просто не осилит большой объем работы с бизнес-логикой. Так что, в целом я с вами согласен, но слова «нормальных процессах и компаниях» предлагаю заменить на «процессах, прижившихся во многих компаниях». Так будет точнее :)
                              0
                              Поясню в тезизах
                              — в компаниях доросших до этих потребностей эти роли выполняют продакт и как раз дизайнер (или те люди что берут на себя эти обязанности), бизнес-анатилтик это вообще про другое и на другом языке
                              — Едиственные UX это исследователь и аналитик в моем понимании
                              — Продуктовые дизайнеры — как следует из названия как раз не про визуал, а про продукт от логики, взаимодействия и тд до визуала
                              — Если бизнес-аналитик сможет помимо роадмапа проекта и своей работы еще сделать например customer journey это плюс, но надо иметь немного другое мышление тк там больше логику проекта с точки зрения разработки имхо собрать

                              И вот почему я против проектировщиков
                              — если он делает прототип с экранами — то это пустая работа, тк в отрыве от визуала это недомакеты где все поменяется – и толку в этом?, изредка есть дизайнеры которые только за визуал (хотя очень редко и смысл в них) и даже тут тк один рисует серые условные грубые блоки — а второй расскрашивает их — то будет лажа (все эти серые прототипы максимум для обсуждения на первых митингах)
                              Если он делает высокого уровня — просто флоу — то это не проектировщик, а аналитик. По этому я исхожу из приносимой пользы — UX исследоветели и аналитики — это очень полезно хоть и дорого, а отдельный человек собирающий прототипы в отрыве от дизайна более чем сомнительня польза, хотя я знаю крупные компании с таким флоу(
                                0
                                Отчего же не передать роль проектирования интерфейса профильному специалисту? :) Разгрузить голову продакта, перестать заставлять дизайнера спецификации писать — все в плюсе, конечные пользователи при удобном продукте. В маленьком продукте, может, просто нет места для такого человека, в большом — полно
                                  0
                                  От того что нет таких специалистов)
                                  Рисовать серые блоки — это бесконечно далеко от финального дизайна и даже вредно (все имхо конечно). Более того как индустрия стремится чтобы Product (or UI/UX) Designers уходили и во фронтенд — мы тут говорим о некой более чем сомнительной компетенции, – как можно, проектировать страницу не учитывая графику, акценты и тд? Тут вопрос все чаще звучит что без реальных данных сложно проектировать страницу — а тут человек котрый серые блоки расскрашивает.
                                  Но самое страшное, что он порождает существование «дизайнера» который не думает, не погружен и без эмпатии и просто раскрашивает блоки?
                                  Продакт должен знать боль бизнеса и цели его и пользователей, дизайнер должен быть погружен от начала обсуждения до поддержки и багов в продукт. И это существут и есть в больших компаниях (по личному опыту)

                                  Мой поинт — UX не прототипы рисовать должен — а проводить аналитику, исследования, тесты и тд. И даже это все в тесном контакте с дизайнером на проекте
                                    0
                                    Тут интересно посмотреть, что «на входе» и «на выходе» у каждого специалиста. Кто-то должен сказать, каким требованиям бизнеса/пользователей/законодательства должен отвечать продукт, как выглядит процесс взаимодействия, какие данные должны попасть в интерфейс, как их представить, какими элементами обеспечить взаимодействие, как все это оформить. Дальше просто смотрим, какой объем продукта, сколько трудоемкость у каждой из этих задач. Помещаются ли они в голову одного человека? Если не помещаются, то кого нанять? Почему-то в современной реальности роль проектировщика взаимодействия выпала из рассмотрения, но задачи-то никуда не делись :) Проектировщиков не нанимают, а это значит, что соответствующие задачи не решаются или решаются непрофильными специалистами (то есть, в меру их навыков). Иногда везет, и эти специалисты решают их классно (я знаю пару продактов, которые в этом очень круты). Иногда решаются фигово. Вот мне и интересно — почему эту роль так задвинули? Ладно бы, ходили и жаловались, что специалистов не найти. Нет, просто задвинули, сфокусировавшись на визуальной стороне интерфейса
                                      0
                                      Вот мне и интересно — почему эту роль так задвинули?
                                      Задачи по корректировке поведения пользователей, по воронкам продаж, по микро- и макроконверсиям часто выполняют сеошники, как не удивительно.
                                        0
                                        Вот я и говорю — задачи никуда не делись, просто профильных специалистов на них не выделяют. И это еще хорошо, что в e-commerce есть сеошники, хоть они занимаются вопросом! На продуктовых проектах таких сеошников часто нет :)
                                        0
                                        Eще раз повторюсь — это делает дизайнер и сейчас нет такого в годных компаниях чтобы дизайнер только визуальную сторону делал, как минимум те что заню и где, я работал такого не видел тоже. Дизайнер начинает с момента постановки задачи (бизнесс, пользователи), делает дискавери, потом делает мокапы и их обсуждают, если надо дизайнер собирает прототип, после делает макеты, потом их внедряют, чистят и правят косяки, после дизайнер верифицирует верстку с qa, потом дизайнер сопровождает проделаную работу на ее жизненном цикле. Это то как я например работал, работаю и внедряю в компании куда прихожу. Тут просто нет места человеку рисующему прототипы в начале. Когда есть время — еще можно вставить в начале после прототипа и в конце после релиза — юзабилити тестирование. А вот возвращаясь к статье — редактор нужен на всех этапах и очень протно, чтобы не разойтись в понимании — но это конечно когда у комнании есть на это ресурс
                                          0
                                          Почему вы считаете, что проектировщик только рисует прототип, а не делает все перечисленное?
                                            0
                                            Потому что тогда он – дизайнер продукта)
                                              0
                                              А если он напишет на визитках «проектировщик», что-то изменится в его работе? :)
                                                0
                                                не принципиально, но того кто это делает называют дизайнером продукта или по старинке UI/UX. Нявряди этого ждут когда в CV проктировщик написанно
                                                  0
                                                  Любопытно, потому что в привычной мне картине мира все ровно наоборот :)
                                                    0
                                                    Очень вовремя мы с вами эту беседу затеяли! Спасибо огромное! :)

                                                    Как раз попросили помочь с переводом на русский текста, скорее, публицистического. Где слово «design» используется в полный рост :)
                                          0
                                          А на счет «серых блоков» — будем объективны, сейчас средний сайт или приложение для мобилки выглядит так, будто кто-то не сильно парясь нарисовал несколько синих или зеленых блоков, а потом скруглил углы. Так что, задача рисования серых блоков никуда не делась. По факту, именно на нее сейчас дизайнеров и нанимают! :)
                                            0
                                            не соглашусь)
                                            И абстракто накиданая форма — и реальная будут иметь разные фокусы внимания и акценты. Дизайнер может прийти к пониманию — разбиения информации из-за перегруженности например, или для усиления акцета — проетировщик в условной акшуре никогда не увидит этого или он должен быть дизайнером и предпологать сразу как тут будет.
                                            Я видел как годные прототипы от UX на дизайне становились лютой кашей, потому что ряд красивых легких серых блоков — товаров это совсем не то когда это фотографии с фоном и фирменным оформлением например
                                              0
                                              А зачем, по-вашему, кто-то берет в руки «условную акшуру»? Зачем этот шаг в проекте? Возможно, в вашей ситуации она и не нужна была, а ее зачем-то притащили? :)

                                              Axure — инструмент прототипирования, разработчики сами так пишут. Прототип в ней может быть условным, может быть с полным оформлением, как вам нужно. Вопрос только в том, зачем и как этот инструмент применить. Можно на условном прототипе тестировать навигацию с сложном каталоге, а можно финальный дизайн заказчику представлять :)

                                              Выбор подходящего процесса, инструментов и набора исполнителей — тоже элемент проектирования продукта :)
                                                0
                                                Ну мы же про роли) а так я знаю дизайнеров которые кодят и сразу результат покажут, да код не для продакшена но все же?) Тот же framer x — имхо то куда будет смещаться отрасль.
                                                К слову спор долгий и не сильно продуктивный, но можно взять топовые компании которые двигают индустрию и постмотеть какой у них флоу, есть ли чистые проектировщики.
                                                  0
                                                  Очень сильно зависит от отрасли.

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

                                                  Есть связь и транспорт, где «трендовое решение, все так делают» может помочь пользователю положить связь на половине континента или движение поездов остановить. Там, понятно, разговор другой и «дизайнеров с портфолио» гонят тряпками.

                                                  Есть устоявшиеся IT-компании, основанные инженерами, живущими ради инженерных решений — там плевали и на проектировщиков и на дизайнеров. Есть кто-то «из сферы UX», кодить не мешает, иконки в Интернете нашел — и хорошо :)

                                                  В общем, разные ситуации попадаются :)
                                                    0
                                                    я как раз не про веб, а про компании типо Яндекса
                        0
                        Гм… Я и не знал, что есть такая профессия — придумыватель надписи на кнопках и меню.
                          +1
                          Так вроде и нет её :)
                          +2
                          Уважаемый редактор. Поясните, пожалуйста, термин UX-редактор.
                          Я понимаю что от написанных текстов зависит пользовательский опыт… Но он зависит и от качества реализованного бекенда, не тупит ли сервис. Мы же не называем бекендера UX-бекендером. И от решений продакт менеджер тоже многое зависит, в том числе и пользовательский опыт. Он уже точно принимает решения которые влияют на него (например экономит ресурсы и выпиливает фичу из релиза). Но почему его не называют UX-продакт-менеджер?
                            0
                            А я с вами полностью согласна: на UX влияют все в компании — каждый разработчик, каждый менеджер, тестировщик, аналитик, саппортёр и так далее.

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

                            Так что приставку UX не отдам, она моя :)
                            0
                            А расскажите, насколько и как в начале работы учитываются пользовательские ожидания. Т.е. вы проводите какие-то исследования пользовательской активности или придумываете сценарии из головы?
                            0

                            А что бы вы предложили почитать на UX-тему помимо "Ководства" и "Бизнес-линча"? :)

                              0
                              Какие-то сечас суперстандартные варианты озвучу: «Не заставляйте меня думать», «Психбольница в руках пациентов» (ну, потому что они, может быть, не про конкретные инструменты, а скорее про общий принцип).

                              А про работу с текстом, конечно, Максим Ильяхов чертовски полезный (если без фанатизма). И мы вот сейчас парочку зарубежных книг ждём, они конкретно про UX-writing: Conversational Design (Erika Hall), The Content Strategy Toolkit (Meghan Casey). Анонсы звучали круто — посмотрим, что внутри :)
                              0
                              Всегда приятно увидеть и услышать профессионала в своем деле!

                              И просто мысли вслух по поводу UX:
                              «Подтвердить». Я как человек хочу сказать ей, что мне «Понятно».

                              Тут еще одна проблема есть, просто инерция. Если 90% таких же кнопок по всему интернету «Подтвердить», а в нашем проекте пусть и понятнее, но не так как везде — это порой сильно путает пользователя.
                                +2
                                Спасибо)

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

                                Если нам важно, чтобы человек на конкретном шаге обратил на что-то внимание — неожиданная «человеческая» кнопка может с этим помочь. Ну, и лучший вариант, на мой взгляд — прямо на кнопке обозначать целевое действие. Условно: не «Подтвердить», а «Да, удаляю карту». Как-то так :)
                                  0
                                  /** var DraftModel */
                                  private $draftModel;

                                  C текущим трендом на мобильное использование, писать полные предложения прямо на кнопке не всегда уместно. Но в целом все согласны, всегда лучше когда понятно написано, чем когда возможны интерпретации.
                                +1
                                Все же влияние микротекста сказывается :) Очень много коротких и\или перечисляющих что-либо предложений. Предложения-тезисы из одного слова, общая «раздробленная» структура (много мелких абзацев).

                                А как же сторителлинг? Неужели вся эта кропотливая, до кровавого пота, бесконечная возня с ссылками, проектами, кнопками и не бог весть чем еще все же убила внутреннего Льва Толстого?
                                  0
                                  Нет, не убила — у меня просто его и не было никогда.

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

                                  Вот абсолютно тупой пример: зачем в меню слева «Денежные переводы», а заходишь туда и там уже нужный мне интерфейс «Перевод денег». Почему сразу не написать «перевести деньги»? Ведь другой функции у интерфейса по этой ссылке нет.
                                    0
                                    Дайте-ка угадаю :) Наверное, этот комментарий не к блоку про техрешение, а к блоку про перевод с системного на человеческий. Потому что в блоке про техрешение ничего про угадывание нет.

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

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

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

                                        Мы не угадываем, мы предусматриваем максимум из возможного.
                                          +1
                                          Могу сейчас ошибиться: посмотрите статистику (карты кликов, тепловые карты, вебвизор) тех 20% которые генерят 80% прибыли я.денег. Чуйка подсказывает что там много чего можно сократить в customer jorney. Потому что я активный пользователь сервиса с пониманием темы UX и UX-копирайтинга в частности, и я даю вам фидбэк — все не очень хорошо. Ну или можете продолжать фокус-группы собирать.
                                    +4
                                    Спасибо за статью. Про копирайт и составление текстов мало пишут. А это действительно очень важная и трудная задача, которая сродни поэзии. В хорошем тексте ни добавить ни убавить нечего. А какие есть ёмкие слоганы! «Das Auto» одно чего стоит.

                                    Про «человечность» текстов, есть такой тренд тексты делать более неформальными, но иногда это в неподходящих местах доходит до неподобающей фамильярности — и вот тут нужно остановиться.
                                    Когда я вижу кнопку «понятно» — я прежде чем ее нажимаю думаю — «Блин, мне же на самом деле нихрена не понятно, я это соглашение мельком пролистал! Но не нажать на эту кнопку нельзя, иначе пользоваться приложением не смогу. Эх, ладно, *тыц*.» И вроде бы всё, закончились мучения мысли, но какой-то осадок остается. Тут лучше бы подошло честное «продолжить». Да, тексты должны быть в первую очередь честными.

                                    Или при завершение, скажем, туториала какого-нибудь — «Ну, поехали!». Даже если это игра — слишком фамильярно. Пользователь должен ощущать себя абсолютным повелителем приложения. Компьютер — молчаливый раб. И нельзя ни на секунду заставить пользоваться усомниться в этой власти. Если тексты сформулированы на несерьезном языке, то и о приложении и компании создается такое-же впечатление. И это мы еще толком не познакомились.
                                      +1
                                      Полностью с вами согласна: тексты прежде всего должны быть честными. Поэтому мы не используем «Понятно» для акцепта длинных юридических условий.

                                      Я стараюсь всегда напоминать себе, что восприятие текста чертовски субъективно. Если что-то нравится (или не нравится) мне, это ещё ничего не значит. Поэтому в первую очередь мы решаем информационную задачу: самое главное, чтобы всё было понятно. А вот дальше на это «понятно» можно накинуть (или не накинуть) что-то эмоционально окрашенное. С осторожностью :)
                                      0
                                      Все так красиво написано)))

                                      Только вчера я скачал яндекс-музыку. Сначала появляется окно: «Новый юзер?/Уже зарегистрированы?»->нажимаешь «Новый юзер»->появляется здоровый инпут: «Введите номер телефона»->вводишь номер телефона->он пишет «номер не зарегистрирован!». А с чего бы ему зареганным быть, если я новый юзер?))

                                      У меня вопрос в девушке: WHY? WHY? WHY?
                                        0

                                        Спасибо, адресую это тройное why коллегам, которые пишут для Яндекс.Музыки.

                                        0
                                        Очень классная статья!
                                        Прям все так в точку, так откликается))
                                        Работаю UX дизайнером (мы это называем так) в Минске, но в обязанности входит как раз все вышеперечисленное) И действительно, многим со стороны не понять весь объем и разносторонность процесса разработки)
                                          0
                                          Если бы вы знали, как редко нас понимают правильно, вы бы чаще молчали.
                                          (Иоганн Вольфганг фон Гёте)

                                          Если бы ты видел, из какого источника текут людские суждения и интересы, то перестал бы добиваться одобрения и похвалы людей.
                                          (Марк Аврелий)

                                          Исходя из выше сказанного, всем не угодишь, а следовательно и не надо. Всегда будут не довольные или им что-то будет не по нраву. На программистов, вообще, не стоит ориентироваться в принятии решения, где кнопка должна располагаться и что на ней должно быть написано.))) У них свой мир в голове. Лучше руководствоваться здравым смыслом и делать свою работу хорошо. И вообще, я считаю очень нужная работа, но почему-то никем не ценится, особенно программистами.
                                            +1
                                            Спасибо за статью, работаю ux-дизайнером. И чаще всего мне приходится пинать PM и аналитиков, чтобы сделали короткие конкретные тексты. Но не задумывался о том, что надо чаще говорить в интерфейсе на языке пользователя. Буду применять)

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое