«Нужен личный кабинет». Такое пожелание уже похоже на техническое задание, но пока ничего не объясняет о задаче клиента. Возможно, ему надо получать документы без звонков. Возможно, согласовывать закупку с руководителем. А может быть, кабинет вообще не нужен: человеку достаточно понятного письма с нужными файлами.
В Гуси-Лебеди мы предлагаем сначала разобраться, что человек пытается изменить в своей работе. Jobs to be Done помогает задать этот вопрос до обсуждения кнопок, разделов и рекламных обещаний. Разберём подход на условном примере закупки: это учебная ситуация, а не описание нашего клиента.
Что такое JTBD и почему задача не равна функции
Jobs to be Done, сокращённо JTBD, рассматривает выбор продукта через прогресс, которого человек хочет добиться в определённых обстоятельствах. Именно так подход объясняет Christensen Institute. Слово «работа» здесь не означает должность. Это задача, ради которой человек выбирает решение.
Представим сотрудника, который ищет поставщика оборудования. «Скачать коммерческое предложение» описывает действие. «Получить файл PDF» описывает его ближайший результат. Но задача может быть шире: передать руководителю достаточно сведений, чтобы согласовать закупку и не возвращаться к поставщику с каждым новым вопросом.
Эта разница меняет разговор о сайте. Удобная кнопка скачивания полезна, однако она не поможет, если в предложении отсутствуют условия поставки или непонятно, подходит ли оборудование. И наоборот, часть задачи может решаться без кабинета: карточкой товара, сравнением вариантов, письмом менеджера. Какие варианты подходят, предстоит проверить.
У выбора бывает несколько сторон. Функциональная: получить нужные сведения. Эмоциональная: меньше тревожиться о неверном решении. Социальная: выглядеть подготовленным перед коллегами. Эти мотивы нельзя автоматически приписать каждому закупщику. Они дают направления для вопросов, а ответ нужен из конкретной истории человека.
Интервью: восстановите историю, прежде чем искать красивую формулировку
Начните с человека, который действительно выбирал решение. Нам нужна история конкретной закупки: что произошло, как он искал варианты, с кем обсуждал решение и почему остановился на одном из них. Вопрос «Каким должен быть идеальный сайт?» слишком быстро превращает разговор в список пожеланий. Вместо него попросите вспомнить последний случай.
В нашем условном примере разговор можно начать так: «Расскажите про последнюю закупку оборудования. Когда стало понятно, что нужно искать поставщика?» Затем двигаться по событиям, не подсказывая ответы:
- Что вы использовали раньше и что перестало устраивать?
- Где искали варианты? Что сделали после первого поиска?
- Какие сведения понадобились для сравнения? Где их получили?
- Кто ещё участвовал в выборе и что было важно этому человеку?
- В какой момент появились сомнения? Как вы их проверили?
- Что произошло после покупки: удалось ли получить тот результат, ради которого выбирали поставщика?
Не обязательно задавать все вопросы подряд. Если собеседник рассказывает о согласовании, попросите описать его подробнее: кому отправил предложение, что получил в ответ, какого документа не хватило. Так появится цепочка действий вместо общего «у нас долго принимают решения».
Отделяйте слова человека от собственного объяснения. «Руководитель попросил условия гарантии, я снова писал менеджеру» относится к рассказанному событию. «Клиенту нужен личный кабинет» уже ваша гипотеза о решении. В заметках полезно держать эти записи раздельно, иначе предложенная функция незаметно станет якобы установленной потребностью.
В B2B у покупки могут быть разные участники: инициатор, пользователь, согласующий, закупщик. Интервью только с одним из них не объясняет автоматически всю сделку. В руководстве Контур подход рассматривается через реальные рабочие задачи и опыт респондента. Для своего исследования заранее определите, чью часть выбора вы изучаете.
Несколько похожих историй дают основание проверить повторяющуюся задачу. Они не показывают, какой процент рынка с ней сталкивается. Если решение о разработке зависит от распространённости проблемы, потребуется отдельная проверка на более широкой аудитории. Не превращайте выразительную цитату в статистику.
Job Story: сформулируйте задачу без готового решения
После интервью попробуйте собрать ситуацию, желаемое действие и результат в одну формулировку: «Когда …, я хочу …, чтобы …». Такой формат Job Story помогает сохранить обстоятельства выбора. Он описан, например, в материале Яндекса о JTBD.
Для нашей учебной закупки: «Когда я сравниваю поставщиков перед согласованием, я хочу собрать сопоставимые условия и документы, чтобы объяснить руководителю выбор и получить решение без повторного поиска информации».
Здесь нет требования сделать кабинет, чат или калькулятор. Это важно: одну задачу можно решить разными способами. Формулировка оставляет команде возможность сравнить их, а не строить интерфейс вокруг первой прозвучавшей идеи.
| Формулировка | Что в ней проверить |
|---|---|
| «Хочу удобный сайт» | Неясно, в какой ситуации и что именно мешает. Вернитесь к событиям интервью. |
| «Хочу скачать PDF» | Есть действие, но ещё не объяснён результат. Для чего нужен документ и что должно быть внутри? |
| «Хочу сравнить условия для согласования закупки» | Уже понятен следующий шаг человека. Уточните, какие условия сравнивает и кто принимает решение. |
Хорошая Job Story должна опираться на собранные истории. Если в интервью никто не говорил о согласовании, нельзя дописать его только потому, что пример выглядит убедительно. Сохраните сомнение как вопрос для следующей проверки.
JTBD можно сочетать с другими исследованиями. Персона описывает существенные характеристики пользователя, карта пути помогает разобрать этапы взаимодействия, интервью даёт материал для понимания конкретного выбора. Это разные ракурсы, а не обязательные конкуренты. Выбирайте инструмент под вопрос, на который пока нет ответа. Если нужно спланировать исследование шире одной истории покупки, посмотрите наш разбор целей и методов маркетингового исследования.
Как превратить выводы JTBD в содержание и проверку сайта
В Гуси-Лебеди мы предлагаем переводить исследование в конкретные решения: что человек должен узнать, какое действие совершить и чем проверить, что сайт ему помогает. Фраза «клиенту важно доверие» сама по себе не говорит дизайнеру, что рисовать, а редактору, что писать.
Вернёмся к условной закупке. Если в историях выбора регулярно не хватает сопоставимых условий, на сайте можно проверить таблицу характеристик, состав поставки и понятные условия обслуживания. Если документ приходится пересылать руководителю, стоит проверить, удобно ли сохранить предложение и понятно ли оно человеку, который не разговаривал с менеджером. Это варианты для проверки, а не универсальный набор блоков для каждого B2B-сайта.
Начните с небольшого прототипа. Дайте участнику задачу, близкую к его реальной ситуации: выбрать подходящий вариант и объяснить, какие сведения он отправит согласующему. Наблюдайте, где он ищет информацию, что не понимает и какие вопросы остаются. Не ограничивайтесь оценкой «нравится»: красивый экран может не помочь выполнить работу. При разработке веб-сервиса под задачи бизнеса такой сценарий можно использовать как основание для обсуждения требований и проверки прототипа.
Зафиксируйте критерий до проверки. Например, участник должен найти состав поставки и условия гарантии без подсказки, а затем показать, где возьмёт сведения для сравнения. Результат такого задания помогает обсуждать конкретное препятствие. Рост заявок или продаж потребует отдельного измерения после внедрения; интервью его не доказывает.
Решения удобно хранить вместе с основанием: наблюдение из интервью, предполагаемое изменение, способ проверки и результат. Если выяснится, что проблему решает обычное письмо с документами, нет необходимости немедленно разрабатывать сложный кабинет. Если препятствие связано с согласованием договора, одной новой кнопки на сайте тоже может оказаться недостаточно.
JTBD полезен именно до того, как пожелание превращается в дорогое техническое задание. Он помогает удержать в разговоре ситуацию человека и нужный ему результат. А сайт, интерфейс и рекламное сообщение становятся средствами, которые предстоит проверить в этой ситуации.