Спасибо за комментарий и ссылку. Классические maturity-модели (включая NN/g) действительно описывают UX-зрелость на уровне компании: процессы, роли, лидерство и стратегию — это прямо отмечено в статье (раздел «продуктовый конструктор, а не модель из учебника»).
Термин «UX-зрелость продукта» здесь используется прикладно: речь не про «самостоятельную зрелость продукта в вакууме», а про уровень внедрения и устойчивости UX-практик внутри конкретного продуктового контура/команды.
Почему так:
объект управления — конкретный продукт/команда, а не компания целиком;
внутри одной организации уровень внедрения UX-практик может быть неравномерным: где-то это «гигиена», где-то — «лидерский» уровень, и управленческие действия нужны разные;
это не попытка спорить с NN/g, а локальная операционализация: как именно в данном контуре принимаются решения, как работает взаимодействие с пользователями и знаниями, что развивать дальше.
Если формулировать строго терминологически, ближе будет «зрелость UX-практик в продуктовой команде» или «уровень UX-интеграции в продукте» — смысл тот же, просто меньше неоднозначности вокруг слова «продукт».
Здравствуйте. Понимаем, что это может приносить неудобства. Устанавливать обновления автоматически технически возможно не на всех устройствах. С точки зрения производителя вашего телефона, RuStore — это сторонний источник, а не дефолтный стор. В таком случае для установки или обновления любого приложения нужно дополнительное подтверждение, это требование и стандарт системы Android
Привет, спасибо) Про приоритезацию в целом описала в статье, алгоритм простой: - если проблема высококритичная и находится в сценарии, на котором завязаны важные для продукта метрики, ее стараются забрать в работу чем раньше, тем лучше. И далее по убыванию. - Проблема крепится к существующей продуктовой задаче (в редких случаях как самостоятельная задача). Остальное уже в рамках работы над фичей по RICE.
То есть при таком подходе конфликтов практически не возникает. Мы знаем, что продукт знает о проблеме, и чем она ему потенциально "грозит", продукт - взвешивает и, исходя из своих ресурсов, решает в какой очередности что сможет взять. Не берут в работу скорее в случаях, когда поняли, что результаты исследования совсем грустные, и имеет смысл вообще отказаться от реализации.
Ситуации, когда есть сомнения в степени критичности проблемы - есть всегда у всех, мне кажется. Если проблема донесена корректно, но все-равно остались сомнения - а/б, количественная валидация или аналитика
Спасибо за комментарий и ссылку. Классические maturity-модели (включая NN/g) действительно описывают UX-зрелость на уровне компании: процессы, роли, лидерство и стратегию — это прямо отмечено в статье (раздел «продуктовый конструктор, а не модель из учебника»).
Термин «UX-зрелость продукта» здесь используется прикладно: речь не про «самостоятельную зрелость продукта в вакууме», а про уровень внедрения и устойчивости UX-практик внутри конкретного продуктового контура/команды.
Почему так:
объект управления — конкретный продукт/команда, а не компания целиком;
внутри одной организации уровень внедрения UX-практик может быть неравномерным: где-то это «гигиена», где-то — «лидерский» уровень, и управленческие действия нужны разные;
это не попытка спорить с NN/g, а локальная операционализация: как именно в данном контуре принимаются решения, как работает взаимодействие с пользователями и знаниями, что развивать дальше.
Если формулировать строго терминологически, ближе будет «зрелость UX-практик в продуктовой команде» или «уровень UX-интеграции в продукте» — смысл тот же, просто меньше неоднозначности вокруг слова «продукт».
Перевод NN/g по ссылке полезный — спасибо.
Здравствуйте. Понимаем, что это может приносить неудобства. Устанавливать обновления автоматически технически возможно не на всех устройствах. С точки зрения производителя вашего телефона, RuStore — это сторонний источник, а не дефолтный стор. В таком случае для установки или обновления любого приложения нужно дополнительное подтверждение, это требование и стандарт системы Android
Привет, спасибо)
Про приоритезацию в целом описала в статье, алгоритм простой:
- если проблема высококритичная и находится в сценарии, на котором завязаны важные для продукта метрики, ее стараются забрать в работу чем раньше, тем лучше. И далее по убыванию.
- Проблема крепится к существующей продуктовой задаче (в редких случаях как самостоятельная задача). Остальное уже в рамках работы над фичей по RICE.
То есть при таком подходе конфликтов практически не возникает. Мы знаем, что продукт знает о проблеме, и чем она ему потенциально "грозит", продукт - взвешивает и, исходя из своих ресурсов, решает в какой очередности что сможет взять.
Не берут в работу скорее в случаях, когда поняли, что результаты исследования совсем грустные, и имеет смысл вообще отказаться от реализации.
Ситуации, когда есть сомнения в степени критичности проблемы - есть всегда у всех, мне кажется. Если проблема донесена корректно, но все-равно остались сомнения - а/б, количественная валидация или аналитика