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

• Когда я хочу проверить электронную почту, но не хочу, чтобы кто-то вокруг знал, что я это делаю, потому что они могут подумать, что это невежливо…

Каждый пример ситуации обеспечивает гораздо более широкий контекст для разработки приемлемого решения.

Как подходить к историям работы

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

Когда я [обстоятельство + этап работы / шаг], я хочу [микроработа], чтобы я мог [потребность].

Примеры:

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

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

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

Рассмотрим последний пример. Первый элемент соединяет информацию об обстоятельствах (выезжаю поздно) с выполнением основной работы (поехать на работу) в рамках одного из этапов процесса (готовлюсь поехать).

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

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

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

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

Тогда история работы из предыдущего примера с поездкой на работу выглядела бы следующим образом:

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

Стеф Троэт, исследователь и инструктор по JTBD из Великобритании, подходит к историям работы иным образом. Она использует формулу:

Когда я [обстоятельства] хочу [работа] так, чтобы [выгода, предлагаемая решением].

Интерпретация не столь важна, главное – найти последовательную структуру и придерживаться ее. Форма, на которой вы остановитесь, должна подходить для вашей команды и ситуации.

Истории работы в действии

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

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