Метод Jobs to Be Done. Проектирование клиентоориентированного продукта

Узнать больше

Hugh Beyer and Karen Holtzblatt, Contextual Design (San Francisco: Morgan Kaufmann, 1998).

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

Indi Young, Structure Derivation, Chap. 13 in Mental Models (New York: Rosenfeld Media, 2008).

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

PLAY ➤ Проверка гипотез с помощью JTBD

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

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

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

Эффективное использование JTBD в экспериментах

В своей книге «Ориентированные на пользователя сценарии» Лоудермилк и Рич показывают, как применить JTBD для формулировки гипотез, проверяемых в жизненном цикле проектирования и разработки продукта[47]. JTBD напрямую связывает понимание лежащей в основе проблемы с решением, становясь объединяющей особенностью и предоставляя общий язык.

Подход авторов состоит из четырех этапов и называется «Система развития гипотезы» (Hypothesis Progression Framework, HPF). Первые два этапа – понимание клиента и проблемы – подпадают под категорию «развития клиента» (кастдев). Это примерно соответствует пониманию пространства задач. Стадия разработки продукта включает идею и разработку функций. В целом категории в этой системе напоминают «Четыре D» (найти, определить, разработать, доставить – discover, define, design, deliver), которые я использовал для организации этой книги. Но есть и некоторые отличия.

HPF позволяет проверить ваши предположения на любой стадии разработки. Авторы рекомендуют на каждом этапе выдвигать и проверять гипотезы.

В частности, они советуют при создании решения использовать формулу создания гипотез, которая берет на вооружение JTBD. На уровне функций Лоудермилк и Рич предлагают такой формат:

Мы считаем, что [тип клиента] успешно решит [проблему], используя [функцию] при выполнении [работы, которую нужно сделать].

Создайте решение, отвечающее нереализованным потребностям, и проверьте его.

Этап 1. Сформулировать гипотезу

Примите во внимание все предположения на каждом этапе и сформулируйте проверяемые гипотезы. Лоудермилк и Рич разработали формат для гипотез на каждой стадии, что показано в табл. 5.1.

Таблица 5.1. Система развития гипотезы (HPF) Лоудермилка и Рич