Инновации против постепенного улучшения | IxDF

Не все команды создают продукты в условиях крайне неопределенной ситуации или пытаются создать передовые новые функции. Многие постепенно совершенствуют существующие продукты и стараются делать это таким образом, чтобы не оттолкнуть большую существующую базу пользователей. Ни одна из этих задач не является особенно простой, и они часто требуют совершенно разных подходов к исследованию и проектированию. Давайте посмотрим, как все меняется в зависимости от целей команды.

Часто продуктовые команды, независимо от того, как гибкий они есть, у них нет четкого различия между «как проводить исследования для нового, инновационного продукта» и «как проводить исследования для существующего, успешного продукта с клиентами». Вы заметили, что мы сказали, что «продуктовые команды» не имеют такого различия. Обычно исследователи пользователей имеют очень хорошее представление о различных видах необходимых исследований, но, к сожалению, не всегда именно они принимают решения.

Причина, по которой в гибких средах ситуация еще хуже, заключается в том, что многие команды в значительной степени избавились от большой, специальной фазы «открытия», которая использовалась для раннего исследования новых продуктов или новых версий продуктов.

Поскольку этот этап произошел до того, как инженеры начали работу над продуктом, а часто и до менеджер по продукту начал писать требования, как правило, было больше времени на такие вещи, как контекстуальный запрос и глубокий этнографические исследования. Всегда ли это происходило? Нет, конечно нет. Но это было учтено в водопадном процессе и в организациях, которые верили в исследование пользователейв графике было заложено время для более глубоких исследований, чем вы часто видите сейчас в гибких средах.

Проведение ранних исследований потребности пользователя и проблемы, возникающие перед созданием продукта, очевидно, не мешают нам продолжать исследования после того, как мы выпустили продукт, и не освобождают нас от необходимости делать это. удобство использования тестирование на прототипы или дизайны. Однако, когда мы все работали по принципу водопада, мы выпускали новую версию, а затем начинали все заново с ранних исследований, часто изучая, как люди используют наш продукт, и находя все возможные способы его улучшения.

С другой стороны, с гибкими командами мы постоянно строит, постоянная доставкаи постоянно учусь. Как же тогда отличить фундаментальные исследования, которые обеспечивают большие, инновационные изменения, от тех, которые помогают нам выявить небольшие, постепенные улучшения? И действительно ли методы и методы, которые мы используем, настолько разные? Давайте узнаем от Лауры Кляйн, UX-дизайнера и автора Создавайте лучшие продуктыв этом видео!

Почему это важно

В компаниях, у которых уже есть существующие продукты или которые могут иметь более длительные временные горизонты для создания новых функций и внедрения новых продуктов, нам часто приходится балансировать время, которое мы тратим на различные виды исследований. Но более длительные и глубокие исследования могут стать проблемой для agile-команд, поскольку они не вписываются в один или два спринта.

Кроме того, может быть очень сложно проводить оба вида исследований одновременно, особенно если в agile-команде есть только один исследователь, что часто бывает. Проведение большого контекстного запроса или дневникового исследования может занять много времени, и если вы также ожидаете, что будете проводить его еженедельно тест юзабилити сессий или одновременно реализовать программу «Голос клиента», что может стать быстрым рецептом выгорания исследователя.

Во многом это похоже на любой вид раскола между основополагающими, порождающий исследования и более постепенные, оценочный исследовать. Иногда люди называют это исследованием проблемное пространство против исследования пространства решений. Это также похоже на исследования открытий и исследования доставки.

Важно помнить, как бы вы это ни называли, это то, что виды исследований, которые вы проводите, различаются в зависимости от того, что вы хотите изучить. Некоторые исследования просто более открыты, чем другие типы исследований, и этот тип раннего исследовательского исследования может оказаться гораздо сложнее интегрировать в agile-команду, особенно если команда практикует Scrum и все работают в рамках одно- или двухнедельных спринтов.

Как это исправить

К сожалению, не существует единого простого решения этой проблемы, но есть несколько разных подходов, которые вы можете использовать. Во многих случаях простое знание о существовании проблемы может помочь, потому что вы сможете поговорить о ней. разные временные горизонты исследования с вашей командой. Если владелец продукта хочет поработать над функцией, которая требует долгосрочных исследований, вы можете помочь ему сначала расставить приоритеты в отношении других, менее трудоемких функций, чтобы дать вам необходимое время.

Другой подход, иногда используемый более крупными организациями, называется так называемым Двухпутевой гибкий подход. В статье 2005 года Линн Миллер, тогдашний директор Пользовательский интерфейс Development at Alias писали о «взаимосвязанных параллельных направлениях проектирования и разработки». Позже, в 2012 году, Марти Кейган и Джефф Паттон назвали так называемую «двойную схватку», когда трек доставки и трек открытия будут работать параллельно, причем трек открытия будет проверять идеи новых продуктов, а затем передавать их в поставку.

Конечно, отделение открытия от доставки может в конечном итоге оказаться очень похожим на водопад или, возможно, на AgileFall.

Это может быть вполне приемлемо или даже необходимо для вашей команды. Попытка уместить все в спринт в поисках какого-то идеального «гибкого» решения может привести к крайне плохим результатам, особенно если приноситься в жертву более крупные и исследовательские исследования.

Вывод

Явное признание того факта, что существуют разные типы исследований с разными временными горизонтами и разными логистическими требованиями, может стать первым шагом на пути к согласованию исследований с гибкими методологиями. Имея отдельные группы, ответственные за разные виды исследований может стать важным шагом, чтобы не выгореть всех исследователей в команде!

К сожалению, не все команды обладают необходимыми ресурсами для создания отдельных команд, занимающихся разными направлениями. В этом случае исследователям необходимо научиться работать на разных уровнях и найти лучшую методологию исследования, подходящую для вопросов, на которые они пытаются ответить.

Рекомендации и где узнать больше

Узнайте больше о подходе Dual Track Agile Линн Миллер здесь.

Изображения

© Дэниел Скрок и Интерактивный дизайн Фонд, CC BY-SA 3.0