Ты нашел, еще 10 человек не нашли. На любой продукт есть конкурет, который делает больше/лучше/дешевле. Но я, допустим, первый раз про этот сайт услышал, до этого ILovePDF юзал)
Тут работает то же правило, что и при создании доступной среды в городе
Делая удобнее среду для колясочников, вы одновременно делаете лучше и для мам с колясками, и для людей на велосипедах и самокатах, и для новых московских роверов 🫡
Тоже самое и с интерфейсами Интересная статья была про слак, где команда делала инклюзивный дизайн, и в процессе фиксанула много UX микробагов, на которые до этого внимания не обращали. И одновременно работу с клавиатурой улучшили на порядок
Плюс доп информация по Personas помогает предлагать релевантные решения. Например, для молодежи коммуникация в telegram более релевантна Whatsup ну и так далее. То есть Personas драйвит выбор оптимизации шагов CJM.
Я редко пользуюсь персонами, особенно при создании Масс Маркет продуктов
У меня есть список работ (Jobs), которые я считаю приоритетными и ридерживаюсь их при выборе респондентов, создании вопросов или проектировании сервисов.
Но в общем то да, CJM делается чаще всего не для всех, а для какого то сегмента, а каким инструментом мы будем обозначать сегменты это уже другой топик для обсуждения)
В вашем примере выше про найм разработчиков стоило бить не на тех кто прошел / отказался, а на какие-то другие черты - кто в вашем городе и кому удобно приехать лично и кто удаленно, к примеру.
Вот эти особенности кто в вашем городе & кому удобно приехать лично родились только после того, как мы опросили тех, кто отказался и кто прошел собесы. Ну и такая разбивка намного детальнее, чем прошел/отказался, потому что респондентов у нас не 200, а не больше 10 было. Чем больше определяющих факторов мы ставим, тем меньше наша выборка. А из 10 человек выборки не сделаешь :D
помогает определить pain points, найти неэффективные шаги в процессе и выбрать roadmap features для приоритизации. Поэтому я совсем не понял комментарий о том, что надо понимать зачем (с какой целью) вы строите CJM перед тем как строить.
Описание цели в начале важно для поддержания фокуса, чтобы все в команде понимали, для чего мы сейчас тратим время и куда хотим прийти.
Возможно, сам CJM от этого не поменяется, но это позволит нам остановиться при сборе данных, когда уже достаточно. Или быстро сменить опрашиваемых респондентов / сменить скрипт общения. Потому что мы делаем не просто CJM по всем стандартам, а решаем одну из сотен проблем, и CJM тут просто как название для достаточно объемного инструмента
Привет Игорь ? А что ты считаешь проектом? Что-то между большой фичей и новой вертикалью?
Потому что отчасти даже согласен с тобой, чем больше проектов/вертикалей внутри одного бизнеса, тем хаотичнее становится управление
А альтернатива кроссфункциональной продуктовой группе — стандартная разбивка по отделам с выставлением приоритетов для фичей внутри каждого проекта? Или есть еще варианты?
Я часто встречаю путаницу между маской и placeholder
А сам грешу тем, что все всплывающие окна называю popup, не разделяя их на alerts, pop up и dialog.
И спасибо, что с примерами с двух разных устройств, теперь можно ваш пост использовать как отдельную страницу Вики для команды)
Ты нашел, еще 10 человек не нашли. На любой продукт есть конкурет, который делает больше/лучше/дешевле. Но я, допустим, первый раз про этот сайт услышал, до этого ILovePDF юзал)
Тут работает то же правило, что и при создании доступной среды в городе
Делая удобнее среду для колясочников, вы одновременно делаете лучше и для мам с колясками, и для людей на велосипедах и самокатах, и для новых московских роверов 🫡
Тоже самое и с интерфейсами
Интересная статья была про слак, где команда делала инклюзивный дизайн, и в процессе фиксанула много UX микробагов, на которые до этого внимания не обращали. И одновременно работу с клавиатурой улучшили на порядок
Там же выводы написаны под каждым пунктом
Вы из тех, кто не признает на Хабре никаких публикаций кроме «как мы запустили дум на холодильнике»?
Получилось?
Я как раз последние пару недель активно занимаюсь созданием variables в фигма и думаем, как будем это цеплять к проду
Я редко пользуюсь персонами, особенно при создании Масс Маркет продуктов
У меня есть список работ (Jobs), которые я считаю приоритетными и ридерживаюсь их при выборе респондентов, создании вопросов или проектировании сервисов.
Но в общем то да, CJM делается чаще всего не для всех, а для какого то сегмента, а каким инструментом мы будем обозначать сегменты это уже другой топик для обсуждения)
Вот эти особенности кто в вашем городе & кому удобно приехать лично родились только после того, как мы опросили тех, кто отказался и кто прошел собесы. Ну и такая разбивка намного детальнее, чем прошел/отказался, потому что респондентов у нас не 200, а не больше 10 было. Чем больше определяющих факторов мы ставим, тем меньше наша выборка. А из 10 человек выборки не сделаешь :D
,
Описание цели в начале важно для поддержания фокуса, чтобы все в команде понимали, для чего мы сейчас тратим время и куда хотим прийти.
Возможно, сам CJM от этого не поменяется, но это позволит нам остановиться при сборе данных, когда уже достаточно. Или быстро сменить опрашиваемых респондентов / сменить скрипт общения. Потому что мы делаем не просто CJM по всем стандартам, а решаем одну из сотен проблем, и CJM тут просто как название для достаточно объемного инструмента
Благодарю ?
Привет Игорь ?
А что ты считаешь проектом?
Что-то между большой фичей и новой вертикалью?
Потому что отчасти даже согласен с тобой, чем больше проектов/вертикалей внутри одного бизнеса, тем хаотичнее становится управление
А альтернатива кроссфункциональной продуктовой группе — стандартная разбивка по отделам с выставлением приоритетов для фичей внутри каждого проекта? Или есть еще варианты?
Я хоть и не тестировщик/разработчик, но очень понравилась статья, лайк ?
Я часто встречаю путаницу между маской и placeholder
А сам грешу тем, что все всплывающие окна называю popup, не разделяя их на alerts, pop up и dialog.
И спасибо, что с примерами с двух разных устройств, теперь можно ваш пост использовать как отдельную страницу Вики для команды)
Поправил