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

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

И знаете, я упрощаю. Удаляю сложные термины и формулировки. Привожу банальные и тошнотворные примеры. Лучше я изложу свою идею на 70%, но её поймут, чем на все 100 - но аудитория не отдуплит, о чём это я толкую.

Но иногда это надоедает. Как сейчас, например.

Мы делаем клёвый проект с Олегом Нестеровым и Адой Солвич. На нём нарабатывает крутые скиллы Евгения Шамрай. К нему даже приложил лапку Вадим Митякин. А Артём Фенелонов вообще стал тем, кто в принципе сделал возможным наше общее сотрудничество.

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

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

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

В общем, я делаю. Вот ссылка.

Несколько лет назад у меня был довольно забавный период.

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

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

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

Сейчас те времена прошли, но осадочек остался. И вот сегодня я решил набросать коротенькую статью про то, что информационная безопасность продукта начинает формироваться ещё на этапе его дизайна.

Мой партнёр по опасному бизнесу (с) Вадим Митякин пишет книгу, где он рассказывает про метод, по которому строится работа продюсеров в нашей артели. На подходе третья глава. Не переключайтесь.

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

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

Немного оффтопа ещё никому не повредило

Вот сейчас будет грустно.

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

То есть наш сервис ещё не умеет принимать оплату и доставка у нас не автоматизирована, а мы уже за каждую сотую покупку ачивки раздаём и турнирную таблицы покупателей имплементируем.

Но опасность такого подхода даже не в том, что он может запросто похоронить ваш проект. Самое страшное, что он может сделать это незаметно.

Синдром Преждевременной Геймификации - это такие Царь-Грабли продуктовой разработки.

Разбираем на цитаты

Как вы думаете, что отличает UX-профессионала от новичка или дилетанта?

- ОООО ЁМАНА, - интеллигентно заметите вы, заломив кепку на затылок, - ВСЁ ПРОСТО СЛУШАЙ СЮДА ПРОФФЕСИОНАЛ ЗНАЕТ ПЕРСОНЫ КУПЕРА ВСЯКИХ ДЕДОВ ТИПА НОРМАНА НИЛЬСЕНА А ЕЩЕ CJM JTBD ДИЗАЙН-МЫШЛЕНИЕ ФРЕЙМВОРК IBM ФИГМУ СКЕТЧ ЦЕППЕЛИН И МАТУШКУ АКШУРУ ЧИТАЕТ ЮРУ ВЕТРОВА А ДЕЛИТАНТ ПАЛЬЦЕМ В СТЕНКЕ КОВЫРЯЕТСЯ И НИЧЕГО ЗНАТЬ НЕ ХОЧЕТ.

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

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

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

👹 У вашего проекта до безумия сжатые сроки - и у вас нет времени на нормальные исследования;
🤡 Ваше руководство - психопаты, которые принимают дизайн по принципу “нравится/не нравится моей собаке”. Вы должны сделать фичу не потому, что она нужна с точки зрения бизнеса или пользователей - а просто потому, что кто-то наверху счел это прикольным;
😈 Ваши коллеги - отборные хобгоблины, которые исповедуют принцип “пользователи дебилы, мы знаем лучше них”;
☠️ К вам пришел скрам-мастер и начал заставлять вас думать, рисовать, исследовать, прорабатывать и отдавать команде результат вашего труда за одну-единственную неделю - потому что у вас такой спринт; а еще он заявил, что решения по дизайну принимаются голосованием всей команды - и вы должны подчиниться местному большинству;
💩 Никтое желает разбираться в метриках, и ваш реальный критерий эффективности - как быстро вы выкатываете новые фичи и насколько они органолептически нравятся большим боссам;
🤢 Дизайн-мышление, HADI-циклы и прочую заумь все вокруг вас считают какой-то блажью, которую надо вежливо выслушать - а потом игнорировать;
🎃 Вас ставят отвечать за UX-дизайн, но при этом полностью лишают контроля над разработкой и доступа к продукту.

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

Многие из вас скажут - брат, да это ж жопа.

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

1. Принять, что ничего не получается, впасть в депрессию, безвольно пойти на поводу у окружения и превратиться в рыбу-УГ.
2. Принять, что ничего не получается, опустить руки и покинуть компанию в поисках Идеально Работающей команды (истории известны примеры, когда персонажи по нескольку лет шлялись по рынку в поисках Золотого Грааля).

3. Надеть белые доспехи, устроить лютый срач на тему “ВЫ ДЕБИЛЫ И НЕ ЛЕЧИТЕСЬ А ВОТ КАК РАБОТАЮТ НОРМАЛЬНЫЕ ЛЮДИ”, задолбать всех своей праведностью, выгореть в конфликтах - и перейти на пункт 1 или 2.
4. Надеть белые доспехи, провозгласить себя UX-гуру, прекратить практическую деятельность, отпустить бороду и начать консультировать и преподавать, не отвечая за результат.

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

Понимаете, в чем суть, да? Профессионал - это не тот, кто умеет пропускать свои продукты через готовые фреймворки. Профессионал - это тот, кто умеет собирать (и модифицировать!) фреймворки вокруг своей индивидуальной ситуации и задач. Получится использовать что-то готовое - отлично; не получится - сделаем все сами с оглядкой на эффективность и целесообразность. То есть вы не обязаны знать все фреймворки-инструменты-методики - но вы обязаны уметь их вывести с нуля, если потребует ситуация.

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

Лютое бесстрашие и умелая готовность ко всему отличает настоящего рыцаря хуикса от мимокрокодила. Помните это.

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

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

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

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

#факап #инфополе #разработка @shererpro

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

Итого:

20 дней. 15 статей на Дзене. Время просмотра - около 5k минут. Почти 80% дочитываний.

CTR в ленте - ничтожные 1.5% (это более чем объяснимо). Количество посетителей из их "рекомендательной системы" смехотворно, но и это понятно.

Суммарный доход - 30k рублей (это при том, что монетизация на канале не доступна).

Дзен, конечно, мусор и днище, но эксперимент не заканчиваем, ещё месяц.

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

Может оказаться полезно начинающим аналитикам и дизайнерам/проектировщикам, которые хотят проверить себя. Или их начальникам, которые хотят проверить дизайнеров.

#бизнес #метрики #финансы @shererpro

Дизайн VS Бизнес

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

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

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

Я победил, разумеется, я ж типа начальник. Но дизайнер, надо отдать ему должное, ушёл несломленный.

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

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

Однако не уверен, что зайдёт. Да и в черновиках факап-постов ворох скопился. Короче, решил у вас спросить. Зря, что ли, канал завёл.

Пока пишется статья про бизнес и дизайн, вот вам лонгрид о фрилансе.

Идея этого поста где только со мной не путешествовала: родилась она на закрытом форуме Гильдии вольных проектировщиков, затем повисела у меня в Фейсбуке, потом перекочевала на канал в Дзене. Думал, там и останется. Пока несколько студентов на одном из последних занятий не попросили меня рассказать о фрилансе. Занятие заканчивалось, и я пообещал им написать об этом статью. Обещания надо выполнять, конечно, но я чёт увлёкся.

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

Итак, обещанный пост про дизайн и бизнес. Помните, в понедельник спрашивал? Про то, как UX может убить продукт. Не один и не сразу, но может.
#бизнес #пользователи #ux @shererpro

Неожиданно, но за несколько часов своей жизни пост собрал лютое количество реакций. Цикл про дизайн данных так не хайпанул на старте.

Но знаете в чём прикол? Большинство тех, кто за бизнес, пишет в личку. Тех, кто решился написать об этом открыто, в комментариях соцсетей, сильно меньше. Зато молодцов, которые резво подскочили на защиту своей неуёмной недальновидности – пруд пруди. Уже даже Трампа с капитализмом умудрились приплести.

Прошлый пост про "юикс убьёт ваш бизнес" разошёлся впечатляющим тиражом. На Дзене, будь он проклят, у меня уже 40 статей – но эта первая, которая набрала полторы сотни дочитываний меньше, чем за сутки. Самое время перепрофилироваться в провокатора. Но делать этого я, конечно, не буду (с).

А тем временем мы продолжаем потихоньку проходиться по факапам. Я писал, что у меня их ворох, помните? Вот, держите первый. Если раньше посты из факап-цикла были более общими, то тут – конкретная проблема и её конкретное решение. Даже немного графиков есть. Упрощённые, правда, как и подача. Но дзен на то и дзен.

#факап #тестирование #разработка @shererpro

Если в любой моей статье хоть раз упоминается продюсирование, кто-то обязательно спросит, что это такое. Объяснить «что» несложно. Сложнее объяснить «зачем».

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

#продюсирование #разработка @shererpro

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

#факап #инфополе #финансы @shererpro

Каждый должен заниматься своей работой. Когда разработчики начинают лезть в UX, а дизайнеры выбирать программные библиотеки – продукт становится на шаг ближе к смерти. А если интерфейсы проектируются под фактическим руководством самых безжалостных юристов? Сталкивались с таким? Я вот сталкивался. Ощущения, как будто попал в мясорубку, из которой тебя вышвырнуло прямиком в кипящее масло. Рекомендую.

#факап #интерфейсы #ux @shererpro