СМОТРИТЕ ЛЁХА В ТЕЛЕВИЗОРЕ: сегодня в 15:55 я буду выступать на Globus Partners Day (с бесплатной прямой трансляцией!) и расскажу про продуктовый дизайн, почему агентства делают говно и всякое-такое-прочее. Трансляция тут: https://www.facebook.com/tagline.digital/videos/792360464468583 (ищите меня на 34 минуте)

Доклад для широкой аудитории, так что не ждите УЗКОПРОФИЛЬНОЙ ГЛУБИНЫ, там, БРЫЗГОВ UX-ГУРУИЗМА или чего-то подобного, но общее представление о вопросе оно точно создаст.

Приходите и слушайте, а я буду чувствовать вашу моральную поддержку и раскрываться так, как никакой Алле Борисовне на концертах не снилось.

P.S. Вообще состав спикеров на Globus Partners Day весьма годный и там есть кого послушать (https://globus-event-org.timepad.ru/event/899454/), но поскольку мне за это никто не платит, я превращусь в эгоистичную жопу и про это вам не скажу - типа, смотрите, какой я классный, а больше никого и нету.

#концертыстасамихайлова

Хочу вам рассказать по-быстрому про штуку, которую многие или не знают, или постоянно забывают. Штука называется HADI, а значит она следующее: Хрен - Американцам, Дизайн - Индейцам.

Не, шучу, расшифровывается HADI как Hypothesis - Action - Data - Interpretation (гипотеза - действие - данные - интерпретацыя), а применяется так:

1. Вы делаете себе татуировку на пальцы левой руки с соответствующими буковками: на мизинец, значится, H, на безымянный A, на средний D, ну и так далее. Теперь вы как продуктовый авторитет, выходит.

2. Перед тем, как сесть за какую-нибудь продуктовую или интерфейсную штуку, смотрите на мизинец левого кулака и думаете «АГА ГИПОТЕЗА». И понимаете: прежде чем начать что-то делать, вам нужно сформулировать гипотезу, нафига вы это делаете. Пишете, там, «Мы верим на основании своего UX-гуруизма, что в дождливую погоду пользователи готовы покупать круассаны по ценам в 100 раз выше, и проверим это, показав фичу продажи круассанов в дождь тыще пользователей в ходе A/B тестирования. Мы будем правы, если треть пользователей экспериментальной группы купит круассанов больше, чем в контрольной группе». Пока хватит (запомните, кстати, такую манеру постановки гипотез - пригодится)

3. Смотрите снова на левый кулак и думаете «АГА ДЕЙСТВИЕ». И понимаете: вам нужно понять, как именно вы будете проверять гипотезу и проворачивать эксперимент с круассанной фичей, а также как и куда собирать данные. Продумываете план действий, его реализуете, запускаете эксперимент.

4. Глядите на вашего нового верного друга - левый кулак - и думаете «АГА ТЕПЕРЬ ДАННЫЕ». Это значит, что теперь вы должны собрать результаты проверки гипотезы воедино. Если не налажали на шаге 3 и все спланировали верно, это уже чисто технический шаг, требующий лишь времени.

5. Вызываете свой левый кулак еще раз. Читаете, глядя на него, с выражением: «АГА ИНТЕРПРЕТАЦИЯ». Теперь вы должны сделать самое сложное - выудить из полученных данных здравый смысл и примерить его на гипотезу. Для этого вы должны не налажать на предыдущих шагах и сделать правильные выводы, не выдавая желаемое за действительное.

6. Теперь вы понимаете, что ваша круассанная гипотеза провалилась или выжила. Причем вы должны быть рады обоим результатам - гипотезы любят не безошибочных, гипотезы любят быстрых и смелых. Выдыхаете. Кулак далеко только не убирайте - у вас должно появиться много новых классных гипотез, с которыми нужно будет работать. Видите, как хорошо быть продуктовым авторитетом?

И вот в идеале вы так и должны, как в стиральной машине, жить циклами гипотез - поставили гипотезу (самый нудный, но важный этап), проверили ее в действии (это самый нажористый этап в плане телодвижений), собрали данные, проинтерпретировали их (это самый хрупкий мозголомный этап), и дальше на новый круг.

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

#продукт

После конференций ко мне часто подваливают люди перетереть за продукты, процессы и все такое. Я очень люблю подобные моменты, потому что именно тогда люди спрашивают действительно интересные вещи. «ЛЁХ НО ЕСТЬ ЖЕ ВОПРОСЫ ИЗ ЗАЛА ПОСЛЕ ДОКЛАДА» - спросите вы. Да, есть, но, к сожалению, самые важные вопросы люди из зала не спрашивают - потому что эти вопросы, как им кажется, выглядят глупо (о, этот страх выглядеть глупо!). Поэтому я люблю общаться лично - именно тогда я понимаю, что действительно волнует и затрагивает людей.

И вот на одной из последних конференций ко мне подвалил чувак с очень простым вопросом: «А КАК ВЫ ВООБЩЕ ИССЛЕДУЕТЕ ПОЛЬЗОВАТЕЛЕЙ». Как выяснилось дальше, под этим вопросом (боясь выглядеть глупо) он скрывал следующее: «Мы понимаем, что пользовательские исследования нужны и важны, слышим про уикс-хуикс из каждой колонки, но, блин, с чего начать-то?»

Этот вопрос меня самого мучал очень долгое время. Мы все читаем от какого-нибудь там Юзабилитилаба про пользовательские исследования, про эти адские методологические процессы, занимающие месяцы, про репрезентативность выборки, количественные и качественные исследования, про ай-трекинг, юзабилити-лаборатории и прочий матстат, и потому процесс UX-исследований порой кажется каким-то таинственным ритуальным процессом, в котором простой смертный без корочки психфака (или хотя бы мехмата) не разберется НИКОГДА ВОВЕКИ ВЕКОВ ЗАКЛИНАЮ ВАС ИМЕНЕМ UX ГУРУ.

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

Первым делом я решил разделить все наши исследования на два направления. Первое направление я назвал хардкорным - и туда я отнес все тяжеловесные (я бы сказал еще, ВЫСОКОНАУЧНЫЕ) исследования, про которые вы читаете в статьях от UX-старцев, слышите на конференциях и так далее. Эти исследования дают много глубокой инфы, но взамен требуют соблюдения методологии и кучи ритуальных телодвижений, требуют много времени и планируются сильно заранее, потому что каждое исследование - это дорогой и довольно сложный аналитический праздник. Поскольку моих людей на научные штудии пока точно не хватает, под исследование приглашается внешняя исследовательская контора.

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

Выглядит это примерно так:
1. У нас появляется хорошая тема для разговора с живыми пользователями (например, новая фича, или идея фичи, или набросок наброска наброска идеи фичи).
2. Мы обращаемся в специальную контору, которая поставляет живых пользователей под наши требования. Берет она за это сравнительно небольшие деньги - на уровне нескольких тысяч рублей за человека. С конторой у нас заключена рамка, так что этот этап проходится быстро.
3. Через несколько дней к нам приходит живой человек. Он наш на целый час. За этот час мы можем показать ему наши наработки, провести через какой-то пользовательский сценарий, задать вопросы, провести карточную сортировку, чего угодно. Попутно у команды появляется крутая возможность увидеть живого пользователя и его взаимодействие с продуктом.
4. Мы заносим полученные ценные мысли в наши скрижали, разбираем итоги, живем дальше поумневшие.

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

«ДА НУ ЭТО ВСЕ ДЕТСКИЙ САД ГДЕ ВАША РЕПРЕЗЕНТАТИВНОСТЬ» - сморщит нос иной UX-дед, но я отвечу на это так. Да, мы осознаем, что мы жертвуем точностью и глубиной исследований - но взамен получаем возможность быстро проверить наши шальные идеи, а также не думать только содержимым своей черепной коробки. Это всяко лучше, чем вообще ни с кем не разговаривать - и уже поэтому подобный метод «в штыковую» очень ценный.

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

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

И очень просто в организации.

#изкрестьянскогобыта

Целевая аудитория - интересная штука. Мой друг, назовем его кодовым словом ВИТАЛЯ, рассказал мне давеча вот какую историю. Как-то к нему в контору пришли клиенты из крупного телекома, которые хотели сделать себе какую-то фиготу типа лэндинга или промосайта, при помощи которого они хотели рекламировать симкарту. Симкарта отличалась тем, что была вся из себя мобильная, быстро оформляемая, с гибкими условиями и так далее.

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

Чтобы не рисовать пользовательские сценарии со слов клиента, ВИТАЛЯ с коллегами решили провести полевое исследование и прощупать ЦА поглубже. Ко всеобщему восторгу исследование показало, что практически все пользователи новой суперсимкарты - это гости из солнечной Азии, которые прибывают в крупные города на заработки, а потому ценят все гибкое, быстро оформляемое и так далее.

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

#изкрестьянскогобыта

P.S. Особо занудные читатели начнут возбухать на ночь глядя «НУ И ЧТО МОЖЕТ ОНИ ХОТЕЛИ ХИПСТЕРАМ ЕЕ НАЧАТЬ ПРОДАВАТЬ КРОМЕ ТАДЖИКОВ», в ответ на что я скажу так: они про Таджикистан и солнечную Азию даже не подозревали. Так что спите спокойно.

Недавно я наткнулся на одну мелкую и ядовитую историю, которая сподвигла меня встать на фоне заката, запустить руку в бороду и рассказать вам про CJM - Customer Journey Map. Если вы знаете про CJM, мотайте ленту вниз - в следующем посте я как раз исхожу злобой по поводу этой истории, - а тут я хочу разъяснить азы советской власти.

CJM, вообще говоря, предназначен для решения следующей проблемы: у нас есть пользователь со своими задачами и болью, у нас есть разрабатываемый продукт со всеми функциональными пирогами, так как же они будут взазимодействовать между собой, спрашивается? Как же нам избежать известной жопы, когда вроде и продукт ок, и пользователь ок, а между собой они не дружат? Как заставить агнца возлечь возле льва?

Про CJM принято думать, что это что-то АДСКИ СЛОЖНОЕ и вообще МАТАН, в доказательство чего все тыкают в статьи разных экспертов с дубовыми схемами, формулами и грандиозными диаграммами.

А я вам говорю, что никакого матана в CJM нет. Щас расскажу. Берем и делаем вот что:

1. Садимся, берем реального и гипотетического пользователя, понимаем, какую задачу он хочет решить (или какой цели достичь), в каком контексте и с какими дополнительными обстоятельствами. Этот пункт удобно проворачивать при помощи метода персонажей, но я про него в другой раз расскажу.
2. Расписываем квадратиками в ряд: для достижения своей цели пользователь делает вот это, потом вот это, потом вон то - а потом вон то.
3. Смотрим внимательно на квадратики и думаем: а чем наш продукт сможет помочь пользователю на каждом шаге? И пишем чуть ниже напротив каждого квадратика: вот здесь продукт будет делать все за пользователя, вот тут пользователю будет предложен выбор, здесь ему будет приходить пуш-уведомление - и так далее.
4. Любуемся теперь уже двумя наборами квадратиков, идущих рядом - и вслед за этим начинаем думать: а какие терки могут возникать между пользователем и продуктом на каждом шаге? Например, вот здесь пользователь должен будет выбрать из 20 очень похожих вариантов; это нехорошо. Здесь пользователь должен будет не пропустить пуш-уведомление, иначе он ничего не сможет сделать дальше; это тоже не очень гут. Аккуратно расписываем все эти терки напротив каждого квадрата.

И… всё. Не, серьезно, всё. У вас уже готов минималистичный CJM, который позволяет понять, как действует пользователь, как ему помогает продукт - и какие помехи и проблемы возникают в процессе.

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

Еще - по ситуации - можно расписывать CJM более глубоко и подробно, например:
- Для каждого шага описывать мысли и эмоции пользователя;
- Для каждого шага описывать, с какими интерфейсными блоками, страницами или экранами пользователь будет взаимодействовать
- Расписывать, какие интеграции с внешними системами нам понадобятся для осуществления каждого шага;
- Указывать взаимосвязь с бизнес-процессами, завязанными на пользовательский сценарий (например, пользователь покупает товар - а вот тут мы активируем бизнес-процесс заказа внутри организации);
- Раскидывать CJM на несколько каналов (соцсети, приложение и т.п.) и смотреть, как пользователь переходит из одного места в другое;
- На основе CJM рисовать конверсионную воронку - то есть указывать для каждого этапа метрики и KPI, которыми мы будем мерять эффективность прохождения пользователем сценария.

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

Так что не бойтесь и пробуйте.

#вашидокументы

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

И в ответ слышите: «ЭТА ПРОБЛЕМА НЕ ЛОЖИТСЯ В НАШ КАСТОМЕР ДЖОРНИ ИНАЧЕ МЫ БУДЕМ ТЕРЯТЬ ДЕНЬГИ ДАВАЙТЕ ЕЕ РАССМАТРИВАТЬ НЕ БУДЕМ»

И вот эта фраза жирно мерзотная, бойтесь ее. Люди, которые говорят ее, расписываются в том, что:

- Они изначально не включают в свой КАСТОМЕР ДЖОРНИ реальные пользовательские проблемы и действия - туда они включают желаемые действия идеального пользователя, существующего только у них в головах. НАШ, сука, КАСТОМЕР ДЖОРНИ, подумать только;
- Они не готовы менять свой КАСТОМЕР ДЖОРНИ - или потому, что влюбились в своих вымышленных пользователей, или потому, что реальный КАСТОМЕР ДЖОРНИ расшатывает их бизнес-схему и показывает ее людоедский нрав, который, например, приведет к падению лояльности. Если реальные данные и проблемы противоречат их священному КАСТОМЕР ДЖОРНИ, рассуждают они, тем хуже для данных.

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

#изкрестьянскогобыта

Я вам тут обещал, что не буду кидаться в вас простыми ссылками на статьи, но тут даже и не знаю, что делать: вышла статья-конспект по моему выступлению на последнем UX-марафоне, где я рассказывал про работу с текстами в интерфейсе: https://clck.ru/Fha5h

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

Но я хитро выкрутился, прямо по заповеди Льва Николаевича Толстого: вот, написал вам текст про то, как не могу написать текст.

(на самом деле у меня есть важная телега в дополнение к моей статье, но я прогоню ее вам чуть позже)

Обещанная телега моя будет вот о чем.

Часто под «проработкой UX» подразумевают что-то предельно конкретное: например, отрисовку интерфейса. Или, там, придумывание хорошо работающей фичи. Или, там, написание хорошего текста.

С одной стороны, это, конечно, хорошо и правильно (я бы даже сказал, ЛЮБО, если бы был казаком-кибердружинником - недавно узнал про существование таких) - действительно, на UX напрямую влияют и интерфейсы, и хорошо работающие фичи, и интересные тексты, но фишка в том, что влияют они не порознь, а все вместе. И строиться они должны все вместе, параллельно.

Непонимание этой простой, казалось бы, мысли приводит к парадоксальным ситуациям: позвали классного UX-гуру, нарисовали офигенные картинки, а реализовано это настолько через жопу, что загружается по миллиону лет. UX отвратительный. Или: придумали восхитительную фичу, которая интегрирует все на свете и снимает всю боль пользователя разом, но интерфейс к ней прикручен настолько дубовый, что пользователь даже не понимает, что с этим делать. UX отвратительный. Ну или вообще классика: написали ОФИГЕННЫЕ ТЕКСТЫ, а сайт под это сделали отвратительный, с помидорами на заднем фоне и который не открывается. Приплыли. UX сами-знаете-какой.

Когда я вышел в банк и начал собирать свою команду, многие меня называли «А ЭТО ТОТ БОРОДАЧ КОТОРЫЙ UX ЗАНИМАЕТСЯ». Сперва я бесился: как так, я же занимаюсь и построением бэк-систем, и над архитектурой продукта думаю, и над интеграциями, у меня и команда разработки, и дизайна, и пятое-десятое, - а потом беситься резко перестал, потому что осознал, что они правы, и я вправду занимаюсь UX, только в самом глубоком понимании этого слова - т.е. по всем направлениям сразу: чтобы это хорошо воспринималось с визуальной точки зрения, гладко и быстро работало, располагало всеми возможными полезными функциями - и оседало в голове у пользователя не бесформенной кучей впечатлений, но ладно скроенной UX-поленницей представлений. Потому что UX - пользовательский опыт - формируется всем сразу, и все важно, и все нужно.

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

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

#продукт

Иногда в продуктовой разработке возникает вот какая херь. Вот, допустим, есть у нас Product Owner, т.е. дядька при галстуке, который топит за бизнес, денежные показатели продукта, приоритезацию задач и все такое важное. У него в команде, помимо прочего, есть какой-то UX-специалист, который призван топить за пользователей, юзабилити и прочую психологию.

Все идет хорошо, пока бизнесовая коса не находит на камень UX: в какой-то момент Product Owner может закатить скандал, что ЧЕГО ВЫ ТУТ УСТРОИЛИ КНОПКУ ЗАКРЫТИЯ КРЕДИТА ВЫВЕСИЛИ НА ПОНЯТНОЕ МЕСТО ЭТО ЖЕ ВСЕ КРЕДИТ ЗАКРОЮТ И МЫ ДЕНЬГИ ПОТЕРЯЕМ ПУСТЬ ЛУЧШЕ ЖИВУТ С КРЕДИТОМ И НЕ ЗНАЮТ.

Сама по себе эта ситуация абсолютно рабочая и не страшная: продакт овнер на то и продакт овнер, чтобы топить за бабки и бизнес. Но проблема в том, что часто в ответ на такой загон от продакт овнера поднимается только робкая рука UX-специалиста, который робко блеет на своем психологическом языке: а как же юзабилити, а как же лояльность, мы же тут ратуем за удобство, за то, чтобы… ХУЕЗАБИЛИТИ И ХУЕДОБСТВО, - отвечает тактично продакт овнер, - Я ТУТ ПРО БАБКИ А ТЫ МНЕ ВТИРАЕШЬ КАКУЮ ТО ДИЧЬ ПШЕЛ ВОН КЫШ КЫШ.

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

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

Как же быть в таком случае? Глобально путей решения три.

1. Сделать так, чтобы у продакт овнера в метриках и KPI были не только бизнесовые показатели вроде какой-то конверсии, но и показатели, которые отражают степень лояльности пользователей к продукту - условно назовем это басурманским словом User Engagement. Тогда продакт овнер вынужден будет балансировать между тактикой ПРОДАЕМ ПРОДАЕМ ПРОДАЕМ и необходимостью поддерживать нормальный UX и не забывать, вообще-то, про нужды пользователя и заботу о долгосрочных отношениях с ним.

Способ неплохой, но у него есть два изъяна: если продакт овнеров на одно приложение будет много, то единую метрику по Engagement на них не накинешь - на нее будет влиять слишком много факторов со всех сторон; важно еще и следующее - есть риск, что продакт овнер всегда будет топить за свое бабло, а про более сложные в работе показатели будет забывать или забивать.

Тогда есть второе решение:

2. Завести отдельную команду, которая будет топить за этот самый Engagement и молиться на лояльность пользователей к продукту. Тогда выйдет неплохой продуктивный производственный конфликт - одна команда будет топить за, допустим, продажи, а вторая - за то, чтобы продукт при этом не гикнулся; тогда при правильном подходе и отношениях в команде между ними установится компромисс, а еще лучше - ситуация win-win, когда и овцы сыты, и волки целы.

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

Наконец, есть еще и третье решение:

3. Забить и ничего не делать, потому что надо срубить деньги сейчас, а пользователь не мамонт, не вымрет. И, как ни страшно это прозвучит для UX-уха, для некоторых продуктов это вполне нормальная и работающая схема действий. Бабки идут, затраты отбиваются - чего еще надо?

От так-то.

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

#изкрестьянскогобыта

Ой, какую байку-балалайку сейчас расскажу. С пылу - с жару, прямо из 2012 года. Слушайте сюда про конференцию User Experience Russia и Сергея Рыжикова, главу 1С-Битрикс.

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

Действующие лица у нас следующие: Сергей Рыжиков - грамотный разработчик, прекрасный управленец и просто хороший человек, который возглавляет 1С-Битрикс, которая делает одноименную систему управления сайтами (ну, вы знаете). В эпоху далекого 2012 года Битрикс славился в народе мощной и при этом зубодробительно сисадминской админкой, которая стерла в пыль мозги не одному поколению юных и нежных контент-редакторов.

User Experience Russia - это конференция, которую всегда делает Юзабилитилаб (не помню, то ли права у них на нее, то ли моральная традиция, то ли еще что). Юзабилитилаб, в свою очередь, славится утонченными UX-аналитиками, которые по своей натуре чаще всего психологи, двигают за науку и представляют собой в рамках данной байки аналог толкиеновских эльфов.

И вот на UX Russia 2012 эти две галактики впервые в истории встретились! Рыжиков приехал выступать на конференцию юзабилистов с докладом с характерным и интригующим названием: «Разработка интерфейсов сложных систем: секси, няшно, мимими» . До этого Рыжиков и UXеры в одном помещении замечены не были, а потому на его доклад собралась бешеная куча народа, которая приготовилась внимать, по каким же именно UX-законам работает компания 1С-Битрикс, гроза вчерашних школьников и начинающих звезд веб-разработки.

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

«Генеральный директор 1С-Битрикс Сергей Рыжиков выступил с темой «Разработка интерфейсов сложных систем: секси, няшно, мимими». За этим интригующим названием скрывался кейс эволюции корпоративного портала Битрикс24.

Сергей предложил очень простую схему работы над продуктом, которая, конечно же, вызвала недоумение у большинства слушателей. Он рассказал, что просто показывает прототипы продукта своим знакомым, и просит их рассказать о своих впечатлениях и ассоциациях. Грубо говоря, все делается по принципу нравится/не нравится. Такой подход Сергей выбрал, в том числе и потому, что продукты Битрикса насчитывают порой более 300 страниц интерфейса, и даже крупные российские юзабилити компании не готовы были за них взяться.»

По факту же на конференции, по словам ее же участников, происходило вот что.

К жадно взирающей аудитории вышел Рыжиков, который ярко, смачно и харизматично высказал примерно следующее: ДА ЗАЧЕМ ЭТО ВАШЕ УЧЕНОЕ ЮЗАБИЛИТИ МЫ ДЕЛАЕМ ТАК ЧТОБЫ НАШИМ РАЗРАБОТЧИКАМ НРАВИЛОСЬ И НА НИХ ОРИЕНТИРУЕМСЯ А С ВАМИ МЫ ПРОБОВАЛИ РАБОТАТЬ КАКАЯ ТО ФИГНЯ СПЛОШНАЯ ВЫХОДИТ СПАСИБО ДО СВИДАНИЯ.

После чего Рыжиков поклонился и покинул сцену в гробовом молчании. Говорят, зарево от горящих надежд UX-аналитиков было видно из Бухары.

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

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

#изкрестьянскогобыта
#отвечаеталександрдрузь

Внимание, вопрос: по-вашему, кто прав, а кто - лев?
anonymous poll

Все львы – 92
👍👍👍👍👍👍👍 53%

UX Russia - прав, Рыжиков лев – 50
👍👍👍👍 29%

Все правы – 20
👍👍 12%

Рыжиков прав, UX Russia - лев – 11
👍 6%

👥 173 people voted so far.

Рекламы в моем канале нет и пока что не будет - разве что придет денежный мешок и будет башлять мне какие-то дикие многозначные суммы, за которые мне не жалко будет писать что-то про ВЕСЕЛЫЙ АНБОКСИНГ ПЫЛЕСОСОВ или, там, ПОРОШОК ДЛЯ ЮИКС ПОХУДАНИЯ, но это я вам еще отдельно тогда сообщу.

Но чтобы вы не расслаблялись слишком, я буду делать вид, что рекламирую сам себя и буду иногда публиковать ссылки на собственные видео и выступления. Бесплатные, само собой.

Не далее как сегодня я выступил на одной сцене с Андреем Себрантом (это директор по стратегическому маркетингу Яндекса и мощнейший спец по технологиям и инновациям) и Алексеем Шульгиным (так же мощно, как Себрант, но по художественной части). Мы тепло и лампово поговорили о взаимодействии человека и машины с точки зрения искусства, науки, технологий и разных прикладных историй про интерфейсы, и я до сих пор в себя прихожу, сижу и выдыхаю, до того было круто.

В общем, теперь про то, куда идти и что смотреть. Вот ссылка на видос: https://www.facebook.com/rosbank/videos/856808824666621

Вот тайминги, если интересует кто-то конкретный:

Андрей Себрант - 7:50
Я - 30:45
Алексей Шульгин - 58:50
Интересные обсуждения - 1:24:00

#концертыстасамихайлова

Но вернемся в моему позапрошлому посту про магическую войну между UX-эльфами и Сергеем Рыжиковым.

Как вы помните, мы провели голосование, где победила точка зрения, что в этой истории все оказались львами: и Рыжиков - за то, что пренебрегает юзабилити-канонами, и UX Russia - потому что припечатали Сергия печатью игнора, хотя - казалось бы.

- ЛЁХА А ЛЁХА, - спросите вежливо вы, - А САМ ТО ТЫ ЧО ДУМАЕШЬ? И тут я мастерски запахиваюсь в раввинский халат и отвечаю вам так: правы все и неправы все.

Чему нас учит эта показательная история?

(Эта, предупреждаю: если вы настроены прочесть сейчас что-то легкое и про смешные интерфейсы - дождитесь завтрашнего дня, у нас там в рубрику БИСКВИТНЫЙ ДВОР новый пациент приедет, а пока пойдите спать, утро вечера мудренее, этот пост с утра под чаёк с печеньем прочтете, он никуда не денется, заодно и проснетесь)

1. Действительно, можно положить прибор на всю эту чехарду с методологиями, заветами юзабилити-старцев, талмудами от UX-ученых и прочим фарисейством - и сделать при этом успешный продукт. История знает много примеров, когда создатель продукта чихал с высокой колокольни на всю дизайн-возню, делал все по-своему в соответствии со своими представлениями о мире, целевой аудитории и своей миссии - и переворачивал мир. Такой сценарий я называю Стальные Яйца Продуктолога, хотя, по правде сказать, не в яйцах тут дело: просто глава продукта в этом случае проворачивает у себя в голове все те же процессы и дела, которые мы совершаем при помощи бесконечных методологий и процессов, только делает это быстрее, гибче и мудрее.

Какие при этом есть риски?

- Вы не окажетесь гением создания продуктов, а только возомните себя таким;
- Все окружающие будут ныть про то, что, дескать, вы слишком быстро действуете, не соблюдаете Тридцать Три Приседания UX-Специалиста (или как там ваша методология зовется) и вообще у вас ничего не выйдет (и тут-то стальные яйца вам и вправду пригодятся);
- В какой-то момент вы можете загнаться или психануть и сотворить с продуктом что-то лишнее - и вас ничего не сможет остановить;
- Без внятной методологии вам сложно будет собрать несколько команд и делегировать на них массовую продуктовую работу - начнется триллер «Лебедь, рак и щука».

2. Вторым уроком этой истории является то, что UX-методологии-инструменты-книги-и-все-такое - штука безусловно полезная, но для продукта небезопасная.

С одной стороны, она позволяет видеть перед собой ориентир, двигаться планомерно в своем продукте - и не быть при этом гением от мира UX (и не держать вокруг таких же гениев). Это путь, который я не придумал, как его назвать - назовем это Дао UX-улитки на Склоне Фудзиямы.

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

Помните, что любая (не шучу) методология - это мертвая, зафиксированная, законсервированная в каком-то моменте мысль ее авторов. Она не должна и не может быть ответом на все вопросы, она представляет собой закостенелый слепок некогда живых мыслей и концепций, который важен и полезен в обучении и развитии, но опасен как подмена своей мысли, своей гибкости, своего пути, - все это может быть забито фразами от окружающих вида «А У КОГО ТЫ ЭТО ВЫЧИТАЛ?», «А В КАКОЙ КОМПАНИИ ЭТО ИСПОЛЬЗУЮТ?», «А ТЫ ХОТЯ БЫ ОДИН ПРОДУКТ ВИДЕЛ, СДЕЛАННЫЙ ПО ЭТОЙ СХЕМЕ?». Это плохие, дурные вопросы, которые в своей основе имеют подтекст «НИЧЕГО НОВОГО ТЫ СДЕЛАТЬ НЕ СМОЖЕШЬ НИ ЧТО НЕ НОВО ПОД ЛУНОЮ», хотя по факту каждый продукт уникален, а окружающие его обстоятельства - кошмарно индивидуальны.

Все ново под луною, а вот трусость - вечна.

3. Мастерство хорошего проектировщика, продуктолога или дизайнера продуктов заключается в том, что он знает все актуальные методологии, но при этом по факту живет по своей схеме, которая может быть отчасти похожа на что-то существующее, но при этом она будет гибко и осознанно подстроена под конкретно его обстоятельства. И главными вопросами, на которые такой проектировщик или продуктолог должен уметь ответить - это не гнилой запрос цитат знаменитых UX-дедов, но «А ПОЧЕМУ ТЫ ДЕЙСТВУЕШЬ ВОТ ТАК?», «ЧТО ЭТО ДАСТ ПРОДУКТУ?» и «КАК ТЫ БУДЕШЬ МЕНЯТЬСЯ, ЕСЛИ ТВОЯ МЕТОДОЛОГИЯ НЕ СРАБОТАЕТ?». Вот это - гибкость, это - индивидуальность, это - мастерство.

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

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

Так что любите даже своих врагов - они, как и ошибки, учат нас очень многому.

#изкрестьянскогобыта

Куда же мы да без вкусной рубрики БИСКВИТНЫЙ ДВОР! Заносите пациента!

За сегодняшний подгон и интерфейсную смелость поблагодарим Риту Комиссарову!

Пациентом вы можете насладиться в фотокарточке чуть выше по течению. На серые квадраты не обращайте внимания - это я замазал пару полей исходного скриншота во имя ПОЛИТИКИ КОНФИДЕНЦИАЛЬНОСТИ, а то Маргарита барышня видная, вдруг будете к ней ломиться в личку за каким-нибудь непотребством или, там, шубы из поддельного песца ей продавать.

Что же мы там видим? А видим мы обычные поля для заполнения и хрень космическую на месте выбора пола. Так и вижу, как дизайнер, поводя жвалами, рассуждал на своем клингонском «АЧАЧАЧАЧА ЧЕЛОВЕК БУДЕТ ВЫБИРАТЬ ПОЛ АЧАЧАЧАЧА ЗАЧЕМ ДЕЛАТЬ ВЫБОР В ДВЕ СТРОКИ ЛУЧШЕ СДЕЛАЮ В ТРИ СТРОКИ АЧАЧАЧАЧА И ЕЩЕ ЧТОБЫ ПОЛЬЗОВАТЕЛЬ МОЗГ ПОЛОМАЛ В ПРОЦЕССЕ АЧАЧАЧАЧА», - после чего нарисовал вот это непотребство, расправил ложные крылья и с улюлюканием убежал в ночь.

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

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

И вот это, казалось бы, простое правило тут сломано напрочь. Взгляд пользователя, убаюканный заглавным текстом и стандартнейшими полями ввода, безмятежно скользит сверху вниз и внезапно натыкается на безумное домино, где управляющие элементы (вот эти вот пупышки для выбора пола) находится на одном уровне, а подписи к ним - находятся сверху и снизу. Еще 5 минут назад пользователь был убаюкан горизонтальным распределением информации (1 строка = одна единица вводимой информации) и двигался через интерфейс, как шампур - через шашлык, а сейчас натыкается на форменный кавардак, ритмика работы с интерфейсом ломается, пользователь просыпается и думает, к примеру, «А ЧТО Я ТУТ ВООБЩЕ ЗАБЫЛ?».

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

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

Как все это можно исправить?

1. Не использовать такой интерфейсный дебилизм без видимой надобности.
2. Если ОЧЕНЬ уж хочется поиграться в пост-модерн, то нужно, во-первых, переводить все остальные поля ввода в горизонталь (например, разместить все элементы в ряд и сделать горизонтальный скролл, хотя это будет выглядеть все равно дико), а во-вторых - обеспечить четкую визуальную привязку надписей к управляющим элементам, чтобы не пришлось возиться с анкетой методом тыка и допускать ошибки.

Ведь выбор пола - дело такое, один раз ошибешься, потом пацаны во дворе засмеют.

#бисквитныйдвор #отвечаеталександрдрузь

P.S. Да знаю я, знаю, что у клингонов нету жвал и крыльев. Не занудствуйте.

P.P.S. Если у вас есть хорошие экспонаты в нашу кунсткамеру - скидывайте мне в личку смело. Родина вас не забудет.

Ну чо, как вам такое интерфейсное решение?
anonymous poll

Такое не прощается. СЖЕЧЬ ИНТЕРФЕЙСНУЮ ВЕДЬМУ! – 70
👍👍👍👍👍👍👍 56%

ПОЧЕМУ ТУТ БИНАРНЫЙ ГЕНДЕР ГДЕ МОИ АНДРОГИНЫ И ИНТЕРСЕКСЫ – 33
👍👍👍 27%

Дяденьки, вы ошиблись, я не дизайнер, я только планшет нашел – 13
👍 10%

Да лан, мне норм. – 8
👍 6%

👥 124 people voted so far.

Интересный комментарий пришел в нашу дорогую редакцию от дорогого читателя Антона Нестерова. По его мнению, учиненный выше БИСКВИТНЫЙ ДВОР может быть не фичей, но багом верстки, которая по идее должна была выглядеть лучше (см. картинку ниже как иллюстрацию). Гипотеза хорошая, хотя кейс даже в исправленном виде все равно выглядит так себе.

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