👌 Итак, вариант ГЛАГОЛЬ. Мы берём и переплетаем между собой работу аналитика и дизайнера. Не ставим в параллель, не чередуем, а именно переплетаем как аджарец - сырную косичку.

Выглядеть это может так. Приходит к команде сумасшедший продакт типа меня и говорит: «ЖЕЛАЮ ЧТОБЫ БЫЛА КНОПКА НА НЕЕ ЖМЕШЬ И ВСЕ МЕНЯЕТСЯ».

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

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

Расхождения будут - но их можно будет легко отработать в паре. Из-за тесного взаимодействия они смогут договориться в духе «ну чо, Василь Игнатыч, накидаешь мне наброски экранов по моим обрывкам юзкейсов, как мы обсуждали?» или «Макар Степаныч, аналитик ты мой дорогой, я пока рисовал - нашел дурацкий кейс, давай подумаем, как система себя должна вести». Аналитик и дизайнер становятся единой боевой единицей и начинают подстраховывать друг друга - подобная конструкция давно показала свою жизнеспособность в большом маркетинге и называется там креативной парой (в рекламе она состоит из копирайтера и арт-директора - по сути, аналогичных ролей).

Прелесть хорошо выстроенной креативной пары в том, что в ней отпадает вопрос, кто должен ОБЯЗАТЕЛЬНО работать первым, а кто вторым: люди вместе решают общую задачу, и в состоянии сами договориться, кто что делает в какой момент времени - где-то в параллели, где-то сменяя друг друга, а где-то работая буквально вместе рука об руку.

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

И дальше начинается хорошая жизнь. Вылезла ХИЩНАЯ ЖОПА? Не беда, креативная пара в состоянии сообща решить, где нужно бороться интерфейсными методами, а где - изменяя функциональность. Дизайнер уперся в левый юзкейс? Не проблема, аналитически-дизайнерская пара способна пересмотреть процессы и обрубить лишнее, чтобы все работало гармонично. Пользовательское тестирование показало, что все фигня? Не вопрос, креативная пара придумает, как с этим справиться.

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

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

Тем самым термину «дизайн» возвращается его истинное значение, коль скоро это не только отрисовка внешнего вида решения, но и продумывание его логики и внутренней структуры.

«ЛЁХА ХВАТИТ ВТИРАТЬ ЕЛЕЙ СКАЖИ ЧТО НЕ ВСЕ ТАК РАДУЖНО», - взмолитесь вы, вконец опьяневшие от перспектив. Ладно, вот вам минусы:

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

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

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

4. Если у вас жесткий дисбаланс аналитиков и дизайнеров, то вам придется иметь дело с кейсами «аналитик готов брать задачу, но у него нет дизайнера» (или наоборот). В таком случае придется крутиться: или подкидывать аналитику задачи, далекие от UX, или же осторожно готовить материалы таким образом, чтобы потом иметь возможность пересмотреть все с дизайнером заново.

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

P.S. Мудрый Леша Копылов @copylove (поклон ему) в комментах указывает, что Алан "Наше Всё" Купер уже указывал на схожую конфигурацию.

Вот статья на эту тему: https://www.uxmatters.com/mt/archives/2014/11/about-face-the-essentials-of-interaction-design.php

Видос с сабами: https://www.youtube.com/watch?v=-GfmtrPBE-Y



#батинаправда

В нашу любимую рубрику "Бесплатная годнота от Лёхи" стучится новый гость, стряхивает снег с валенок, шумно прочищает нос и расправляет бороду-лопату.

Делюсь видео со своего выступления на онлайн-митапе от Дом.рф про CJM. Все забесплатно, если кто-то будет порываться взять с вас деньги - зовите меня, приеду из прошлого на своей девятке и наведу шороху.

😱 Я рассказываю о том, как сделать CJM мечты - и затем превратить его в полное, бесповоротное, окончательное фуфло. Вы услышите хреновые истории про то, как расшатать чужой CJM, как подпасть под очарование небритых психологов и обрести интерфейсное бессилие, как сделать из сценариев полную кашу, как СДЕЛАТЬ ВСЕ НЕ ТАК.

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

Видео: https://youtu.be/ArOY7OzCsy8?t=8337
Презентации лежат тут: https://disk.yandex.ru/d/knHoOJ3I83JkkQ

Помимо меня, CJM-движ учиняет Сбер, Циан, Сбермаркет и, собственно, Дом.рф.

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

#агабесплатнаягоднота

Котаны, не успел я написать пост - а у меня следующая бесплатная годнота для вас на подходе.

(правка из будущего: ссылка на запись в конце поста)

Картина классическая: батя вышел за хлебом и уехал на гастроли. Через неделю (8 декабря с 19.30 до 21.00) я снова буду принимать участие в бесплатном митапе с чрезвычайно умными людьми - теперь мы будем толковать за исследования.

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

Короче, как оно бывает: сидите вы на исследовании и тут вам в голову бахает задать вопрос респонденту ПРО БУДУЩЕЕ - про то, чего нету сейчас. Ну, типа, вот сейчас такой функции/интерфейса/кнопки/штуки нет, а что, если она появится в будущем и вы…

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

Другая половина исследователей, наоборот, одобрительно кивнет и скажет «Ну а чо, норм тема».

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

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

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

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

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

Повторюсь - 8 декабря, 19.30, все бесплатно. Запишитесь в гугл-форму, и мы пришлем вам ссылку для Zoom.

Не успеваете придти? Не беда, запись тоже будет, я узнавал.

UPD. А вот и запись: https://youtu.be/9vNJ9vJlwxk

#агабесплатнаягоднота

Слышите крики «ЪУЪ СУКА!» где-то за горизонтом? Верно: то ваш любимый Лёха нашел новый экспонат для рубрики БИСКВИТНЫЙ ДВОР и спешит поделиться своим бомбажом с вами.

Сегодня у нас на лопате банк «МЫ НЕ ДЕЛАЕМ UX-ТЕСТИРОВАНИЯ ПОТОМУ ЧТО В НИХ НЕ ВЕРИМ» Тинькофф. Эту мантру я слышал от них пару лет назад и иногда я размышлял, что у них, возможно, что-то поменялось - но нет.

Короче, следите за кейсом.

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

3. Иду в карту. Что я вижу? А ничего я не вижу. Нету никакой истории операций. Мухи унесли.

4. Я перехожу в режим бешеного кабанчика и начинаю носиться кругами по всему приложению, похрюкивая от напряжения. Истории операций нигде нету. Ни на главной, ни где-то еще. Я нахожу даже какое-то невообразимое говнище, которое мне никогда не понадобится - но истории операций нигде нету.
5. Я начинаю грустно выть, будто и не бешеный кабанчик я, а волк, который, как известно, даже когда кабанчик - волк. История операций от этого не появляется.
6. А потом я ее, сука, нахожу. И знаете где?
7. Я еле удерживаюсь от рифмы, но отвечу культурно: ПОД КНОПКОЙ, МАТЬ ЕЕ, «НЕТ ТРАТ В ДЕКАБРЕ»

8. Я гляжу на ноябрьскую операцию под заголовком «Траты за декабрь» и мой ор поднимается выше гор.

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

Обратите внимание, что эти хобгоблины и поступления денег таким же макаром прячут под "Траты за декабрь" (за замечание спасибо дорогому читателю @replaner). Я долго думал, что здесь пошутить - и не смог. Это дно, которое стучит об тебя.

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

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

«МЫ НЕ ДЕЛАЕМ UX-ТЕСТИРОВАНИЯ ПОТОМУ ЧТО В НИХ НЕ ВЕРИМ» Вот же срань какая, а.

P.S. Хотите вишенку на торте? Я снимал скрины с Тинькова, при этом слушая музыку через наушники. Так вот: при открытии приложения Тинек за каким-то чертом останавливает музыку и перехватывает аудиопоток. Да что мне там у вас слушать, медведь вас задери?!

#бисквитныйдвор

Давно хотел вам рассказать про приоритизацию продуктовых задач.

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

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

А еще приоритезация - это скотское слово, в котором я постоянно опечатываюсь (сейчас, например).

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

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

Мой рассказ про преоритизацию (ну вот, опять) будет разбит на 2 части:

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

2. Потом мы оттопырим мизинчик и поговорим про более задротские методы разделаться с вашими задачами. Мы поговорим про ICE, RICE и ICE+ (вряд ли вы про него слышали - это мой домотканый способ приоритизировать задачи в особо запущенных случаях).

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

Итак, поехали.

Сегодня у нас в программе говяжьи методы приоритизации - то, что поможет вам быстро распределить задачи в полевых условиях.

Суть этой группы методов проста - садимся с умными людьми и давай задачи по полкам раскладывать. Тут я выделяю 3 основных метода работы:

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

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

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

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

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

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

Этот дед вынимает сигару изо рта, шевелит густыми усами, смотрит на ваши планы, говорит хмуро «ВОТ ЭТО БЛЪ ДЕЛАЕМ В САМОМ НАЧАЛЕ ЭТО БЛЪ ДЕЛАЕМ В САМОМ КОНЦЕ А ПРО ЭТО БЛЪ ЗАБЫЛ СРОЧНО ЭТО НЕ РЕАЛИЗУЕМО ОПЯТЬ НАПРИДУМЫВАЛИ БЛЪ ХИМОТУ А НАМ ДЕЛАЙ».

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

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

3. Суперстракчед-хуман-аркитекча-центеред-2000 эдишон-ПЛЮС. Как можно догадаться из названия, этот метод приоритизации объединяет предыдущие два - и предполагает, что вы усаживаете за стол переговоров и UX-специалистов, и архитектурных дедов. Спустя несколько часов споров, выпитых бутылок водки и порванных - нет, вы не так поняли, подождите - листов бумаги вы получите план по разработке, который будет сбалансирован и с системной, и с пользовательской точки зрения. Его можно брать в работу и не беспокоиться, что вы где-то сядете в лужу.

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

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

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

(или не спасут, но я не буду пугать вас раньше времени)

#батинамудрость

А вот вам небольшое интермеццо, вызванное комментариями к посту про преоре... преори... приоре... короче, к моему прошлому посту.

Дорогие читатели подняли резонный вопрос - а на кой чорт ты, Лёха, CJM используешь для расстановке приоритетов, когда четкие пацаны для этого издавна используют другой инструмент - User Story Mapping? Это что же выходит, четкие пацаны попутали?

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

Любой User Story Mapping строится в четыре основных шага:

1. Берем сегмент ЦА/персону и определяем основные этапы его взаимодействия с продуктом (ну, там, Ознакомление->Поиск товара->Знакомство с товаром->Оформление покупки->Ожидание->Получение и обратная связь)

2. Для каждого из этапов выписываем, что пользователь будет делать - фильтровать каталог, класть товар в корзину, смотреть бессмысленным взглядом на иконку «Ожидание доставки»;

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

4. Решения (они же фичи) разбиваем на релизы в зависимости от целесообразности и критичности с точки зрения прохождения основного сценария.

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

А теперь отвлечемся от USM и резко, бешено вспомним, как выглядит типовой CJM:

1. Берем сегмент ЦА/персону и определяем основные этапы его взаимодействия с продуктом (ну, там, Ознакомление->Поиск товара->Знакомство с товаром->Оформление покупки->Ожидание->Получение и обратная связь)

2. Расписываем для каждого этапа, что пользователь хочет делать (найти товар, заказать товар, поругаться по поводу товара)

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

4. Попутно выписываем проблемы/боли/конфликты, которые возникают на всем протяжении сценария.

В итоге у вас получится вот такая штука:

Тут у вас должно зашевелиться нехорошее ощущение - что USM и CJM, мягко говоря, слабо отличаются друг от друга:

1. В USM есть разбивка на релизы и может быть разбивка на технические таски для разработки

2. В CJM есть акцент на пользовательские проблемы

3. В CJM идет упор на «Что пользователь хочет» (т.е. мы исходим из желаний пользователя, а не его действий), в USM же допустимо указывать и то, что пользователь хочет - и что он непосредственно делает.

Поясню: в CJM недопустимо писать что-то вида «Пользователь хочет: зарегистрироваться» (ни один пользователь в своем уме не хочет этого делать, это мы от него хотим), а вот при заполнении USM можно в User Tasks спокойно написать «Пользователь регистрируется» - и дальше писать фичи для реализации этой задачи.

«ОК ОК ОК CJM И USM ПОХОЖИ НО ВСЕ ТАКИ РАЗНЫЕ,» - скажете вы, а я в ответ дьявольски захохочу и предложу вам выполнить вот такое мысленное упражнение:

1. Берем наш CJM.

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

3. Берем графу «Чем мы помогаем» (которая с фичами) и разбиваем ее на релизы.

Получаем вот такого супермутанта - который при этом формально остается вполне себе CJM, пусть и с дополнительными обвесами: