1. Вводная часть

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

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

Если копнуть глубже, может оказаться, что человек заказывает продукты вечером после работы и его реальная задача звучит примерно так:

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

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

Именно с такими задачами работает Jobs To Be Done — JTBD.

Но откуда узнать, какую работу на самом деле пытается выполнить пользователь? Для этого нужны исследования. Один из подходов — Customer Development, или CustDev: разговор с потенциальными и существующими пользователями, изучение их поведения, проблем, альтернатив и процесса принятия решений.

На этой лекции мы свяжем два подхода:

CustDev помогает получить факты о поведении → JTBD помогает структурировать эти факты → продуктовая команда превращает jobs в продуктовые и интерфейсные решения.

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

2. Основная идея темы

Продукт существует не ради своих функций и экранов. Он помогает человеку изменить некоторую ситуацию.

Пользователь не просыпается утром с желанием «использовать SaaS-сервис». У него появляется задача.

Например:

«Мне нужно понять, почему упали продажи».

«Мне нужно быстро согласовать макет с клиентом».

«Мне нужно найти квартиру до переезда».

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

Продукт становится инструментом достижения результата.

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

Это меняет направление продуктового мышления.

Вместо вопроса:

«Какие функции нужны пользователю?»

мы начинаем спрашивать:

«Какого прогресса человек пытается достичь и в какой ситуации?»

А уже после этого решаем, какие функции, сценарии и элементы интерфейса помогут ему этот прогресс совершить.

Получается цепочка:

Ситуация пользователя → проблема/мотивация → Job → желаемый результат → требования к продукту → пользовательский сценарий → интерфейс.

3. Что такое Jobs To Be Done

Jobs To Be Done можно перевести как «работа, которую необходимо выполнить».

Но слово работа здесь не означает профессию или рабочую обязанность. Job — это изменение ситуации, которого пытается добиться человек.

Например, человек покупает дрель.

Если смотреть на продукт буквально, ему нужна дрель. Если смотреть глубже — отверстие в стене. Но и отверстие может быть только промежуточным результатом.

Возможно, человек хочет:

повесить полку → освободить рабочий стол → организовать пространство → комфортнее работать дома.

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

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

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

4. Из чего состоит Job

Для продуктовой работы полезно рассматривать Job не как одну фразу, а как сочетание нескольких компонентов.

Контекст

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

Возьмём задачу «заказать еду».

Один пользователь заказывает еду:

— вечером после работы;

другой:

— во время обеденного перерыва;

третий:

— когда неожиданно пришли гости.

Формально действие одинаковое — заказ еды. Но Jobs различаются.

В первом случае человеку может быть важнее минимальное количество действий.

Во втором — точное время доставки.

В третьем — возможность быстро подобрать много еды для группы людей.

Поэтому вопрос «В какой ситуации возникает потребность?» принципиально важен.

Мотивация

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

Например:

«Я заканчиваю работу поздно и не хочу готовить».

Здесь возникает мотивация перейти из текущего состояния:

голоден + устал + мало времени

в желаемое:

есть готовая еда + минимум усилий + понятное время ожидания.

Именно переход между этими состояниями и представляет для нас интерес.

Прогресс

Одно из центральных понятий JTBD — progress, то есть прогресс.

Пользователь хочет не функцию. Он хочет оказаться в лучшей для себя ситуации.

Допустим, дизайнер использует сервис для создания прототипов.

Можно решить, что его Job:

«Создать прототип».

Но зачем?

После интервью выясняется:

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

Теперь продуктовая логика совершенно другая.

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

Исследование Job начинает влиять на требования к интерфейсу.

5. Формулировка JTBD

Для учебной работы удобно использовать конструкцию:

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

Например:

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

Обратите внимание: здесь нет конкретного интерфейсного решения.

Мы не написали:

«Когда я открываю приложение, я хочу кнопку "Повторить заказ"».

Это уже решение.

Если мы слишком рано включаем решение в Job, мы ограничиваем пространство проектирования.

Из одного Job могут появиться разные решения:

повторить предыдущий заказ;

сохранить набор продуктов;

автоматически сформировать корзину;

показать часто покупаемые товары;

создать регулярный заказ.

Сначала необходимо понять работу. Затем — искать оптимальное решение.

6. Функциональные, эмоциональные и социальные аспекты

Пользовательские задачи редко бывают исключительно функциональными.

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

Функциональная задача: быстро собрать понятную презентацию из данных.

Но одновременно может существовать эмоциональная задача:

чувствовать уверенность перед выступлением.

И социальная:

выглядеть компетентным перед руководителем и коллегами.

Это важно для дизайна.

Если команда видит только функциональный уровень, она может сделать хороший редактор с десятками возможностей.

Но если пользователь боится сделать «непрофессиональную» презентацию, ценными становятся шаблоны, проверка структуры, рекомендации по оформлению и предпросмотр.

То есть эмоциональная составляющая Job способна влиять на совершенно конкретные продуктовые решения.

7. Customer Development

Теперь возникает вопрос: откуда вообще взять Job?

Один из источников — Customer Development, или CustDev.

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

Главная идея здесь проста:

мы не должны придумывать поведение пользователя за него.

Если команда говорит:

«Наверное, пользователям сложно выбирать тариф»,

это гипотеза.

Чтобы получить данные, необходимо изучить реальные ситуации.

8. Почему нельзя просто спросить пользователя, чего он хочет

Представим интервью:

— Какие функции вам нужны в банковском приложении?

Пользователь отвечает:

— Хочу аналитику расходов с искусственным интеллектом.

Команда записывает:

Feature request: AI-аналитика расходов.

Но мы пока почти ничего не узнали.

Почему человеку нужна аналитика?

Когда возникает проблема?

Что он делает сейчас?

Что именно его не устраивает?

Что произойдёт, если проблему не решить?

Возможно, после дополнительных вопросов выяснится:

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

Вот это уже полезная информация.

Job может выглядеть так:

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

Теперь команда может искать разные решения. AI — только один из вариантов.

9. Как проводить интервью в логике JTBD

Ключевой принцип — изучать реальное прошлое поведение, а не фантазии о будущем.

Слабый вопрос:

«Вы бы пользовались функцией автоматического анализа расходов?»

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

Сильнее спросить:

«Вспомните последний раз, когда вы пытались разобраться со своими расходами. Что произошло?»

Дальше мы восстанавливаем историю.

Что стало триггером?

Почему человек решил что-то делать?

Что попробовал сначала?

Какие альтернативы рассматривал?

Что его не устраивало?

Почему в итоге выбрал конкретный инструмент?

Что произошло после?

Так мы исследуем не декларируемое мнение, а поведение.

10. Силы выбора

Полезная часть JTBD-анализа — понимание сил, которые влияют на изменение поведения пользователя.

Представим, что человек ведёт задачи команды в таблице, а мы предлагаем ему специализированный таск-менеджер.

Сам факт существования более удобного инструмента ещё не означает переход.

На решение действуют противоположные силы.

Push — давление текущей ситуации. Что не устраивает пользователя сейчас? Например, задачи теряются, сложно видеть ответственных, таблица становится слишком большой.

Pull — привлекательность нового решения. Что тянет пользователя к альтернативе? Например, автоматические уведомления, статусы, дедлайны, единая история работы.

Но одновременно существуют силы, удерживающие пользователя.

Habit — привычка. Команда уже умеет работать в таблице. Всё знакомо.

Anxiety — тревога перед новым решением. А что, если миграция займёт неделю? Что, если сотрудники не захотят учиться? Что, если потеряются данные?

Получается условная модель:

Push + Pull → способствуют переходу.

Habit + Anxiety → удерживают от перехода.

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

Например, импорт из Excel уменьшает стоимость смены инструмента. Пошаговый onboarding снижает тревогу. Знакомые паттерны интерфейса уменьшают необходимость переучиваться.

11. Связь JTBD и CustDev

Теперь можно соединить два подхода.

CustDev — способ исследовать реальность пользователя.

JTBD — способ структурировать часть полученных знаний вокруг прогресса и обстоятельств выбора.

Во время интервью мы получаем историю:

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

Из этой истории можно извлечь:

Контекст: количество проектов увеличилось.

Push: задачи начали теряться.

Старая альтернатива: заметки и таблицы.

Pull: возможность видеть задачи и статусы централизованно.

Anxiety: сложность настройки.

Habit: привычка работать в таблицах.

Прогресс: контролировать несколько проектов без необходимости держать всё в голове.

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

12. От интервью к JTBD

Рассмотрим небольшой пример.

Допустим, мы проектируем сервис онлайн-обучения.

На интервью студент говорит:

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

Плохой вывод:

«Пользователю нужны короткие уроки».

Почему плохой? Потому что мы слишком быстро перешли от наблюдения к решению.

Сначала извлечём данные.

Контекст: обучение происходит вечером после работы.

Ограничение: мало времени и энергии.

Проблема: длинный урок трудно начать при ограниченном времени.

Поведение: пропуск постепенно приводит к прекращению обучения.

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

JTBD можно сформулировать так:

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

Теперь появляется пространство решений.

13. Перевод Job в требования к интерфейсу

Это ключевой этап для продуктового дизайнера.

JTBD сам по себе не является макетом интерфейса.

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

Возьмём предыдущий Job:

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

Что следует из него?

Пользователь должен понимать, сколько времени займёт следующий шаг.

Следовательно, интерфейс может показывать:

«Следующий урок — 8 минут».

Пользователь должен иметь возможность быстро продолжить.

Следовательно:

«Продолжить с места остановки».

Пользователь хочет видеть, что небольшой шаг всё равно является прогрессом.

Следовательно, можно показать:

прогресс курса, завершённые этапы, ближайшую небольшую цель.

Если большие занятия создают барьер входа, продуктовая команда может проверить идею:

разбивать материал на короткие законченные части.

Заметьте важную последовательность:

Interview insight → Job → потребность → продуктовый принцип → интерфейсное решение.

А не:

Interview → пользователь попросил кнопку → рисуем кнопку.

14. Развёрнутый практический пример

Представим SaaS-сервис для небольших маркетинговых команд.

Команда продукта считает, что пользователям нужен новый dashboard со статистикой задач.

На CustDev-интервью руководитель маркетинга рассказывает:

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

Что мы видим?

Первоначальная гипотеза команды звучала как dashboard.

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

Контекст: подготовка к регулярной командной встрече.

Триггер: необходимость оценить состояние проектов.

Проблема: информация распределена между несколькими источниками.

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

Желаемый прогресс: быстро увидеть состояние работы и заранее заметить блокеры.

JTBD:

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

Теперь можно проектировать.

Нужен ли обычный dashboard?

Возможно.

Но из Job возникают более точные требования:

показывать задачи с просроченными сроками;

выделять задачи без движения;

показывать ответственного;

давать быстрый переход к проблемной задаче;

собирать информацию в одном месте;

позволять получить картину состояния без ручного опроса команды.

Только после этого дизайнер определяет структуру экрана.

15. Важное различие: Job и User Story

Студенты часто смешивают JTBD и User Story.

User Story обычно описывает требование примерно так:

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

JTBD находится уровнем выше:

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

JTBD помогает понять зачем и в каком контексте существует потребность.

User Story помогает конкретизировать что пользователь должен иметь возможность сделать в продукте.

Поэтому эти форматы могут дополнять друг друга.

JTBD → продуктовая гипотеза → User Story → интерфейсный сценарий.

16. Частые ошибки и заблуждения

1. Job превращается в функцию.
«Когда я открываю приложение, я хочу нажать кнопку повторного заказа» — это уже описание интерфейса. Нужно вернуться на уровень выше и спросить: зачем пользователь повторяет заказ?

2. Job формулируется слишком широко.
«Я хочу быть продуктивнее» почти бесполезно для проектирования. Непонятно, в каком контексте возникает задача и какой прогресс считается успешным.

3. Команда спрашивает о будущем вместо прошлого.
«Стали бы вы пользоваться нашей функцией?» даёт слабые данные. Лучше исследовать последний реальный случай возникновения проблемы.

4. Один комментарий пользователя превращается в требование.
Фраза «добавьте фильтр» ещё не означает необходимость фильтра. Сначала необходимо понять задачу, которую человек пытается решить.

5. CustDev превращается в презентацию продукта.
Если интервьюер половину встречи рассказывает идею и спрашивает, нравится ли она человеку, он изучает реакцию на презентацию, а не естественное поведение.

6. Исследователь задаёт наводящие вопросы.
«Вам ведь сложно каждый раз искать нужный документ?» уже содержит желаемый ответ. Лучше: «Расскажите, как вы в последний раз искали нужный документ».

7. JTBD автоматически считают доказанной потребностью.
Формулировка Job — это результат интерпретации исследования. Её полезно проверять на других интервью и через дополнительные данные.

17. Ограничения подхода

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

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

Например, JTBD не заменяет юзабилити-тестирование.

Мы можем прекрасно понимать Job пользователя и при этом сделать неудобный интерфейс.

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

То есть продуктовая работа может выглядеть так:

Интервью объясняют «почему» → продуктовая аналитика показывает «что и насколько часто» → JTBD структурирует потребность → прототипирование предлагает решение → usability testing проверяет, способен ли пользователь этим решением воспользоваться.

18. Работа с инструментами

Для этой темы студентам достаточно нескольких инструментов, которые выполняют разные роли.

Google Docs удобно использовать для транскриптов и заметок интервью. Важно сохранять реальные высказывания респондентов отдельно от собственных выводов исследователя.

Google Sheets подходит для синтеза нескольких интервью: строки могут соответствовать респондентам, а столбцы — контексту, триггерам, проблемам, альтернативам, Push/Pull, тревогам, привычкам и предполагаемым Jobs.

Miro или FigJam помогают визуально кластеризовать наблюдения и искать повторяющиеся паттерны.

Figma подключается уже после исследования: здесь продуктовые требования превращаются в User Flow, wireframes и прототипы.

ChatGPT можно использовать как помощника при обработке материалов: например, предложить варианты группировки наблюдений или проверить, не содержит ли формулировка Job готовое решение. Но ИИ не должен «придумывать» пользовательское исследование вместо реальных респондентов.

Итоги лекции

Главное, что нужно вынести из этой темы: не начинайте проектирование интерфейса с интерфейса.

Экран — это конец длинной цепочки продуктовых решений.

Сначала существует человек в определённой ситуации. У него появляется причина изменить текущее положение. Он использует знакомые решения, сравнивает альтернативы, чего-то опасается и пытается совершить некоторый прогресс.

Customer Development помогает исследовать эту реальность.

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

А продуктовый дизайн превращает это понимание в требования, сценарии и интерфейс.

Поэтому логика работы продуктового дизайнера выглядит не как:

«Что нарисовать?»

а как:

«Что происходит с пользователем?» → «Какого прогресса он хочет?» → «Почему существующие решения не справляются?» → «Что должен позволить ему продукт?» → «Какой сценарий это обеспечит?» → «Какой интерфейс нужен для этого сценария?»

Именно эта последовательность отделяет проектирование интерфейсов от проектирования продукта.