Pull to refresh

Comments 64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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