Так что возьмите за правило: пишете для людей - обращайтесь к людям. И все будет хорошо.

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

Котаны, хочу поделиться с вами на ночь одной очень личной историей, связанной с дизайном. Заваривайте чай!

Иногда я люблю веселить публику своим пёстрым трудовым путем. Смотрите:

⁃ сперва в 00-х годах я был копирайтером, IT-журналистом, а еще верстал газету;
⁃ в 10-х годах я по уши погрузился в аналитику-проектирование-дизайн в заказной разработке, тогда же полюбил этот ваш хуикс;
⁃ в 18 году перешел в Росбанк и там внезапно стал продактом;
⁃ в 23 году - после серии разных компаний, - перешел в Яндекс.Маркет и так же внезапно стал дизайн-директором b2b;
⁃ в конце 24 года перешел в Звук, и стал кем? Правильно - снова продактом!

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

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

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

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

В-третьих, всплывали вопросы философского плана - например, как мне называть себя на выступлениях, чтобы было понятно, кто я и о чем я? Уместно ли мне в Хуикс писать не только про дизайн, но и про продуктовые штуки? Не вызываю ли я короткое замыкание в головах у HR своими скачками из дизайна в продукт и обратно? Как меня видит рынок?

Точки крайнего умопомешательства я достиг в конце 24 года, когда успешно отсобеседовался сразу на две роли - на арт-дира в «Кинопоиск» и - буквально встречей в тот же день! - на продакт-лида в «Звук».

И вот кто я был после этого?..

С другой стороны, я не мог жить иначе.

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

И продуктовый менеджмент для меня тоже был немыслим без погружения в UX, как следствие - в интерфейсы и лук-н-фил, как следствие - в дизайн; продакт-менеджеры, которые хвастались передо мной, что они дальше Экселя и Жиры носу не кажут, всегда казались мне ущербными.

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

Мучился я долго - а ответа на вопрос все не рождалось. И вот что мне было делать? Дожидаться пенсии, когда все эта пляска между умными и красивыми для меня закончится и я буду целыми днями играть в любимые соло-варгеймы? Сменить профессию и пойти переворачивать тюленей в зоопарк? Объявить себя UX-гуру, облысеть и написать красную книгу под названием «UX-методология шизофреника»?!

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

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

От этого постулата оставался один небольшой шаг в сторону решения моей личной проблемы с самоидентификацией - и ответ пришел мне в голову после очередного почти одновременного собеседования с продактами Звука и дизайнерами Кинопоиска.

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

Роли дизайнера и продакта в моей голове окончательно размылись, смешались - и вместе с тем окончательно размылся смысл вопроса «Кто я?»: ведь если конечной точкой развития отношений продакта и дизайнера является их полное слияние, то какой смысл выбирать, кем сегодня считаешь себя ты?

И внезапно ответ на вопрос «Кто я?» решился просто: он отпал для меня за ненадобностью. Для меня стало важным ответить на «Зачем я здесь», «Что я смогу дать», «Что это даст мне» - а это вопросы совершенно другого ряда, зависящие не от моего самоощущения, но конкретного продукта, его команды и имеющегося челленджа.

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

И мне сразу стал понятен пример известных мне сильных цифровых специалистов, которых постоянно мотало между продуктом и дизайном - будь то любимый мною Тарас Шаров из Яндекс.Маркета; потрясающий Дима Иваночек, умеющий одновременно делать красивые вещи и крутить в голове Эксель; наконец, легендарный Мазуревич, который просто легендарен. Они не мучились самоназванием - а просто работали там, где им интересно, и делали то, что им было важно, не оставаясь заложниками роли.

И я в декабре 2024 года, к своему удивлению, оказался Лёхой, который умеет делать цифровые продукты. Я выдохнул - и решил пойти в Звук продактом. Просто потому что так было интереснее.

#личное

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

Что ж, извольте! Сперва давайте завтыкаем на следующую увеселительную схему:

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

Диаграмма разбита на 3 ромба, соответствующих трем основным этапам жизни продуктовой задачи: 1) определение и проработка продуктовой проблемы; 2) нахождение и проработка идеи для решения проблемы; 3) выкатка решения проблемы и последующие разработки.

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

А теперь посмотрим, как это работает на примере отдельных этапов:

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

- Разобравшись с проблемой, мы начинаем генерить идеи для ее решения (Solution Discovery). Идей у нас может появиться много, часть идей будут откровенно бредовыми, часть - нереализуемыми, часть - вредными. Это и есть самая широкая точка ромба - точка максимальной неопределенности. Чтобы одолеть босса этого уровня, нам нужно проанализировать каждую из идей, оценить ее на адекватность и реалистичность, а уже после этого остановиться на решении, которое будет нам нравиться (Concept Validation). Это будет вторая точка определенности.

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

И так мы двигаемся дальше, играя на баяне неопределенности и с каждой итерацией приближаясь к оптимальному определенному решению

Тут есть пара важных оговорок:

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

Именно поэтому в третий ромб заключен этакий бычий пузырь, который подразумевает совместную итеративную разработку - а сам этап носит интересное название Design&Development: в этот момент команда дизайна и продукта должна жить в обнимку с разработчиками, чтобы делать продукт вместе. Впрочем, если у вас в ходу водопад, то Triple Diamond от этого не становится менее актуальным - просто в его состав могут добавляться дополнительные звенья (ромбы) под каждый этап.

2. На конкретно этой схеме есть условные этапы Design&Development, Early Access Programme, Commercial Availability - я призываю не относиться к ним слишком серьезно, потому что в реальной жизни они могут быть сильно перемешаны между собой (выкатили что-то на широкую публику - собрали фидбек - выкатили обновление на узкую группу пользователей - потестировали…), но от этого суть третьего ромба не меняется - от состояния «я хз, сработает это или нет» мы приходим к идеальному варианту, обкатанному на аудитории. И мне кажется дико важным, что этот этап у дизайна и разработки - общий.

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

Я не могу себе представить адекватный продуктовый процесс, который противоречил бы Triple Diamond’у - а это значит, что вы можете смело брать эту модель как образец для подражания или диагностировать с ее помощью свои существующие продуктовые процессы. Словом, полезная штука, рекомендую.

Особенно красиво модель Triple Diamond расцветает в комбинации с HADI-подходом и Agile-манифестом - но про это мы поговорим с вами в иной раз.

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

Всех с наступающим, друзья!

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

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

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

Вместе точно справимся.

Обнял,
всегда ваш Лёха.