Продуктовое мышление что это
Почему “продуктовое мышление” станет новым прорывом в UX-дизайне?
Жизнь слишком коротка, чтобы разрабатывать никому не нужные вещи…
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Размышляя об опыте взаимодействия, мы часто представляем себе продукт с простым, красивым и легким в использовании набором функций, которые делают жизнь пользователя проще. Но на самом деле функции — это лишь небольшая, хрупкая часть продукта. Они представляют собой лишь несколько предлагаемых путей решения проблемы пользователя. “Продуктовое мышление” — это мышление такими категориями, как проблемы пользователя, работы, подлежащие выполнению, цели и доходы компании.
В основе опыта взаимодействия лежит не набор функций, а задача, для выполнения которой человек использует продукт. Основа пользовательского опыта компании Uber —заказ такси без заморочек в любое время. Обратный отсчет, показывающий точное время до прибытия такси, — это функция, расширяющая опыт взаимодействия. Но продукт Uber будет работать и без этой функции. Сама же функция обратного отсчета в отрыве от продукта (гарантированного круглосуточного вызова такси ) существовать не может. Взаимоотношения между функцией и продуктом односторонние: функции без продукта не работают. Именно поэтому дизайнеры должны в первую очередь думать о продукте.
“Мыслите продуктами, а не функциями”
Выявите задачи, для выполнения которых используется продукт
У продукта есть основной опыт взаимодействия, который, по сути, является причиной существования продукта. Этот опыт взаимодействия удовлетворяет нужды пользователя или решает его проблемы. Благодаря этому, продукт становится значимым и представляет определенную ценность. Если проблемы не существует, или решение не соответствует проблеме, продукт теряет свою значимость, и никто не будет им пользоваться; а это, в свою очередь, ведет к провалу продукта. Неправильное решение еще можно исправить, а вот с несуществующей проблемой уже ничего не сделаешь. Так как же нам убедиться, что мы схватили за хвост настоящую проблему? Увы, быть уверенными на 100% не получится, но мы можем существенно минимизировать риск, наблюдая и беседуя с людьми. Следовательно, нам удастся выявить проблему и создать решение, которое действительно нужно пользователям.
“Клиент и не должен знать, чего ему хочется. Это не его работа”— Стив Джобс
Клей Кристенсен, к примеру, однажды пытался поднять продажи молочных коктейлей. Он испробовал всё: делать их слаще, расширить линейку вкусов, немного увеличить размер стаканов. Ничего не давало результатов, пока он не начал наблюдать за клиентами. Он обнаружил, что задача, для решения которой покупался молочный коктейль, была — сделать утреннюю поездку на работу менее скучной. Большим преимуществом молочного коктейля было то, что он, благодаря своей густоте, дольше “пьется” и создает ощущение полного живота. В этом была настоящая проблема, а клиенты понятия об этом не имели. В итоге Кристенсен придумал делать коктейли еще гуще, что увеличило продажи. http://ipony.de/?p=3495
“Влюбляйтесь в проблему, а не в какое-то конкретное решение” — Лаура Хавьер
Мыслите продуктами и создавайте правильные функции для правильных людей
Продуктовое мышление помогает создавать успешные функции. Определив проблемы, c которыми борется продукт, мы отвечаем на вопрос “почему мы создаем этот продукт?”. Определившись с целевой аудиторией “у кого есть подобная проблема?” и с решением “как мы это осуществим?”, мы получим достаточно оснований для создания новой функции. А постановка цели поможет нам измерить будущий успех.
Соответствие между решением и проблемой
Продукт становится значимым, когда предложенное решение соответствует выявленной проблеме. Это решение описывает способы, которыми проблема может быть решена. Таким образом, уровень соответствия между решением и проблемой определяет основной опыт взаимодействия с продуктом. Конкретные функции расширяют этот опыт и поддерживают основное взаимодействие, но не могут его заменить.
Проектирование взаимодействия (interaction design) и визуальный дизайн (visual design) могут сделать продукт красивым, простым в использовании, радостным или даже выделяющимся среди конкурентов, но они не способны сделать его значимым. Именно поэтому должный уровень соответствия между проблемой и решением так важен для создания успешного продукта.
Определение продукта
В ходе “продуктового мышления” UX-дизайнеры должны быть в состоянии ответить на следующие вопросы: Какую проблему мы решаем? (Проблема пользователя). Для кого мы это делаем? (Целевая аудитория). Почему мы это делаем? (Видение). Как мы это делаем? (Стратегия). Чего мы хотим достичь? (Цели). Только после этого имеет смысл переходить к конкретике (функции).
Сила продуктового мышления
Благодаря продуктовому мышлению, дизайнеры имеют возможность создавать правильные функций для правильных людей.
ПМ помогает понять опыт взаимодействия продукта в целом, а не только в рамках проектирования конкретных функций.
ПМ повышает вероятность решения реальных проблем пользователей и снижает риск создания никому не нужного продукта.
ПМ дает нам силу принимать правильные решения, когда дело доходит до создания функций.
“Создавать функции просто. Создавать правильные функции для правильных людей — вот это вызов!”
Продуктовое мышление позволяет UX-дизайнерам задавать правильные вопросы, создавать правильные функции и более эффективно общаться со всеми заинтересованными в проекте людьми. Оно позволяет дизайнерам говорить “нет” и сомневаться при добавлении новых функций.
Когда поступает запрос на новую функцию, или когда кто-то рассказывает идею нового продукта, дизайнеры могут задать правильные вопросы прежде, чем рисовать вайрфреймы или раскрашивать макеты. “Вписывается ли функция в продукт?” — “Решает ли она реальную проблему клиента?” — “Людям это нужно или просто хочется? Давайте сначала разберемся!” Благодаря этому продукт будет подтянутым и эффективным.
Заключение
Продуктовое мышление обеспечивает создание дизайнерами правильных функций для правильных людей, а также решение реальных пользовательских проблем. Такое мышление дает нам силу принимать правильные решения и является основой создания успешных продуктов, реально необходимых пользователям. Продуктовое мышление устанавливает плодотворные отношения между product-менеджментом и UX-дизайном, а, следовательно, ведет к созданию более сильных продуктов. Именно поэтому продуктовое мышление станет новым прорывом в UX-дизайне.
Если вам понравилась статья и перевод, дайте нам знать — нажмите кнопку Recommend
А если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Видеокурсы и практика по дизайну интерактивных систем: ux/ui, веб-дизайн и бренд-дизайн
Вас ждет плотная проектная практика по анимации интерфейсов, дизайну сайтов, а также мобильных и веб-приложений. Под руководством наставников в стиле «смотри и повторяй»!
Breezzly — это среда для тренировки digital-навыков. Здесь вы встретите комплекты видеокурсов в актуальных инструментах интерактивного дизайна, среди них Figma, Principle и Invision Studio. А каждый проект — это живой кейс с историей, собранной по горячим следам!
Продуктовое мышление. Что это и как его развивать
О пользе продуктового мышления сейчас можно услышать из каждого утюга. Действительно, оно необходимо не только менеджерам продуктов, но и всей команде. Тогда мы действительно будем делать качественный продукт, который обладает максимальной ценностью для нашего клиента.
Однако мало где можно прочесть, что это и в чем проявляется.
Ниже хочу изложить свое видение этого процесса.
На одном из митапов у меня спросили: «Как можно протестировать есть у меня продуктовое мышление или нет?» И я подумал, что статью можно рассматривать как диагностический инструмент. Читая каждый пункт, постарайся честно ответить на вопрос: «Есть это у меня или еще есть над чем поработать?»
1. Мысли продуктами, а не фичами
Ключевая задача продукта — это нести ценность пользователю. И кажется, что добавление отдельной классной фичи увеличит эту самую ценность. Однако целое — это всегда больше, чем сумма составляющих его компонентов.
Когда мы что-то добавляем важно помнить, что это повлияет на весь продукт.
Вот неполный список вопросов, который стоит себе задать прежде, чем делать ту или иную фичу.
2. Вы не ваша целевая аудитория
Безусловно есть исключения, когда вы делаете продукт для разработки продуктов, но в большинстве случаев это не так.
В психологии есть такой механизм как проекция. Это когда мы переносим свои чувства, мысли, желания на другого человека. Поэтому, как эмпатию не включай, у вас все равно будут разные ценности, взгляды на жизнь, боли и задачи.
В результате, если руководствоваться принципом «Я думаю, что для них будет лучше это», мы будем делать продукт для себя. И это особенно забавно, когда команда бородатых мужиков пилит продукт для мам-одиночек 🙂
3. Исследуй
Чтобы сблизить картины мира нашу и пользователя, его нужно постоянно исследовать.
Концептуально есть 2 вида исследований:
4. Всё гипотеза
Чтобы не заблуждаться в том, что же нужно нашему пользователю, необходимо все свои предположения формулировать как гипотезу. А гипотеза подразумевает под собой долю сомнения и то, что это нужно проверить.
5. Экспериментируй
Тут нам в помощь пресловутый HADI-цикл.
За каждой гипотезой стоит потенциал роста. Поэтому, чем больше гипотез мы проверим, тем лучше. Пусть первые эксперименты будут синтетические, неправильные, «высосанные из пальца», тут главное начать, если еще не начали.
Очень полезный вопрос по результатам эксперимента, который способствует развитию продуктового мышления: «Что нам стало ясно, что до этого было неочевидно?».
Ключевые характеристики эксперимента, которые важно учитывать:
6. Пользователь не тупой, он такой, какой есть
Нам кажется, что в нашем сервисе все так понятно и очевидно. А пользователи почему-то не понимают, что нужно нажать на эту кнопку и ходят кругами, а потом вообще уходят.
Можно, конечно, назвать их тупыми, только нас это никуда не приведет. При разработке приложения, рассчитывай, что им будут пользоваться и младенцы, и бабушки в 90 лет.
7. Лояльно воспринимай фидбек пользователей
Нам очень неприятно, когда кто-то критикует нашу работу, на которую мы потратили столько сил. Так устроена наша психика. Автоматически включается механизм психологической защиты – обесценивание.
Когда смотришь на обстоятельный отзыв с одной звездой, первое что приходит на ум – «сам дурак». Но опять же, такой путь никуда не ведет. Представь, пользователь сел и потратил часть своей жизни на то, чтобы сообщить вам о своих болях. Тут лучше выдохнуть, сказать ему «спасибо», а затем трезво перечитать отзыв и отделить в нем зерна от плевел.
8. Будь открыт новому
Опять же, наша психика не любит перемены. И поэтому мы очень профессионально можем найти 10 причин почему новая идея — бред. Причем, чем более интеллектуально развит человек, тем на более высоком уровне работают защиты.
Есть простая фраза – «А давай попробуем!», которая позволяет двигаться вперед. Причем, она хорошо подходит как для предложения что-то сделать, так и для ответа на предложение.
9. Отрицательный результат – тоже результат
Пункт очень избитый, нам его твердили с детства. Но я настолько часто слышу «зря делали» по поводу какого-то фейла, что решил его добавить в список.
10. Отказывайся от неэффективных фич
Неэффективные фичи засоряют интерфейс, удлиняют регресс, нагружают техподдержку и т.д.
Звучит вполне логично, но для меня это один из самых сложных пунктов. Так больно отказываться от того, что делали долго, вложили много сил и энергии. И кажется, что вот-вот и все взлетит, а оно все никак…
Список можно продолжать.
Напишите в комментариях, что еще развивает продуктовый майндсет, с вашей точки зрения.
Продуктовое мышление против проектного мышления
16 Сен 2020
Привет, дорогие друзья!
Многие ли из вас задумывались: в чем разница между продуктовым и проектным мышлением? Какого будет правильнее придерживаться в той или иной ситуации? Возможно ли их вообще совместить?
Читайте об этом в нашей новой статье!
Одна из самых трудновыполнимых задач, с которой сталкивается менеджер по продукту (или организация, если уж на то пошло), — это попытка сменить культуру мышления с уровня проекта на уровень продукта.
Проектное Мышление
Проектное мышление распространено довольно широко. Многие люди, особенно те, кто занимаются разработкой программного обеспечения, посвятили большую часть своей карьеры проектам и управлению проектами. Крупные организации часто имеют проектные офисы, ориентированные исключительно на управление проектами. Это неудивительно, ведь управление проектами существует уже очень давно.
Так что же такое проектное мышление?
В центре внимания проектного мышления находится поставка (delivery). Это может быть поставка определенных функций или программного обеспечения, или действительно поставка чего-либо физического, от самолетов до домов. И поскольку основное внимание уделяется поставке, основное измерение проводится на временном графике. Управление проектами в особенности фокусируется на результаты (output): важно измерять, насколько точно мы смогли заранее оценить график, а затем достичь запланированных результатов в соответствии с этим графиком. Успех в значительной степени определяется тремя этапами: вы заблаговременно берете все спецификации, устанавливаете график с вехами на протяжении всего пути, а затем поочередно достигаете все вехи.
Продуктовое Мышление
Продуктовое мышление использует принципиально иной подход. Вместо того чтобы сосредотачиваться на результатах, продуктовое мышление фокусируется на показателях или конечных результатах (outcome). (На русском языке output и outcome переводятся одинаково, как результат, но в английской практике outcome – это последствия output, например, output – созданный цементный завод, а outcome – сколько тонн цемента этот завод создает – примечание редактора).
Это существенное отличие от проектного мышления. Вместо того чтобы сосредоточиться на графике и датах, мы фокусируемся на цели, которую хотим достичь, или на работе, которую нужно сделать. Поскольку мы ориентируемся на показатели (outcome), а не на результат (output), гораздо труднее установить временные ограничения вокруг поставки, по крайней мере, заранее. В первую очередь потому, что мы не обязательно знаем, как мы собираемся достичь цели заранее.
Этот тип мышления может показаться довольно неординарным для людей, которые потратили много времени, сосредоточенного на проектах и управлении проектами. Многие люди испытывают дискомфорт из-за неопределенности, связанной с отсутствием структурированных графиков и расписаний, которые они могут отслеживать на регулярной основе.
Преимущества
Итак, каковы преимущества отказа от временных рамок проекта в пользу сосредоточения внимания на показатели (outcome)?
Прежде всего, нет ничего важнее показателей, к которым мы движемся. Главное преимущество продуктового мышления (product mindset) заключается в том, что мы гарантированно получаем более эффективное достижение показателей.
Имея проектное мышление, мы с самого начала предполагаем, что уже знаем, как достичь желаемых показателей (outcome). Исходя из этого предположения, мы создаем план и график проекта, полный требований и основных этапов, а затем приступаем к выполнению этого плана. Если мы правы, и то, что мы изначально предполагали, оказывается правильным решением, тогда все замечательно. Мы просто выполняем план и достигаем показателей (outcome).
Но что, если мы изначально ошибались? Что, если решение, которое мы определили, не приведет к тем показателям, на который мы надеялись?
Вот где проектное мышление приводит нас к разного рода неприятностям. Как только мы приводим план в действие, может быть очень трудно, особенно в крупных организациях, развернуться и внести изменения в сделанном. После того, как даты были установлены, и все согласились с планом, это обычно то, что застревает в головах каждого, несмотря на стремление учиться и адаптироваться к изменениям. И если мы в конечном итоге пропустим финальную дату, это может вызвать невероятные проблемы для команд и бизнеса.
С продуктовым мышлением мы способны учиться и адаптироваться по ходу дела. Мы не устанавливаем даты и вехи, а скорее сосредоточены на обучении и достижении показателей. Если что-то не получается или клиенты плохо реагируют на что-то одно, мы можем принять это во внимание, адаптироваться и все еще работать над показателями, которые мы планировали, не разрушая красивый план, который является всеобщим фокусом.
Самое главное, когда возникают проблемы (и не обманывайте себя, они всегда будут возникать), продуктовое мышление позволяет нам учиться и адаптироваться, а также оставаться сосредоточенными на показателях, которые мы пытаемся достичь. Напротив, когда возникают проблемы и мы застреваем в проектном мышлении с его фокусом на расписании, мы часто втягиваемся в бесконечные совещания, пытаясь определить, почему наши первоначальные предположения были ошибочными и как нам обратно встроиться в график. Это в конечном счете приводит к жертвам в качестве, отсутствию баланса между работой и личной жизнью, и не достижении показателей, на которых мы сфокусировались (независимо от того, правильно ли их все еще достигать).
На примере проекта
Мы говорили о многих концепциях, поэтому давайте рассмотрим некоторые примеры, чтобы лучше проиллюстрировать эти моменты.
Отличным примером проекта является строительство дома. Мы с женой построили наш дом в прошлом году. Мы прошли через весь процесс планировки, выбирая все отделки и детали в доме, а затем заплатили большие суммы денег, чтобы начать строительство.
Когда мы начали, наш менеджер по строительству дал нам предполагаемую дату окончания строительства. Это было примерно через 6 месяцев. Очевидно, что есть много вещей, которые входят в эту оценку, и часто возникают вещи, которые отбрасывают даты, но поскольку строительство дома — это очень повторяемый процесс с определенными входными данными, хороший менеджер по строительству может смотреть на план, неделю за неделей, и определять, когда ожидать завершение работ.
Наш дом был готов с запозданием примерно на неделю, что, по-моему, похоже на отличный результат. Одна из сделок была задержана, так что все было отложено на несколько дней, что имело некоторые последствия. Но это нормально, ибо ожидаемо.
Когда речь заходит об этих типах строительных проектов, они в значительной степени ориентированы на управление проектами. Каждый знает, что нужно сделать, и держать людей в графике — это настоящий ключ, тем более что это касалось не только самого дома, но и всего остального.
На примере продукта
Но работает ли этот вид управления проектами везде? Нет.
Как бы нам ни хотелось думать о разработке программного обеспечения как о некой конструкции, это не верно. Четко определенные планы и работы невозможно применить к разработке продукта, как бы мы ни старались. Несмотря на большой комфорт от четко определенных временных рамок, это не то, как мы должны выполнять разработку продукта.
В продукте, над которым я работал, была ключевая проблема, которую я определил и знал, что мы должны решить, чтобы продолжать расширять нашу аудиторию и охватывать дополнительных пользователей. Традиционный подход к этому будет заключаться в сборе требований, определении объема работ, а затем создании функций. Но, к большому ужасу многих людей в моей организации, я не придерживаюсь такого типичного подхода.
Как только я понял проблему, я погрузился в исследование решений, от создания функций до интеграции программного обеспечения сторонних производителей. Когда я это сделал, мне стало ясно, что решение состоит в том, чтобы ничего не создавать. Вместо того чтобы создавать новые функции или интегрировать чужое программное обеспечение (в данном случае это было портфолио для студентов), решение состояло в том, чтобы изменить то, что мы просили студентов делать. Вместо того чтобы сосредоточиться на инструменте «портфолио для студентов», мы могли бы просто попросить их создать части портфолио, а затем использовать любое программное решение, которое они захотят, чтобы продемонстрировать свою работу. Выгоды для всех будут значительными. Студенты будут контролировать свое портфолио, и мы не будем привязаны к созданию программного обеспечения или использованию какого-либо конкретного поставщика.
Мы бы никогда не пришли к такому решению с проектным мышлением. Это решение возникло потому, что я был сосредоточен на проблеме и показателях (получение дополнительных пользователей в нашем приложении), а не на создании следующей функции.
Этот тип результата обычно является результатом продуктового мышления. И он может прийти в любой момент на этом пути. В моем примере выше мы избегали делать какую-либо работу по развитию. Но часто может потребоваться несколько прототипов дизайна, чтобы понять, что будет работать. Или мы можем проделать небольшой объем работы по разработке, чтобы узнать, какие функции действительно приведут к желаемому результату. Независимо от того, где конкретно в процессе мы учимся, главное, что мы учимся в дороге, а не решаем курс заранее и следуем плану проекта.
Правильный выбор
Так как же нам это сделать? Как сохранить фокус на продукте?
Все продукты и управление ими предполагают определенный уровень управления проектами. Мы должны продолжать двигаться вперед, и (к сожалению) нереалистично предполагать, что мы можем работать в среде, где наши заинтересованные стороны и партнеры не будут ожидать каких-то дат или обязательств.
Главное — принимать обязательства и проектные планы только в тот момент, когда мы уверены, что можем сделать это. Поэтому вместо того, чтобы заранее выбрать определенный путь, мы берем на себя обязательства, как только проверим, что надо сделать, и действительно поймем, что для этого потребуется. Часто на практике это один или два рабочих спринта. Это может показаться действительно запоздалым процессом, но именно в этот момент оценки и планы действительно могут что-то значить. Марти Каган в своей книге “Inspired: How to Create Tech Products People Love”, называет этот тип обязательств “обязательством высокой целостности”. Мы даем командам время, чтобы сделать правильные открытия и исследования, прежде чем просить обязательств.
И мы также должны помочь другим осознать преимущества продуктового мышления. Есть причина, по которой многие люди просят даты и сроки. Отчасти из-за старых привычек. Но бывают моменты, когда это необходимо для бизнеса и бюджета. Поэтому нам нужно понять, в чем заключается работа временной шкалы в этих случаях. Если это поможет продать продукт, мы должны переключить внимание с конкретных фичей на историю более высокого уровня. Если речь идет об управлении риском, возможно, нам нужно помочь людям понять, что реальный риск заключается не в том, чтобы пропустить дату, а в том, чтобы полностью провалиться в создании ценности, которую мы пытаемся поставить.
В конце концов
В конце концов, главная цель разработки продукта – создать ценность для пользователей и клиентов. Однако в большинстве случаев мы не знаем точно, что именно принесет эту ценность. Думать, что мы можем предложить правильные решения с четким представлением бюджета за год вперед, довольно нереалистично.
В то время как проектное мышление фокусируется на разработке решений заранее и последующей реализации в соответствии с графиком, продуктовое мышление сохраняет фокус на показателях. Это предполагает некоторый уровень комфорта с неопределенностью и обучением, что может быть довольно трудно. Но если мы хотим достичь правильных показателей, а не просто своевременный результат, то выбор действительно падает на продуктовое мышление.
Для тех, кто хочет разобраться с продуктовом мышлении у нас есть курсы по Agile и дизайн-мышлению.
• На курсе по Agile вы узнаете, что такое гибкое мышление, Agile-трансформация, Scrum и Kanban. Каждый месяц проходит тренинг в открытом формате для всех желающих в онлайн или офлайн.
• На курсе по дизайн-мышлению вы узнаете, как проектировать востребованные продукты и услуги.