Люстра

💬 Похоже, не все ещё готовы

Вчерашний пост про «CJM за 3 дня» неожиданно разлетелся репостами: его закинули в крупный чат ресёрчеров, и там началась бурная дискуссия вокруг этой статьи.

Критики зацепились за дедлайны и способ исполнения: минимальный фактчек и «халтура под горящий срок». В ответ — позиция «инструмент как инструмент»: если итог проверен продактом и принят бизнесом, то почему бы и нет?

Я сам активно использую нейросетки и порой при большом объёме задач это единственный способ выполнить всю работу. При этом теперь задаюсь вопросом, где проходит граница между «ускорить процесс» и «исказить качество».

Короче, рынок всё ещё адаптируется к новым инструментам. Я думал, что нейросети уже «как Figma» в каждой продуктовой команде, но, похоже, переход идёт неравномерно — вопросов по-прежнему много.

UPD: Ссылка на начало обсуждения в чате ресёрчеров.

✨ Когда CJM нужен через 3 дня (а не месяца)

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

Елена с помощью Scholar GPT нашла свежие работы по теме, выделила портреты пользователей и их барьеры, собрала первый черновик CJM с GPT и перенесла его в Figma, где вместе с продактом откалибровала карту под UX продукта.

📎 Ссылка на статью

🥸 Исследование продуктовых дизайнеров

Новое исследование 2025 года от DevCrowd по продуктовым дизайнерам. В этот раз крупная выборка (700+ ответов).

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

Внутри исследования:
– Портрет респондента;
– Особенности профессии;
– Навыки и инструменты;
– Карьера и компании (включая зарплаты);
– Сообщество и развитие.

📎 Ссылка на исследование

UPD: Кстати, у ребят и про продуктовых менеджеров есть исследование этого же года, тоже можно глянуть.

👀 Запросы к стартапам от Y Combinator

Акселератор YC выкатил свежий список приоритетных тем для летнего набора, где партнёры особенно хотят видеть заявки.

Больше всего мне, как экс-дизайнеру, интересна позиция Аарона Эпштейна: по его мнению, следующий виток роста придёт к дизайн-центричным командам. Дизайнеры сильны в эмпатии и у них высокая планка качества, что в купе с AI-инструментами позволяет им запускать собственные исключительные продукты.

Полный список запросов YC:
– AI-компании полного цикла;
– Больше дизайн-фаундеров;
– Голосовой AI;
– AI для научных прорывов;
– AI-личный ассистент;
– AI в здравоохранении;
– AI-репетитор для всех;
– Софт для создания роботов;
– Будущее образования;
– AI-охрана дома;
– Создатель внутренних агентов;
– AI-исследовательские лаборатории;
– AI-голосовые ассистенты для e-mail;
– AI для личных финансов.

📎 Ссылка на статью

А я дальше в спячку.

Ладно, норм. Спасибо, Дилан.

Summary config.new

Config 2025

Cursor в Figma? А зачем? Дизайнеры не поймут, а у разработчиков другие игрушки.

Config 2025

Теперь наконец-то заживём?

Config 2025

🙂 Теперь я продакт

Этим летом я перешёл в роль продуктового менеджера и теперь работаю с внешними продуктами экосистемы сервисов РосКвартала. Сейчас в приоритете запуск новой версии мобильного приложения для жителей (B2B2C) и стратегия развития в краснеющем океане.

Многие аспекты новой профессии до сих пор не понятны, придётся снова, как это было с дизайном, идти от 0 к 1.

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

Привет! На связи Вадим — автор канала и лид-дизайнер команды РосКвартала. Перед нами сейчас стоят амбициозные цели, и мы ищем не менее амбициозного Middle+ дизайнера.

Вместе нам предстоит:
– Создать лучшее на рынке PropTech мобильное приложение для жителей многоквартирных домов;
– Заниматься развитием платформы, которая помогает нашим клиентам управлять жилым фондом и мобильным приложением.

🖥 Подробнее про вакансию
✉️ Форма для отклика

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

Тестирование продуктовых гипотез

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

В выступлении Михаил рассказывал как команда Яндекс Навигатора тестировала продуктовые гипотезы. Самое интересное в этом выступлении сами способы тестирования.

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

Сейчас такие тесты делают очень редко, либо просто про них перестали рассказывать, не часто теперь встречаю такие кейсы.

После просмотра доклада зашёл в нынешнее представление Навигатора (Яндекс Карты). Интересно как некоторые гипотезы озвученные в том докладе развились и сейчас работают в приложении.

Ссылка на выступление

JTBD + CJM

Изучил подробнее метод Анны Матвеевой с объединением JTBD и CJM, а также снова перечитал статью Джеймса Томаса про подключение Desired Outcomes к Job Stories. На самом деле оба пришли практический к одному и тому же.

Сходства:
– Выделяется большая Job Stories и она декомпозируется на составные, если это требуется;
– Job Stories расписываются с помощью ориентированного графа с набором необходимых данных;
– Во всех ориентированных графах присутствует Desired Outcomes.

Отличия:
– Анна явно не предлагает выделять Core и Growth JobStories;
– Джеймс явно не предлагает строить CJM;
– Джеймс предлагает создавать интересный суммаризирующий артефакт для команды «Jobs map».

Адаптация на адаптации

Из адаптаций Анны и Джеймса я слепил черновик своей адаптации, которую можно увидеть в обложке поста. Такая адаптация подойдёт не всем, может она и мне не подойдёт, это только черновик. Такая адаптация создаётся под определённый проект, на котором хочется обкатать знания.

На всякий случай объясню то что вы видите на обложке.

1. У продукта, который я хочу заисследовать, есть определённый набор больших Job Stories. Короче, верхнеуровнего то ради чего в принципе будут использовать продукт. Это Core Functional Job.

2. Core Functional Job слишком большие, чтобы на основе них генерировать какие-то решения, поэтому их нужно декомпозировать на составные, т.е. Core Job Stories (MVP) и Growth Job Stories. Core JS первыми берутся в исследования, а Growth JS идут в беклог и достаются из него когда обработаны все Core JS.

3. Чтобы качественно происследовать JS и получить данные, которые помогут сгенерировать решения, строится CJM и(или) UJM. Первая исследует продвижение человека по JS как покупателя (customer), а вторая как пользователя (user).

У меня есть большие сомнения в нужности этапов для Core Functional Job и разделении JS на CJM и UJM, возможно, можно всё сразу учесть в одном артефакте.

Мне тут подсказали, что я неосознанно себя зафреймил и поэтому постоянно прихожу в тупик по поводу использования JTBD.

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

Второй момент. Существуют прям отдельные школы JTBD. Первая школа определяет Job Story как прогресс, а другая как активность.

Определение Job Story как прогресс помогает нам понять, те самые описываемые в теории, 4 движимые силы («толчок», «притяжение», «переживания» и «привычки») и контекст, в котором всё это происходит. Это всё даёт нам верхнеуровневое понимание о том что и когда с пользователем происходит, без привязи к каким-то маленьким решениям.

Определение Job Story как активность говорит о том, что мы делаем продукт для решения конкретных микро-задач, чтобы сделать процесс выполнения работы быстрым и удобным.

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

По итогу теперь я могу выделить для себя несколько вариантов использования JTBD:

1. Мы с командой готовим маркетинговые материалы для кампании. Я использую первую школу и определяю контексты и движимые силы наших пользователей.
2. Мне нужно изучить/улучшить отдельный участок в продукте. Я использую вторую школу и сосредотачиваюсь на микро-задачах пользователя.
3. Мы с командой запускаем новый продукт. Я провожу большое исследование с использованием сразу 2-х школ, чтобы хорошо погрузиться в тему и обогатить команду данными.

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

⁉️ Как пользоваться JTBD?

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

➡️ Интро

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

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

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

➡️ Предъявы к JTBD

1. Большинство обучающих материалов по JTBD приводят в пример кейсы, который никак не ложатся на разработку цифровых продуктов.
2. Если получается найти кейс использования JTBD для цифрового продукта, то можно найти кучу крутых инсайдов, но только небольшая часть из них конвертируется в интерфейсные решения. И тут вопрос, зачем тратить на это время, если по итогу инструмент приносит мало эффективности? Опять же эта информация скорее полезна стратегам, а они уже после обработки могут отдавать задачи конкретным специалистам (дизайнерам, разработчикам, маркетологам и т.д.).
3. Инструмент слишком громоздкий и трудозатраоный. Да, по итогу появляется куча материалов для беклога, но и адаптация результатов под беклог тоже тратит много времени.

➡️ База по JTBD

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

1. Курс от Tilda по JTBD. Единственный нормальный бесплатный курс в публичном доступе.
2. Статья про JTBD от Tilda. Дополнение к курсу выше в текстовом виде для закрепления информации.
3. Глава про JTBD из книги Ивана Замесина. Крутой продакт рассказывает про базу JTBD, свой опыт работы с ним и даёт советы по адаптации инструмента.
4. Открытый урок по JTBD от BBE. Небольшой материал про теорию JTBD для закрепления всей информации полученной выше.
5. Подкаст Make Sense. Тут, к сожалению, сложно выделить какой-то конкретный выпуск, везде понемногу.

➡️ Применение для дизайнеров

Благо, что коллеги делятся своим опытом применения JTBD и в интернете есть что почитать или посмотреть по теме.

1. Курс по исследованиям. Набор обучающих материалов от Крис Барильник ex-исследователя в MAX с адаптацией классического JTBD с составлением сегментов, JS и гипотез ещё до интервью с пользователями.
2. Руководство по Jobs to Be Done и Desired Outcomes для дизайна интерфейсов. Статья от Джеймса Томаса из Домклик, в которой он миксует JTBD c Desired Outcomes и генерирует конкретные интерфейсные решения с помощью этого.
3. Блок «Исследования» на курсе по мобилкам от BBE (платно, а бесплатно, на всякий случай, осуждаю). В курсе Анны Матвеевой есть целый блок про исследования, в котором она предлагает соединять JTBD c CJM.

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

Я не хочу превращаться канал в базу знаний и самому себе запрещать тут ныть (самое важное 😨), хвастаться и публично общаться с коллегами. Очень хочется придти к формату Алёны Чибичик, Олега Александрова или Нади Здоровой.

Если вам печально, что классическая Люстра накрылась медным тазом, то есть суперские альтернативы в виде Дизайнер, привет и UX Horn, этих 2-х каналов хватит с головой. Если вы прям задрот, то можно и на Журналус подписаться.

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

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

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

И мелкий оффтоп, все прошлые публикации вычитывала моя девушка (Настя, приветули ❤️), потому что я пишу очень неграмотно) Надеюсь теперь её освободить от этой обязанности и публиковаться самостоятельно. Грамотеи, сорян 🥂

✨ Как работать с результатами интервью

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

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

🔗 Ссылка на статью

💎 Возможности элемента Input

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

Внутри статьи:
– Типы клавиатуры для ввода;
– Disabled vs Read Only;
– Input вызывающий камеру;
– Проверка правописания;
– Автоматический Shift;
– Автокомплит для полей.

🔗 Ссылка на статью

☀️ Мемное воскресенье №2

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

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

✨ Как описать методологию исследования: гайд с примерами и шаблонами

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

Внутри статьи:
– Что такое методология исследования;
– Почему важно описывать методологию;
– Как написать методологию исследования;
– Что мы исследуем;
– Как мы будем исследовать;
– Пример методологии исследования;
– Шаблоны для описания методологии;

🔗 Ссылка на статью

💎 Как провести конкурентный анализ для нового продукта или фичи

Статья Никиты Булгакова, преподавателя в BBE и продакт-лида в ProductHub, о том, как правильно изучать конкурентов.

Внутри статьи:
– Как спланировать исследование конкурентов;
– Как собирать информацию и структурировать;
– Как анализировать информацию и применять в решениях;

🔗 Ссылка на статью