Jobs to Be Done для ИИ-функции в мобильном приложении описывает прогресс пользователя в конкретной ситуации. Формулировка начинается не с модели и не с экрана чата. Она отвечает на вопросы: что человек пытается завершить, почему текущий способ ему мешает и по каким признакам результат можно принять.
JTBD здесь является внутренним методом продуктовой разведки, а не внешним стандартом разработки ИИ. Интервью помогает сформировать гипотезу. Подтвердить частоту, важность и ценность работы могут только наблюдаемое поведение и данные продукта.
Отделите работу от технологии
Возьмите недавнюю ситуацию, а не абстрактное пожелание. Зафиксируйте повод, ограничения, желаемое изменение и следующего участника процесса. Просьба помочь с документом становится содержательной, когда известно, какое решение пользователь примет, что нельзя потерять и кто проверит итог.
Уберите из формулировки слова ИИ, ассистент и генерация. Если смысл исчез, команда описала любимый механизм. Работа пользователя должна допускать поиск, правило, изменение интерфейса или ручную услугу. На этапе выбора решения полезен анализ пользовательского сценария, но сам факт обращения к UX не подтверждает спрос на функцию.
Изучите обходные способы. Пользователь переносит данные между приложениями, хранит шаблон в заметках, спрашивает специалиста или откладывает действие. В этих деталях видны цена текущего пути и требования к доверию. Иногда они показывают, что хороший фильтр полезнее генеративной модели.
Превратите работу в проверяемое поведение
Опишите минимальный вход и результат, который человек способен проверить на небольшом экране. Затем добавьте неудобные случаи: неполные данные, противоречивые записи, слабое соединение, отсутствие разрешения, двусмысленный запрос и выход за назначение функции. Мобильный продукт должен распознать границу и предложить безопасное продолжение.
Завершение наступает не тогда, когда модель выдала ответ. Пользователь может подтвердить источник, исправить поле, выбрать вариант или передать результат следующей роли. Работа выполнена только после перехода окружающего процесса в допустимое состояние.
Смотрите на реальные решения, а не на каталог красивых экранов. Портфолио цифровых продуктов может показать диапазон задач команды, однако не является доказательством ценности конкретной ИИ-функции для вашей аудитории.
Инструментируйте путь от повода до принятого результата. Отдельно фиксируйте добровольный запуск, отказ, исправление, передачу человеку, повторное использование и отклонение результата дальше по процессу. Одна суммарная метрика активности скроет причины.
Проверьте работу до расширения функции
Проведите ограниченный тест на типичных входных данных и реальных ограничениях. Сравните новый путь с текущим по завершению, времени, усилию на проверку и серьёзным ошибкам. Вывод относится только к наблюдаемой группе и периоду. Демонстрация прототипа не доказывает принятие, безопасность и экономическую ценность.
В мобильном продукте отдельно проверьте момент и место использования. Функция, полезная за рабочим столом, может мешать в дороге, при слабой связи или когда у человека занята одна рука. Наблюдение должно охватывать реальный контекст, а не только интервью в переговорной. Оно помогает отличить слабую работу от неудачной формы взаимодействия.
Опишите конкурентом функции не только другое приложение. Им может быть звонок коллеге, сохранённый шаблон, отказ от действия или привычный ручной маршрут. Если новый способ требует больше проверки, переключений и ожидания, технологическая новизна не создаёт прогресс для пользователя.
Перед разработкой согласуйте владельца результата. Кто обновляет подсказки, разбирает исключения, контролирует качество входных данных и отвечает за передачу человеку? Без этих обязанностей JTBD останется красивой формулировкой, а эксплуатационная нагрузка проявится уже после запуска.
Зафиксируйте отклонённые варианты решения и причину выбора. Этот короткий журнал помогает вернуться к исходной работе, если модель или интерфейс не проходят тест, вместо того чтобы защищать уже вложенные усилия. Договорённость сохраняет фокус.
Заранее задайте решение после теста. Продолжать можно, если работа подтверждена, результат проверяем, отказ безопасен, а владелец процесса принимает эксплуатационные обязанности. Изменить концепцию нужно, если человек ожидает другой прогресс. Остановиться следует, когда функция только переносит нагрузку на коллегу.
Материал о том, почему порталы не поддерживают реальную работу, показывает похожую ошибку: структура продукта начинает диктовать маршрут вместо задачи пользователя.
Частые вопросы
Это конкретный прогресс в определённой ситуации: повод начать действие, ограничения, желаемый результат и критерий его принятия.
Обычно нет. Формулировка должна сохранять смысл, даже если задачу лучше решит обычный алгоритм, поиск или изменение процесса.
Изучите недавние случаи, обходные способы и реальные входные данные, затем проверьте ограниченный сценарий с понятным критерием результата.
Когда потребность не подтверждена, результат невозможно проверить, обычная логика надёжнее или последствия ошибки не допускают выбранный режим работы.
Когда работа, границы и критерии проверки определены, проектирование мобильного продукта может выбрать подходящий механизм и проверить его без преждевременного масштаба.
