Вы верно подметили, CJM и Eevent stormimg рассматриваются как два альтернативных инструмента для снятия текущего процесса (если он был) или описания целевого процесса. Соответственно, бэкбоном для USM могут быть как точки контакта из CJM, так и domain events (оранжевые карточки) из Event storming'а. Однако, переносить их в исходной формулировке я бы не рекомендовал. Для написания пользовательских историй существуют полезные шаблоны.
В данном случае скорее важны не инструменты, а сама последовательность: понять текущий процесс (если он был до вас) → прикинуть целевой процесс → описать пользовательские истории целевого процесса. Для первых двух пунктов может подойти как CJM, так и Event storming. Но ES хорош тем, что некоторые карточки из него могут стать пререквизитом для USM и без изменений перекочевать в него (схематично).
Что касается перехода от требований к макетам, то этот процесс до конца невозможно формализовать, потому что пользовательские истории с макетами могут состоять во всех возможных видах связи: один к одному, один ко многим, многие ко многим.
Могу сказать точно, что в нашей работе мы чаще всего переходим к макетам именно после USM. А вообще, в процессе синтеза всех этих артефактов аналитики на практике у вас точно начнет вырисовываться примерный перечень и содержание макетов еще до начала их отрисовки :)
Схематизацию требований (USM, CJM, итд) делаю в Miro. Журнал проектирования в данный момент удобнее всего вести в Notion. Первые наброски карт экранов и самих экранов (Breadcrumbs и Fat marker sketches) проще всего сделать на бумаге. Дальнейшую сборку черновых и чистовых макетов веду в Figma, дополнительных инструментов для этого не использую. Раньше для наглядной визуализации определенной детали взаимодействия использовал Principle, но в последнее время в этом нет необходимости, да и Фигма подтянулась в вопросе прототипирования.
Ваша ассоциация верна) В сложных проектах мозг действительно не справляется со всей поступающей информацией. Поэтому я, собственно, и поделился личным опытом освобождения когнитивного ресурса в данной статье.
Приятно видеть, что практики пересекаются)
Вы верно подметили, CJM и Eevent stormimg рассматриваются как два альтернативных инструмента для снятия текущего процесса (если он был) или описания целевого процесса. Соответственно, бэкбоном для USM могут быть как точки контакта из CJM, так и domain events (оранжевые карточки) из Event storming'а. Однако, переносить их в исходной формулировке я бы не рекомендовал. Для написания пользовательских историй существуют полезные шаблоны.
В данном случае скорее важны не инструменты, а сама последовательность: понять текущий процесс (если он был до вас) → прикинуть целевой процесс → описать пользовательские истории целевого процесса. Для первых двух пунктов может подойти как CJM, так и Event storming. Но ES хорош тем, что некоторые карточки из него могут стать пререквизитом для USM и без изменений перекочевать в него (схематично).
Что касается перехода от требований к макетам, то этот процесс до конца невозможно формализовать, потому что пользовательские истории с макетами могут состоять во всех возможных видах связи: один к одному, один ко многим, многие ко многим.
Могу сказать точно, что в нашей работе мы чаще всего переходим к макетам именно после USM. А вообще, в процессе синтеза всех этих артефактов аналитики на практике у вас точно начнет вырисовываться примерный перечень и содержание макетов еще до начала их отрисовки :)
Схематизацию требований (USM, CJM, итд) делаю в Miro. Журнал проектирования в данный момент удобнее всего вести в Notion. Первые наброски карт экранов и самих экранов (Breadcrumbs и Fat marker sketches) проще всего сделать на бумаге. Дальнейшую сборку черновых и чистовых макетов веду в Figma, дополнительных инструментов для этого не использую. Раньше для наглядной визуализации определенной детали взаимодействия использовал Principle, но в последнее время в этом нет необходимости, да и Фигма подтянулась в вопросе прототипирования.
Ваша ассоциация верна) В сложных проектах мозг действительно не справляется со всей поступающей информацией. Поэтому я, собственно, и поделился личным опытом освобождения когнитивного ресурса в данной статье.