Jobs To Be Done в дизайне: как перестать проектировать фичи и начать решать задачи

## Откуда пришёл фреймворк

Идею сформулировал Клейтон Кристенсен в Гарварде на основе наблюдений за тем почему люди переключаются с одного продукта на другой. Самый известный пример из его исследований — молочный коктейль в сети фастфуда.

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

Никакая фокус-группа с вопросом «что улучшить» не дала бы этого инсайта.

## Три слоя любого job

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

Функциональный. Что человек делает буквально. Отправляет файл. Бронирует стол. Оплачивает счёт. Это видно в аналитике и в юзабилити-тестах.

Эмоциональный. Как он хочет себя чувствовать в процессе и после. Уверенно — не облажаться перед командой. Спокойно — не держать это в голове. Гордо — сделал сам, не попросил помощи.

Социальный. Как он хочет выглядеть в глазах других. Профессионально. Заботливо. Современно.

Пример: человек ищет приложение для тренировок. Функциональный job — отслеживать прогресс и получать план. Эмоциональный — чувствовать что двигается к цели, а не топчется на месте. Социальный — выглядеть человеком который следит за собой.

Приложение которое решает только функциональный уровень — трекер. Приложение которое попадает во все три — продукт к которому возвращаются.

## Как формулировать job statement

Формула которую используют большинство практиков JTBD:

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

Три правила хорошего job statement:

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

Второе — контекст важнее персоны. Один и тот же человек нанимает продукт по-разному в разных ситуациях. Руководитель проверяет дашборд утром в понедельник и руководитель проверяет дашборд за пять минут до презентации — это два разных job с разными требованиями к скорости, глубине и формату.

Третье — формулировка должна оставаться верной даже если ваш продукт исчезнет. Job описывает прогресс пользователя, а не взаимодействие с интерфейсом.

Несколько примеров для типичных продуктов:

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

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

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

## Как находить jobs: три метода

### Интервью на переключение

Самый эффективный метод в JTBD-практике. Спрашиваешь не «что вам нравится» а «расскажите о моменте когда вы решили попробовать этот продукт». Дальше идёшь назад: что происходило до? Что стало триггером? Что рассматривали как альтернативу? Почему выбрали именно это?

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

Три вопроса с которых стоит начать:

— Вспомните день когда вы впервые воспользовались [продуктом].
  Что происходило в тот день?
— Что вы делали до этого чтобы решить ту же задачу?
— Был ли момент когда вы почти не стали это использовать?

### Контекстное наблюдение

Наблюдаешь как человек работает в своей среде — не в лабораторных условиях. Люди не рассказывают про обходные пути которые придумали. Не говорят что открывают Excel потому что в основном продукте нет нужного фильтра. Не упоминают что перефотографируют экран потому что экспорт слишком медленный.

Контекстное наблюдение показывает jobs которые никогда не всплывут в интервью.

### Job mapping

Берёшь один job и разбиваешь на шаги: что человек делает до, во время и после. На каждом шаге спрашиваешь: где тратится больше времени чем должно? Где возникает неуверенность? Где человек делает что-то в обход?

Это не карта пользовательского пути — CJM описывает взаимодействие с продуктом. Job map описывает работу которую человек делает независимо от того существует ли ваш продукт.

## Как JTBD меняет решения на практике

На этапе исследования. Вместо вопроса «какие фичи вам нужны» задаёшь вопрос «в какой ситуации вы это используете и что было бы если бы этого не было». Разница в качестве инсайтов — принципиальная.

На этапе проектирования. Каждое решение проверяется вопросом: какой job это помогает выполнить? Если ответа нет — решение под вопросом. Это быстро обнажает фичи которые добавили потому что «конкуренты сделали» или «попросил CEO».

На этапе приоритизации. Вместо спора «какая фича важнее» команда смотрит на jobs которые плохо закрыты. Метрика — насколько job важен для пользователя и насколько он сейчас удовлетворён. Высокая важность + низкое удовлетворение = возможность.

На этапе тестирования. Юзабилити-тест показывает может ли человек выполнить сценарий. JTBD-тест показывает решает ли продукт реальную задачу в реальном контексте. Это разные вопросы с разными ответами.

## Типичные ошибки

Путают job с задачей в интерфейсе. «Нажать на кнопку экспорта» — это не job. «Подготовить отчёт до встречи не переключаясь между пятью инструментами» — job.

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

Собирают jobs и кладут в стол. Job statements бесполезны как артефакт. Они работают только если команда возвращается к ним на каждом ревью дизайна и каждом планировании.

Пытаются закрыть все jobs сразу. Лучше глубоко закрыть один-два core job, чем поверхностно — десять. Продукты которые пытаются нанять на всё проигрывают специализированным.

## Как AI ускоряет JTBD-исследование

JTBD работает на качественных данных — интервью, наблюдения, транскрипты. Исторически именно анализ был узким местом: 20 интервью дают сотни страниц текста, ручная кодировка занимает три-четыре недели. AI не заменяет исследователя, но сжимает этот цикл радикально.

Вот конкретные места где AI встраивается в JTBD-воркфлоу.

### Подготовка гайда для интервью на переключение

JTBD-интервью устроено иначе чем обычное Discovery-интервью. У него конкретная структура: шесть стадий временно́й линии (первая мысль → пассивный поиск → активный поиск → решение → первое использование → результат) и четыре силы которые двигают или тормозят переключение. Построить гайд который покрывает все стадии и не пропускает нужные пробинг-вопросы — задача на несколько часов.

Промпт для Claude:

Ты опытный JTBD-исследователь. Составь гайд для интервью
на переключение по методологии Боба Мёсты.

Продукт: [название и короткое описание]
Аудитория: [кто участники]
Цель: понять почему пользователи перешли с [альтернативы]
на наш продукт в последние 3 месяца.

Включи:
— Разогрев и установку доверия (5 мин)
— Шесть стадий временно́й линии с 3-4 пробинг-вопросами на каждой
— Блок четырёх сил: push, pull, anxiety, habit
— Закрытие и next steps

Вопросы должны быть открытыми, без упоминания фич продукта.

### Очистка и подготовка транскрипта

Сырой транскрипт из Otter, Fireflies или Zoom — это шум: непоследовательные метки спикеров, слова-паразиты, временны́е метки которые ломают структуру. Перед анализом транскрипт нужно привести в порядок.

Промпт:

Очисти этот транскрипт JTBD-интервью:
— Нормализуй метки спикеров: интервьюер → И, участник → У
— Убери слова-паразиты (ну, вот, типа, как бы) сохраняя смысл
— Сохрани эмоциональные маркеры: [смеётся], [пауза], [неуверенно]
— Сохрани дословные цитаты нетронутыми — они пойдут в job statements
— Убери временны́е метки, структурируй по репликам

[вставь транскрипт]

### Извлечение job statements из транскриптов

Самое трудоёмкое в анализе JTBD — найти паттерны через несколько интервью. AI работает с большим объёмом текста одновременно и видит повторяющиеся мотивы которые при ручной работе легко пропустить.

Промпт для одного транскрипта:

Проанализируй транскрипт JTBD-интервью.

Извлеки:
1. Job statements по формуле «Когда [контекст], я хочу [действие],
   чтобы [результат]» — отдельно функциональные, эмоциональные, социальные
2. Триггеры переключения — что именно запустило поиск альтернативы
3. Силы притяжения к новому продукту (pull)
4. Силы торможения — тревоги и привычки которые мешали переключиться
5. Прямые цитаты под каждый пункт

Не добавляй интерпретации — только то что прямо сказал участник.

[вставь транскрипт]

Промпт для синтеза по нескольким транскриптам:

Ниже очищенные транскрипты [N] JTBD-интервью.
Найди сквозные паттерны:

— Топ-3 job по частоте упоминания с цитатами из разных участников
— Повторяющиеся триггеры переключения
— Общие тревоги которые тормозили решение
— Противоречия между участниками — где мнения расходятся
— Неожиданные находки которые встретились у 1-2 участников
  но кажутся значимыми

Для каждого паттерна: сколько участников его упомянули
и минимум одна прямая цитата.

[вставь транскрипты]

### Валидация job statements

Написал job statement — проверь его перед тем как строить на нём решения.

Проверь эти job statements по критериям качества:

— Нет упоминания продукта или фичи
— Контекст конкретный, не абстрактный
— Результат описывает прогресс пользователя, не взаимодействие с интерфейсом
— Формулировка остаётся верной если наш продукт исчезнет

[вставь job statements]

Для каждого: оценка ок / нужна правка + конкретное предложение
как улучшить если нужно.

### Важная граница

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

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

## Чеклист: как применить на следующем проекте

Исследование
☐ Провести минимум 5 интервью на переключение
☐ Записать job statements по формуле: Когда / Я хочу / Чтобы
☐ Проверить: в формулировке нет упоминания продукта или фичи

Проектирование
☐ Каждое новое решение проверить: какой job оно закрывает?
☐ Для ключевых экранов определить функциональный и эмоциональный job
☐ Убрать из бэклога фичи для которых нет ответа на этот вопрос

Приоритизация
☐ Оценить jobs по матрице: важность × текущая удовлетворённость
☐ Сфокусироваться на jobs с высокой важностью и низкой удовлетворённостью

Тестирование
☐ Проверять не «может ли пользователь выполнить сценарий»
   а «решает ли это его реальную задачу в реальном контексте»