Все полезности на следующей неделе, а сейчас я бы хотел избавиться от очередных мемных запасов, которые у меня накопились в сохранёнках.
Также приглашаю и вас покидать рабочих и около рабочих мемов в комментарии под этим постом.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4😁3
Отличная техническая статья про то, как работает и какие есть настройки у элемента Input в вебе. Дизайнерам, которые работают с вебом и пока что мало в нём понимают, должно быть полезно.
Внутри статьи:
– Типы клавиатуры для ввода;
– Disabled vs Read Only;
– Input вызывающий камеру;
– Проверка правописания;
– Автоматический Shift;
– Автокомплит для полей.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Статья про то, как эффективно использовать результаты качественных исследований при работе над продуктом.
Материал в большей степени для продакт-менеджеров, но если вы самостоятельно проводите глубинки, то тоже будет полезно.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥1🎉1
Возвращаюсь к ведению канала, но осознано отказываюсь от системности в публикациях и чёткого вектора на полезные материалы.
Я не хочу превращаться канал в базу знаний и самому себе запрещать тут ныть (самое важное😨 ), хвастаться и публично общаться с коллегами. Очень хочется придти к формату Алёны Чибичик, Олега Александрова или Нади Здоровой.
Если вам печально, что классическая Люстра накрылась медным тазом, то есть суперские альтернативы в виде Дизайнер, привет и UX Horn, этих 2-х каналов хватит с головой. Если вы прям задрот, то можно и на Журналус подписаться.
Понимаю, что сейчас попрощаюсь с многими подписчиками, но искать и публиковать джуновский материал по темам которым я уже 1000 раз проходил не хочется. Изначально канал планировался как инструмент для развития себя и личного бренда, а постепенно начал превращаться в продукт, который я не хочу строить. Возможно, в будущем что-то поменяется, не исключаю, но сейчас так.
Направленность канала остаётся прежней, про продуктовый дизайн.
Тут также как и раньше будут проскакивать статейки и видео, но только те, которые мне действительно помогли и этим хочется поделиться. К примеру, откопал крутую статью про применение JTBD в интерфейсах, которая наконец-то нормально объяснила как эту вундервафлю использовать в реальной работе. Чуть позже скину её сюда.
И мелкий оффтоп, все прошлые публикации вычитывала моя девушка (Настя, приветули❤️ ), потому что я пишу очень неграмотно) Надеюсь теперь её освободить от этой обязанности и публиковаться самостоятельно. Грамотеи, сорян 🥂
Я не хочу превращаться канал в базу знаний и самому себе запрещать тут ныть (самое важное
Если вам печально, что классическая Люстра накрылась медным тазом, то есть суперские альтернативы в виде Дизайнер, привет и UX Horn, этих 2-х каналов хватит с головой. Если вы прям задрот, то можно и на Журналус подписаться.
Понимаю, что сейчас попрощаюсь с многими подписчиками, но искать и публиковать джуновский материал по темам которым я уже 1000 раз проходил не хочется. Изначально канал планировался как инструмент для развития себя и личного бренда, а постепенно начал превращаться в продукт, который я не хочу строить. Возможно, в будущем что-то поменяется, не исключаю, но сейчас так.
Направленность канала остаётся прежней, про продуктовый дизайн.
Тут также как и раньше будут проскакивать статейки и видео, но только те, которые мне действительно помогли и этим хочется поделиться. К примеру, откопал крутую статью про применение JTBD в интерфейсах, которая наконец-то нормально объяснила как эту вундервафлю использовать в реальной работе. Чуть позже скину её сюда.
И мелкий оффтоп, все прошлые публикации вычитывала моя девушка (Настя, приветули
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝29🔥10💘5❤1
Сразу скажу, что ответа у меня нет, я ещё продолжаю тыкать палкой в JTBD. Просто решил поделиться с вами своими мыслями и артефактами с процесса.
Недавно проходился по вакансиям, а точнее по требованиям в них. Практический в каждой продуктовой компании пишут про то что дизайнер должен уметь в исследования, чтобы анализировать продукт и генерировать гипотезы. Короче, классика, но захотелось осознано углубиться.
Для проведения исследований инструментарий у нас очень большой, но самый непонятный для меня в этом наборе JTBD. Я много читал про него, использовал несколько раз в работе, но теория находится на каком-то очень высоком уровне абстракции, а результаты практический всегда сложно конвертировать в интерфейсные решения.
Я вижу пользу инструмента для продактов и фаундеров на ранних стадиях стартапов. Те абстрактные джобы, которые получаются в результате исследования по JTBD помогают принимать стратегические решения связанные с продуктом и формулировать посылы для аудитории в коммуникациях, но не дают ответ на вопрос в какое интерфейсное решение должна конвертироваться полученная информация.
1. Большинство обучающих материалов по JTBD приводят в пример кейсы, который никак не ложатся на разработку цифровых продуктов.
2. Если получается найти кейс использования JTBD для цифрового продукта, то можно найти кучу крутых инсайдов, но только небольшая часть из них конвертируется в интерфейсные решения. И тут вопрос, зачем тратить на это время, если по итогу инструмент приносит мало эффективности? Опять же эта информация скорее полезна стратегам, а они уже после обработки могут отдавать задачи конкретным специалистам (дизайнерам, разработчикам, маркетологам и т.д.).
3. Инструмент слишком громоздкий и трудозатраоный. Да, по итогу появляется куча материалов для беклога, но и адаптация результатов под беклог тоже тратит много времени.
Делюсь материалами, которые я изучал и изучаю снова, чтобы лучше понять 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.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍3
Люстра
Мне тут подсказали, что я неосознанно себя зафреймил и поэтому постоянно прихожу в тупик по поводу использования JTBD.
Первый момент. Нужно понимать, что JTBD большая махина, результаты работы которой могут использовать разные члены продуктовой команды. Поэтому Job Stories бывают на очень высокого уровня абстракции и наоборот. Одни специалисты будут использовать набор Job Stories, к примеру, для принятия стратегических решений, а другие проектирования интерфейса.
Второй момент. Существуют прям отдельные школы JTBD. Первая школа определяет Job Story как прогресс, а другая как активность.
Определение Job Story как прогресс помогает нам понять, те самые описываемые в теории, 4 движимые силы («толчок», «притяжение», «переживания» и «привычки») и контекст, в котором всё это происходит. Это всё даёт нам верхнеуровневое понимание о том что и когда с пользователем происходит, без привязи к каким-то маленьким решениям.
Определение Job Story как активность говорит о том, что мы делаем продукт для решения конкретных микро-задач, чтобы сделать процесс выполнения работы быстрым и удобным.
Некоторые исследователи прям умышленно мешают эти школы вместе в рамках одного исследования для получения результата сразу для большого количества членов команды.
По итогу теперь я могу выделить для себя несколько вариантов использования JTBD:
1. Мы с командой готовим маркетинговые материалы для кампании. Я использую первую школу и определяю контексты и движимые силы наших пользователей.
2. Мне нужно изучить/улучшить отдельный участок в продукте. Я использую вторую школу и сосредотачиваюсь на микро-задачах пользователя.
3. Мы с командой запускаем новый продукт. Я провожу большое исследование с использованием сразу 2-х школ, чтобы хорошо погрузиться в тему и обогатить команду данными.
Понятное дело кейсов разных может быть больше, но для закрепления мне и вам, думаю, будет достаточно.
Первый момент. Нужно понимать, что JTBD большая махина, результаты работы которой могут использовать разные члены продуктовой команды. Поэтому Job Stories бывают на очень высокого уровня абстракции и наоборот. Одни специалисты будут использовать набор Job Stories, к примеру, для принятия стратегических решений, а другие проектирования интерфейса.
Второй момент. Существуют прям отдельные школы JTBD. Первая школа определяет Job Story как прогресс, а другая как активность.
Определение Job Story как прогресс помогает нам понять, те самые описываемые в теории, 4 движимые силы («толчок», «притяжение», «переживания» и «привычки») и контекст, в котором всё это происходит. Это всё даёт нам верхнеуровневое понимание о том что и когда с пользователем происходит, без привязи к каким-то маленьким решениям.
Определение Job Story как активность говорит о том, что мы делаем продукт для решения конкретных микро-задач, чтобы сделать процесс выполнения работы быстрым и удобным.
Некоторые исследователи прям умышленно мешают эти школы вместе в рамках одного исследования для получения результата сразу для большого количества членов команды.
По итогу теперь я могу выделить для себя несколько вариантов использования JTBD:
1. Мы с командой готовим маркетинговые материалы для кампании. Я использую первую школу и определяю контексты и движимые силы наших пользователей.
2. Мне нужно изучить/улучшить отдельный участок в продукте. Я использую вторую школу и сосредотачиваюсь на микро-задачах пользователя.
3. Мы с командой запускаем новый продукт. Я провожу большое исследование с использованием сразу 2-х школ, чтобы хорошо погрузиться в тему и обогатить команду данными.
Понятное дело кейсов разных может быть больше, но для закрепления мне и вам, думаю, будет достаточно.
❤4👍2
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 и 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, возможно, можно всё сразу учесть в одном артефакте.
❤9👍3
Тестирование продуктовых гипотез
Вписался в курс WNBL по исследованиям и сразу получил пачку статей и книг для подготовки. В одном из предоставленных материалов по прототипам привели в пример очень крутое выступление 7-ми летней давности, кажется, от продакта Михаила Високовского.
В выступлении Михаил рассказывал как команда Яндекс Навигатора тестировала продуктовые гипотезы. Самое интересное в этом выступлении сами способы тестирования.
Для тестирования гипотез озвучивания деталей маршрута использовался просто созвон с водителем с шейрингом гео-позиции, а для тестирования интерфейсных гипотез использовались физические прототипы из изоленты, конструктора лего и распечатанных бумажек.
Сейчас такие тесты делают очень редко, либо просто про них перестали рассказывать, не часто теперь встречаю такие кейсы.
После просмотра доклада зашёл в нынешнее представление Навигатора (Яндекс Карты). Интересно как некоторые гипотезы озвученные в том докладе развились и сейчас работают в приложении.
Ссылка на выступление
Вписался в курс WNBL по исследованиям и сразу получил пачку статей и книг для подготовки. В одном из предоставленных материалов по прототипам привели в пример очень крутое выступление 7-ми летней давности, кажется, от продакта Михаила Високовского.
В выступлении Михаил рассказывал как команда Яндекс Навигатора тестировала продуктовые гипотезы. Самое интересное в этом выступлении сами способы тестирования.
Для тестирования гипотез озвучивания деталей маршрута использовался просто созвон с водителем с шейрингом гео-позиции, а для тестирования интерфейсных гипотез использовались физические прототипы из изоленты, конструктора лего и распечатанных бумажек.
Сейчас такие тесты делают очень редко, либо просто про них перестали рассказывать, не часто теперь встречаю такие кейсы.
После просмотра доклада зашёл в нынешнее представление Навигатора (Яндекс Карты). Интересно как некоторые гипотезы озвученные в том докладе развились и сейчас работают в приложении.
Ссылка на выступление
👍10❤2
Привет! На связи Вадим — автор канала и лид-дизайнер команды РосКвартала. Перед нами сейчас стоят амбициозные цели, и мы ищем не менее амбициозного Middle+ дизайнера.
Вместе нам предстоит:
– Создать лучшее на рынке PropTech мобильное приложение для жителей многоквартирных домов;
– Заниматься развитием платформы, которая помогает нашим клиентам управлять жилым фондом и мобильным приложением.
🖥 Подробнее про вакансию
✉️ Форма для отклика
И не забудь поделиться вакансией с друзьями👍
Вместе нам предстоит:
– Создать лучшее на рынке PropTech мобильное приложение для жителей многоквартирных домов;
– Заниматься развитием платформы, которая помогает нашим клиентам управлять жилым фондом и мобильным приложением.
И не забудь поделиться вакансией с друзьями
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤4🎉4👍1
Этим летом я перешёл в роль продуктового менеджера и теперь работаю с внешними продуктами экосистемы сервисов РосКвартала. Сейчас в приоритете запуск новой версии мобильного приложения для жителей (B2B2C) и стратегия развития в краснеющем океане.
Многие аспекты новой профессии до сих пор не понятны, придётся снова, как это было с дизайном, идти от 0 к 1.
По этой причине решил снова вернуться к ведению канала, потому что в своё время это сильно прокачало меня по продуктовому дизайну. Только сейчас фокус будет больше смещён на продуктовый менеджмент.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤34👍10👀7😢2🍾1
Media is too big
VIEW IN TELEGRAM
Акселератор YC выкатил свежий список приоритетных тем для летнего набора, где партнёры особенно хотят видеть заявки.
Больше всего мне, как экс-дизайнеру, интересна позиция Аарона Эпштейна: по его мнению, следующий виток роста придёт к дизайн-центричным командам. Дизайнеры сильны в эмпатии и у них высокая планка качества, что в купе с AI-инструментами позволяет им запускать собственные исключительные продукты.
Полный список запросов YC:
– AI-компании полного цикла;
– Больше дизайн-фаундеров;
– Голосовой AI;
– AI для научных прорывов;
– AI-личный ассистент;
– AI в здравоохранении;
– AI-репетитор для всех;
– Софт для создания роботов;
– Будущее образования;
– AI-охрана дома;
– Создатель внутренних агентов;
– AI-исследовательские лаборатории;
– AI-голосовые ассистенты для e-mail;
– AI для личных финансов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍1
Новое исследование 2025 года от DevCrowd по продуктовым дизайнерам. В этот раз крупная выборка (700+ ответов).
Отчёт может быть полезен, если сейчас задумываетесь о грейдах, зарплатах и развитии навыков.
Внутри исследования:
– Портрет респондента;
– Особенности профессии;
– Навыки и инструменты;
– Карьера и компании (включая зарплаты);
– Сообщество и развитие.
UPD: Кстати, у ребят и про продуктовых менеджеров есть исследование этого же года, тоже можно глянуть.
Please open Telegram to view this post
VIEW IN TELEGRAM
😱4🔥2
Небольшой, но интересный кейс от Елены, продуктового дизайнера в Альфе, в котором в кратчайшие сроки удалось разработать CJM для сложного пользовательского сценария, опираясь на знания нейросетки и на найденные ею исследования.
Елена с помощью Scholar GPT нашла свежие работы по теме, выделила портреты пользователей и их барьеры, собрала первый черновик CJM с GPT и перенесла его в Figma, где вместе с продактом откалибровала карту под UX продукта.
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉7❤🔥4
Люстра
Вчерашний пост про «CJM за 3 дня» неожиданно разлетелся репостами: его закинули в крупный чат ресёрчеров, и там началась бурная дискуссия вокруг этой статьи.
Критики зацепились за дедлайны и способ исполнения: минимальный фактчек и «халтура под горящий срок». В ответ — позиция «инструмент как инструмент»: если итог проверен продактом и принят бизнесом, то почему бы и нет?
Я сам активно использую нейросетки и порой при большом объёме задач это единственный способ выполнить всю работу. При этом теперь задаюсь вопросом, где проходит граница между «ускорить процесс» и «исказить качество».
Короче, рынок всё ещё адаптируется к новым инструментам. Я думал, что нейросети уже «как Figma» в каждой продуктовой команде, но, похоже, переход идёт неравномерно — вопросов по-прежнему много.
UPD: Ссылка на начало обсуждения в чате ресёрчеров.
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉5
У Миши Наера вышел выпуск «Спикерской» с Андреем Алексеевым — продуктовым дизайнером Т-Банка, который запустил и затем продал свой стартап Memo — приложение по изучение языков через видео и мемы.
Всегда с особым интересом смотрю на истории, когда у дизайнеров получается запускать свои продукты. Часто мы не умеем в код, делаем большую ставку на дизайн и забываем про маркетинг — тем ценнее послушать, как у других получилось.
Внутри видео:
– Как начали работу над стартапом;
– Как собирали команду и нанимали;
– Про опыт хакатонов и бенефиты для стартапа;
– Решение о продаже и стартапа;
– Как тестировать гипотезы перед запуском.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2🎉1
This media is not supported in your browser
VIEW IN TELEGRAM
Наткнулся на 21st — открытую площадку, где разработчики публикуют готовые React-компоненты и целые экраны. Это что-то вроде Figma Community, только для кода.
На платформе много решений, собранных с реальных маркетинговых страниц популярных SaaS-сервисов. Например, на обложке — блок с главной страницы Linear.
Помимо вдохновения: если ваша команда работает с React и придерживается подхода shadcn/ui, можно просто отправить ссылку на компонент — разработчики возьмут код и адаптируют его под ваш дизайн.
Единственное: сейчас платформу обновляют — похоже, на её базе делают отдельный продукт. Поэтому возможны баги, а в навигации пока легко потеряться. Вам на страницу Community в раздел Components.
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉5❤🔥3🥰1
Статья Павла Шерера про информационные сущности: зачем они нужны, из чего состоят и как связаны между собой.
Если правильно помню, это база первых курсов IT-специальностей, но тут расписано простым языком и приведены более-менее реальные примеры, так что понять сможет любой.
Хороший материал, если хочется прокачать структурность данных в продукте и своих рабочих артефактах, а также начать ещё лучше коммунициаровать с delivery-командой.
Внутри статьи:
– Термины и пояснения;
– Что такое сущность;
– Свойства сущности;
– Связи между сущностями;
– Иерархическая таксономия;
– Противоречивые классификации;
– Визуализации базы данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥1