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

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

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

😻 Когда хороший хозяин лепит хинкали, он думает про гостя, его вкусы и предпочтения на всем протяжении процесса, а потому хинкали выходят вкусными, душевными и теплыми. После них хочется сказать «Вай мэ!».

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

Не надо так.

#бомбаж

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

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

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

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

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

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

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

Четко - комар носу не подточит, да? Проблема заключается в том, что настолько четко деление между БА и СА срабатывает, по моим скромным наблюдениям, только в продуктах крупных, забюрократизированных (еле выговорил) компаний.

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

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

Чуете, да? Из-за того, что живая разработка не всегда идет по принципу «сперва придумай идеальный сценарий, а мы его реализуем», но часто закольцовывается, пересекается и ходит по кругу, БА начинает думать как СА, а СА начинает думать как БА. Со временем начинают происходить и еще более чудовищные вещи: БА может при продумывании задачи учитывать системную архитектуру и какие-нибудь особенности микросервисов, а СА - описывать задачи с минимальным вовлечением БА. БА приобретает черты СА, а СА начинает издали походить на БА.

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

Конечно, у такого нечеткого подхода к БА и СА есть свой недостаток - это требует определенной прокачки людей и зрелости команды. Но у меня есть и хорошая новость: по моим наблюдениям, подобный курс развития БА в СА, а СА в БА неизбежен и сопровождает практически каждого матерого специалиста. То есть можно сказать, что деление на «бизнес» и «системных» аналитиков - это, скорее, отдельные точки старта аналитической карьеры, но не какое-то жесткое разделение по специальностям. Бизнесовый ты аналитик, системный, конец один - вероятнее всего, со временем ты станешь супераналитиком, который взглядом будет двигать горы, или вообще свалишь в продуктовый менеджмент, где подобные скиллы очень востребованы.

Подкину, впрочем, вам еще пару исключений:

1. Помимо ветки развития в супераналитика, СА в теории могут эволюционировать в системного архитектора, который плевать хотел на эти ваши бизнесовые замороки.
2. У БА есть отдельная ипостась - БА в консалтинговом агентстве. Эти ребята живут по своим специфическим правилам, далеким от нашей крестьянской разработки, и это отдельный жанр жизни и интересный опыт.
3. Никто не отменял жизни в огромных жестких мегакорпорациях, где ты сидишь как чистый БА или СА, перекладываешь задачки в жире по регламенту и медленно погружаешься в корпоративный дзен.

Но это исключения. В остальном же запомните:
⁃ Если ты БА, то готовься стать СА - или работать в узком забюрократизированном сегменте;
⁃ Если ты СА, то готовься стать БА - или работать в узком забюрк.. забрю… забор… тьфу, короче, вы поняли;
⁃ Если ты набираешь аналитиков себе в живой продукт, смотри на то, кто тебе нужен и что человек умеет, а не на то, кто как прозывается. Это все в большинстве случаев пустое.

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

Котаны, до меня доехала книга Карла Вигерса The Thoughtless Design Of Everyday Things, сейчас буду делиться впечатлениями.

(Да-да, это из той самой посылки, которую Амазон от меня пытался зажопить несколькими постами ранее - но доставил-таки, курилка)

Если вы сейчас подумали «ЧО ЗА ВИГЕРС-ХУИГЕРС», то представьте себе, будто Джордж Лукас отжал у мышастого лицензию на «Звездные войны» и снял новую часть, при этом экспериментируя с новыми жанрами и привлекая нормальных сценаристов и режиссеров. Мощное возвращение, да?

Вот и тут мощное. Карл Вигерс знаменит, прежде всего, своей чудо-книгой Software Requirements (чудовищно переведенной как «Разработка требований к программному обеспечению»), которая стала настольным учебником сразу для нескольких поколений аналитиков и проектировщиков.

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

И вот этот самый Вигерс, император аналитики и проектирования, без объявления войны выпускает книгу про дизайн, в которой нескрываемо стебется над книгой The Design Of Everyday Things («Дизайн привычных вещей») под авторством Дона Нормана - чудодейственного старца, который, на минуточку, когда-то придумал термин «UX».

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

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

И вот представьте мое изумление, когда оказалось, что книга Вигерса - это один огромный БИСКВИТНЫЙ ДВОР, где Вигерс в своём академически-ядовитом стиле разбирает косячные приложения, сайты, ручки дверей автомобилей, водопроводные краны, гитары, швабры и вообще все мироздание, при этом не забывая периодически воздевать палец к небу и говорить «А ВОТ ЩАС Я ВАМ РАССКАЖУ КАК НАДО С ТОЧКИ ЗРЕНИЯ ТЕОРИИ». Thoughtless Design в названии книги оказался не беззубым "Хорошим дизайном, чтобы пользователь не задумывался", но шипастым хлыстом в адрес безголовых дизайнеров, не желающих думать.

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

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

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

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

2. Учитывайте реальные сценарии использования

3. Учитывайте широкий разброс контекстов использования

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

5. Давайте пользователю полезную обратную связь.

6. Не тратьте время пользователя впустую.

7. Подчиняйте дизайн удобству для пользователя.

8. Учитывайте огромную вариативность людей.

9. Не возлагайте на пользователя большую ментальную нагрузку.

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

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

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

Вигерс снова крутой, будьте как Вигерс.

P.S. А! Вспомнил еще историю, как Карл Вигерс однажды моего кореша на хер послал, но про это я вам отдельно расскажу.

#йоукнига

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

Для начала давайте договоримся: я буду называть бизнесовых и системных аналитиков словом «аналитик», а вы будете делать вид, что так и нужно, ладно?

(почему так можно - читайте парой постов выше)

Итак, у нас есть дизайнер и аналитик, которых надо увязать в единый процесс. Чисто по логике у нас есть три доступных варианта:

🖕 Вариант АЗЪ. Сперва аналитик прописывает требования и спецификации, затем дизайнер по ним рисует макеты.

Вариант классический и повсеместно распространённый, но хероватый.

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

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

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

Все демотивированы, сказки не выходит, занавес.

🤞 Хотя подождите! У нас же есть еще вариант БУКИ! В этом случае дизайнер может рисовать макеты первым, а аналитик городить свою аналитическую балалайку на их основе.

Впрочем, это тоже херня, заканчивающаяся примерно одним и тем же: дизайнер рисует классные макеты, передаёт аналитикам и слышит через 15 минут от них вой «ДА ЭТО ЖЕ ТАК НЕ РАБОТАЕТ». И начинаются переделки и хождения кругами, сопровождающиеся срачами и воплями «ДА ОТКУДА ОН ЭТУ ХЕРНЮ ВЗЯЛ». Тоже не фонтан.

🤟 Вариант ВЕДИ. Пускаем аналитику и дизайн в параллель - нехай соревнуются.

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

⁃ ТАК ЧТО ЖЕ О МУДРЫЙ ЛЁХА, - спросите вы скромного меня, - ВЫХОДА НЕТ ЖИЗНЬ БОЛЬ И АНАЛИТИКА И ДИЗАЙН ЭТО ДВА УРОБОРОСА ПОЖИРАЮЩИХ ДРУГ ДРУГА И НАШИ НЕРВЫ?

Нет, друзья мои. Есть еще более хитрый вариант, про который я умолчал - и который пойдёт у нас под названием ВАРИАНТ ГЛАГОЛЬ.

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

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

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

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

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

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

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

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

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

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

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

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

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. Я еле удерживаюсь от рифмы, но отвечу культурно: ПОД КНОПКОЙ, МАТЬ ЕЕ, «НЕТ ТРАТ В ДЕКАБРЕ»