"PO конечно должен проводить исследования" - это основное, что я пытался донести в статье. Потому что в корпоративной разработке аналитик работает и за продуктовнера, и за дизайнера. А ситуация в статье описана прямо противоположная административной бюрократии и избыточности артефактов.
Я не участвовал в проектировании описанных вами интерфейсов и не знаю причин, которые побудили разработчиков вносить подобные изменения. Но могу порассуждать о факторах, которые могли оказать влияние на принятые решения:
Унификация дизайна между разделами системы.
Влияние отдела маркетинга. Если произошел ребрендинг, или выпустили обновленный фирменный стиль, все разделы системы подлежат адаптации под него. У маркетологов свои причины на такие изменения.
Смена команды разработчиков.
Я согласен с вами в том, что а) глобальное изменение ранее устоявшегося дизайна должно быть опциональным: пользователю необходимо предоставлять выбор между старым и новым интерфейсом. б) непреднамеренная потеря функциональности интерфейса при таких изменениях недопустима.
В то же время из опыта внедрения я знаю, что любые изменения в привычных решениях всегда изначально тяжело воспринимаются любым человеком. Иногда нужно дать им время (шанс) на раскрытие потенциала полезности.
Что касается недостаточной информированности после действия пользователя: этого точно можно было избежать, следуя советам из моей статьи.
У вас хорошо развито пространственное мышление! Предлагаю считать эту неточность акцентом на одну из мыслей в статье: проектировщику сложно самостоятельно угадать точку зрения пользователей.
"PO конечно должен проводить исследования" - это основное, что я пытался донести в статье. Потому что в корпоративной разработке аналитик работает и за продуктовнера, и за дизайнера. А ситуация в статье описана прямо противоположная административной бюрократии и избыточности артефактов.
Спасибо за обратную связь.
Добрый вечер, приведите аргументы, пожалуйста. Почему вы считаете, что работу аналитика или дизайнера нужно оправдывать?
Татьяна, спасибо за ваш комментарий.
Я не участвовал в проектировании описанных вами интерфейсов и не знаю причин, которые побудили разработчиков вносить подобные изменения. Но могу порассуждать о факторах, которые могли оказать влияние на принятые решения:
Унификация дизайна между разделами системы.
Влияние отдела маркетинга. Если произошел ребрендинг, или выпустили обновленный фирменный стиль, все разделы системы подлежат адаптации под него. У маркетологов свои причины на такие изменения.
Смена команды разработчиков.
Я согласен с вами в том, что
а) глобальное изменение ранее устоявшегося дизайна должно быть опциональным: пользователю необходимо предоставлять выбор между старым и новым интерфейсом.
б) непреднамеренная потеря функциональности интерфейса при таких изменениях недопустима.
В то же время из опыта внедрения я знаю, что любые изменения в привычных решениях всегда изначально тяжело воспринимаются любым человеком. Иногда нужно дать им время (шанс) на раскрытие потенциала полезности.
Что касается недостаточной информированности после действия пользователя: этого точно можно было избежать, следуя советам из моей статьи.
У вас хорошо развито пространственное мышление! Предлагаю считать эту неточность акцентом на одну из мыслей в статье: проектировщику сложно самостоятельно угадать точку зрения пользователей.