Комментарии 8
Как выглядит разработка софта на самом деле
юстировка сбилась
Матрица DFV лишь показывает где находится сильное продуктовое решение.
А вот как идти к нему, (и идти ли вообще), решает каждая продуктовая команда уже самостоятельно.
Поэтому, в некоторых командах могут быть перекосы в любую сторону, по многим причинам. Но тогда логичный вопрос, остается ли это решение всё еще сильным? Или это просто такой компромисс?
Собственно мы сейчас находимся на ресурсы, который есть живое подтверждение, уверен что их «дизайнеры» тоже «всегда пытались внедрить в продукт максимальное количество удобных функций». Проблема только в том что они понятия не имеют что это такое. Так что «отпилить все лишнее» в этой ситуации часто спасает положение и не дает сделать хуже.
Конечно, я не отрицаю, что бывают где то клевые дизайнеры, но в текущей ситуации они могут эффективно работать только при наличии супер грамотного руководителя проекта.
Безусловно, чтобы быть дизайнером нужно понимать предметную область, иначе, невозможно создать интерфейс для того, что не понимаешь сам. Если говорим о понимании дизайнером разработки на том же уровне, что и разработчик, то это как минимум довольно дорогое удовольствие, поскольку такой специалист будет стоить дороже дизайнера и разработчика вместе взятых) О тех, кто «возомнил себя „дизайнерами“» - возможно вы просто сталкивались с начинающими специалистами. И в этом нет ничего плохого, все мы когда-то начинали и многого не знали. В такой ситуации, проблема решается так же, как и для любой другой профессии: уровнем задач и объема контроля за выполнением. С ростом специалиста задачи сложнее и контроля за процессом меньше. Раз уж речь зашла о ресурсе, на котором мы находимся, то это странно, дизайнеру не понимать, что значит удобно. Прямая обязанность дизайнера - делать удобно, точно также как и разработчика - делать так, чтобы система работала. В статье, я говорил о том, что инструмент следует применять как раз для того, чтобы не отпилить все важное в угоду срокам. А для этого важна коммуникация в команде. Потому что ни дизайнеры, ни разработчики не работают в вакууме. Это команда. В которой роль руководителя напрямую влияет на качество продукта.
Спасибо за статью, добавлю немного от себя. Когда в просчете модели Кано очень много результатов то их довольно долго просчитывать.
Для таких случаев поделюсь ссылкой на Калькулятор модели Кано
https://kartashev.me/kano-calculator/
Надеюсь кому-то поможет так же как и мне помог :)
Как UX/UI-дизайнеру достичь взаимопонимания с разработчиками и проджектами: комбинируем UX-фреймворки