JTBD-интервью: как понять, почему клиент решил что-то менять

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

JTBD-интервью помогает восстановить эту историю. Ниже — руководство от выбора респондентов до решения, которое команда сможет проверить. Разберём один сквозной учебный кейс, подготовим вопросы и покажем, как использовать Текстослав для отдельного интервью и исследования по нескольким записям.

Если вы пока проверяете, какой сегмент и проблему стоит исследовать, начните с полного маршрута CustDev — от гипотезы к проверке. Для подготовки нейтральных вопросов пригодится сценарий глубинного интервью. Этот гайд посвящён конкретной задаче: восстановить историю выбора и переключения, включая случай, когда перехода не произошло.

Сначала определите, какое решение вы исследуете

Jobs to be Done — семейство подходов к изучению того, чего человек пытается добиться в определённых обстоятельствах. Здесь используем интервью о переходе на новое решение, или switch interview, в подходе Боба Моэсты и Криса Спика. Предмет разговора — уже случившийся выбор: покупка, смена инструмента, отказ от привычного способа. Авторы метода объясняют его через восстановление конкретной истории переключения.

Есть и другая известная методология — Outcome-Driven Innovation у Strategyn. Она описывает функциональную задачу, её этапы и критерии успешного выполнения, которые затем можно количественно исследовать. Карта задачи и desired outcomes — отдельные инструменты. Не стоит называть таблицу цитат полноценным ODI-исследованием.

Для нашего примера вопрос такой: что заставляет небольшое агентство перейти от согласования макетов в переписке к отдельному сервису? Мы хотим понять момент перехода и препятствия, чтобы решить, что показывать в первом знакомстве с продуктом.

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

Когда история переключения подходит

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

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

Кого приглашать: ищите опыт, который отвечает на вопрос

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

Перед приглашением задайте короткие отборочные вопросы:

• Как сейчас согласовываете макеты с заказчиками?
• Менялся ли этот процесс за последнее время? Когда?
• Как участвовали в выборе лично вы?
• Чем пользовались до изменения?
• Есть ли конкретный проект, на котором впервые попробовали новый способ?

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

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

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

Подготовка: один лист, который удержит разговор в теме

Для первого интервью можно запланировать час. Это рабочий ориентир, а не обязательная длительность: сложная корпоративная покупка может потребовать отдельного разговора с другим участником.

Подготовьте лист с пятью строками: прежний способ, первый повод задуматься, поиск вариантов, выбор, первое использование. Оставьте место для событий и вопросов. Не пытайтесь заранее заполнить историю собственными предположениями.

В начале объясните цель: «Мы разбираемся, как команды меняют процесс согласования. Хотим восстановить ваш последний выбор. Здесь нет правильных ответов; нам полезны и удачные, и неприятные детали». Согласуйте запись, круг доступа и использование цитат. Это часть нормальной подготовки интервью, которую также описывает руководство GOV.UK по глубинным интервью.

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

Как вести интервью: соберите историю из событий

Начните с понятной опоры: «Когда вы впервые использовали новый сервис на реальном проекте?» Дальше можно двигаться назад к выбору, затем к прежнему процессу. Собеседник не обязан рассказывать в хронологическом порядке — порядок вы восстановите при разборе.

Модель timeline у Моэсты и Спика различает первую мысль о перемене, пассивное знакомство с вариантами, активный поиск, решение и использование. Её польза для интервьюера — видеть пропуски между событиями. «Давно было неудобно» и «оплатили в понедельник» оставляют без ответа главный вопрос: что произошло между ними?

Прежний способ и конкретный сбой

Спросите: «Возьмём последний проект до перехода. Как макет попадал к заказчику? Кто собирал правки? Как понимали, какая версия согласована?»

Если услышите «всё терялось», попросите эпизод: «Что потерялось в последний раз? Как вы это заметили? Что пришлось делать?» Вы ищете последовательность действий и последствия. Потерять сообщение, отправить не ту версию в печать и потратить десять минут на поиск — разные ситуации.

Момент, когда начали действовать

«Когда вы впервые сделали что-то, чтобы изменить процесс? Что это было? Что происходило на работе в тот день?»

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

Реальные альтернативы и компромиссы

«Что ещё рассматривали? Что попробовали? Почему один вариант отложили? Что в выбранном решении пришлось принять, хотя это не нравилось?»

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

Сомнения и окончательное решение

«В какой момент были ближе всего к отказу? Что тогда останавливало? Как это разрешилось? Кто ещё участвовал в решении?»

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

Ожидание и первое использование

«Какой результат вы рассчитывали получить на первом проекте? Что получилось в действительности? Что продолжили делать старым способом?»

Здесь часто обнаруживается разрыв между покупкой и внедрением. Доступ оплачен, но клиент по-прежнему присылает правки в личные сообщения. Это важная часть истории перехода.

Мини-разбор: что скрывается за словами «нужна автоматизация»

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

08:12 · Анна: У нас и раньше путались версии. Я вечером собирала правки из трёх чатов, но обычно успевала.
14:36 · Анна: В августе в печать ушёл макет до последнего исправления. Клиент нашёл ошибку уже в тираже.
21:05 · Анна: Сначала я сделала правило: все правки только в одном чате. Через неделю заказчик снова написал дизайнеру напрямую.
29:40 · Анна: Боялась, что клиенту придётся заводить аккаунт. Он и на письма отвечает через раз.
35:18 · Анна: На пробе отправила ему ссылку. Он открыл и оставил комментарий. Тогда я пошла согласовывать оплату.

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

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

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

Пробная формулировка job story:

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

Эта фраза — гипотеза исследователя. Её ценность проверяется тем, объясняет ли она другие сопоставимые истории и помогает ли принять конкретное решение.

Сравнение: попробовали и вернулись назад

Вторая история тоже полностью вымышленная. Борис из агентства В столкнулся с похожей ошибкой версии:

10:20 · Борис: «Попробовали сервис после переделки печатного макета».
18:10 · Борис: «Заказчик открыл ссылку, но правки всё равно прислал дизайнеру в мессенджер».
25:45 · Борис: «На втором проекте я вёл и сервис, и чат. Стало две версии обсуждения».
32:05 · Борис: «Вернули один общий чат; финальное подтверждение теперь запрашиваю отдельно».

Версия «всем нужен сервис после дорогой ошибки» не выдерживает сравнения. Рабочая гипотеза уже: участие внешнего заказчика может быть условием устойчивого перехода. Альтернативное объяснение — разные типы проектов или права участников; в интервью это пока не выяснено. Следующие вопросы восстанавливают события: «На каком шаге клиент ушёл в чат?», «Что было иначе во втором проекте?», «Кто должен был поддерживать новый порядок?» Вопрос «Каких функций не хватило?» полезен позже, но без истории способен скрыть двойную работу за списком пожеланий.

Разбор одного интервью в Текстославе

После загрузки записи проверьте, кто из спикеров интервьюер, а кто респондент. Это влияет на смысл: ваш вопрос «боялись потерять данные?» не является свидетельством того, что клиент действительно этого боялся.

Откройте «Аналитика» → «Новый отчёт» → «По одной записи» и выберите формат «Почему клиент меняет решение». Он предназначен для истории выбора: триггер, хронология, альтернативы, силы перехода, ожидаемые результаты и голос клиента.

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

Для точечного продолжения используйте «Чат с ИИ» по записи:

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

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

Несколько интервью: соберите исследование с общей структурой

Когда интервью становится много, отдельных резюме мало. В одном акцент на цене, в другом на внедрении, в третьем на функциях — сопоставлять их неудобно. Для этого в Текстославе есть исследования по записям проекта.

Соберите материалы одной исследовательской задачи в проект. Перейдите в «Аналитика» → «Новое исследование». Можно выбрать шаблон или задать «Свой вопрос», описать нужный результат и подготовить структуру исследования.

Например:

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

Перед запуском откройте «Состав данных» и проверьте, что именно будет собираться. В собственном исследовании можно добавить сущности, описать правила их поиска, выбрать вид значения и способ получения: «Из записи» или «Вывод ИИ».

Для нашего примера начните с небольшой структуры:

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

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

Как читать базу, чтобы заметить закономерность

В «Базе данных» можно смотреть таблицу и карту связей, искать и фильтровать значения, открывать цитаты с источником, спикером и временем. Используйте это для сопоставления случаев, а не только для подсчёта находок.

Допустим, в нашей учебной серии получилось так:

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

NN/g описывает тематический анализ как движение от фрагментов и кодов к темам через сравнение данных. Простое объединение одинаковых слов ещё не объясняет поведение. Ищите различия внутри темы и случаи, которые противоречат вашему объяснению.

В интерфейсе показатели охвата относятся к записям. Одна компания могла дать три интервью, а один человек — повторить проблему десять раз. Для выводов о независимых клиентах учитывайте состав исследования отдельно. Имя спикера само по себе не устанавливает, что это один и тот же человек в разных файлах.

Из исследования — в проверяемое продуктовое решение

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

1. Какой вопрос исследовали и какие случаи вошли.
2. Главное наблюдение и подтверждающие источники.
3. Противоречащие случаи и границы вывода.
4. Возможное объяснение.
5. Какое изменение стоит проверить.
6. Что будем считать поддержкой или опровержением.

Для нашего кейса результат мог бы выглядеть так:

Наблюдение. В одной истории оплатили после первого комментария заказчика; в другой его отказ остановил переход. Ещё одна команда выбрала систему крупного клиента.

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

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

Что ещё неизвестно. Насколько часто это препятствие встречается в целевом рынке, влияет ли его устранение на оплату и сохранится ли эффект после первого проекта.

Так исследование приводит к наблюдаемому действию. Если нужно оценить распространённость проблемы или коммерческий эффект, потребуются отдельный количественный дизайн и продуктовый эксперимент. Несколько выразительных интервью не дают процента рынка.

Когда интервью действительно получилось

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

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

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