Jtbd to interface

JTBD → Interface: генеративная трансформация

Ты превращаешь структурированные JTBD в спецификацию интерфейса. Не «рисуешь интерфейс и потом проверяешь через jobs», а jobs порождают интерфейс. Каждый элемент экрана существует потому, что его породил конкретный job, outcome или circumstance.

Философия

Интерфейс — это Job Architecture, сделанная видимой. Разделы = Big Jobs. Экраны = Little Jobs. Последовательность состояний экрана = Job Map. Элементы на экране = Desired Outcomes. Варианты отображения = Circumstances × Personas.

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

---

Генеративная цепочка (5 уровней)

Скилл работает последовательно по 5 уровням. Каждый уровень берёт выход предыдущего и порождает следующий.

Уровень 1: Big Jobs → Навигация

Вход: список Big Jobs (3–7 штук) из Job Architecture.

Что делать:

1. Каждый Big Job = раздел верхнего уровня навигации.
2. Если Big Job имеет 2+ подработы с принципиально разными контекстами — допускается подраздел.
3. Навигация строится вокруг глаголов пользователя, не существительных системы.

Формат вывода:

NAV-1: {Глагол пользователя} ← Big Job "{job statement}"
NAV-2: {Глагол пользователя} ← Big Job "{job statement}"
  NAV-2.1: {Подраздел} ← Little Job "{job statement}"
  NAV-2.2: {Подраздел} ← Little Job "{job statement}"
...

Принцип именования: название раздела = то, что пользователь хочет СДЕЛАТЬ, не то, что система хранит. «Пополнить» вместо «Баланс». «Запустить рекламу» вместо «Рекламные аккаунты». «Получить деньги» вместо «Вознаграждение».

Контрольный вопрос: если заменить все названия разделов на «Сделать X», фразы должны звучать естественно для пользователя.

Уровень 2: Little Jobs → Экраны

Вход: навигационная карта из Уровня 1 + список Little Jobs, привязанных к каждому Big Job.

Что делать:

1. Каждый значимый Little Job = один экран (или состояние экрана).
2. Тривиальные Little Jobs (1 действие, 0 решений) могут быть элементом на экране родительского job, а не отдельным экраном.
3. Если Little Job обслуживает несколько Big Jobs — экран живёт в том разделе, где job выполняется чаще. В остальных разделах — ссылка / shortcut.

Формат вывода:

SCREEN: {screen-id}
  Раздел: NAV-{N}
  Job: "{job statement}"
  Тип: workspace | wizard | dashboard | list | detail | settings
  Частота: daily | weekly | monthly | event-driven
  Персоны: {список персон, которые используют этот экран}
  Связанные экраны: {screen-id} (переход при...)

Типология экранов (определяется характером job):

Характер job	Тип экрана	Когда
Мониторинг, обзор	Dashboard	Job типа Control, Monitor
Многошаговое создание	Wizard	Job типа Launch, Setup
Управление коллекцией	List + Detail	Job типа Manage, Organize
Ежедневная работа	Workspace	Job типа Execute, Operate
Конфигурирование	Settings	Job типа Configure, Customize

Уровень 3: Job Map → Flow экрана

Вход: экран из Уровня 2 + Job Map (8 шагов Ulwick) для этого job.

Что делать:

1. Каждый шаг Job Map, где пользователю нужно совершить действие или принять решение = отдельное состояние экрана или шаг wizard'а.
2. Шаги «Define» и «Locate» часто объединяются в начальный экран / форму.
3. Шаги «Monitor» и «Modify» часто объединяются в рабочую панель.
4. Шаг «Conclude» = экран подтверждения / результата.
5. Порядок шагов Job Map = порядок навигации внутри экрана (слева направо, сверху вниз).

Формат вывода:

FLOW: {screen-id}

  STATE-1: {название состояния}
    Job Map шаг: Define / Locate
    Что пользователь решает: {описание решения}
    Что нужно видеть: {информация для решения}
    Действие: {что пользователь делает}
    → переход: STATE-2 (при: {условие})

  STATE-2: {название состояния}
    Job Map шаг: Prepare / Confirm
    ...

  STATE-3: {название состояния}
    Job Map шаг: Execute
    ...

Шаги Job Map, которые НЕ порождают состояния экрана:

• Если шаг полностью автоматизирован системой (нет решения пользователя) — он не порождает UI-состояние, но может порождать уведомление или индикатор прогресса.
• Если два смежных шага всегда выполняются вместе без паузы — объединять в одно состояние.

Уровень 4: Desired Outcomes → UI-элементы

Вход: состояния экрана из Уровня 3 + Desired Outcomes для каждого шага Job Map.

Что делать:

1. Каждый Desired Outcome порождает один или несколько UI-элементов, которые помогают пользователю достичь этого outcome.
2. Outcome типа «Minimize X» → элемент, который показывает текущее значение X (для контроля).
3. Outcome типа «Reduce time to Y» → автоматизация Y или shortcut к Y.
4. Outcome типа «Increase confidence in Z» → визуализация Z, статус, preview, подтверждение.

Формат вывода:

ELEMENTS: {screen-id} / STATE-{N}

  EL-1: {тип элемента}
    Outcome: "{desired outcome statement}"
    Назначение: {зачем этот элемент существует}
    Содержание: {что показывает/делает}
    Приоритет: primary | secondary | tertiary

  EL-2: {тип элемента}
    Outcome: "{desired outcome statement}"
    ...

Типология элементов (определяется типом outcome):

Тип outcome	UI-элемент	Пример
Minimize error	Валидация, preview, подтверждение	«Проверить перед отправкой»
Reduce time	Shortcut, автозаполнение, шаблон	«Повторить прошлое пополнение»
Increase visibility	Метрика, статус-бар, таблица	«Текущий баланс: X ₽»
Maintain control	Фильтр, сортировка, переключатель	«Показать только мои аккаунты»
Avoid risk	Warning, confirmation dialog, undo	«Вы уверены? Отмена невозможна»

Приоритет элементов:

• Primary — элемент решает top-5 outcomes по opportunity score. Занимает главное визуальное пространство.
• Secondary — элемент решает outcomes из top-20. Видим, но не доминирует.
• Tertiary — остальные. Доступен по клику / раскрытию / настройкам.

Уровень 5: Circumstances × Personas → Варианты

Вход: экраны из Уровня 2 + персоны + обстоятельства (circumstances).

Что делать:

1. Определить, какие экраны выглядят по-разному для разных персон.
2. Определить, какие обстоятельства (контексты) меняют содержание экрана.
3. Вариант ≠ отдельный экран. Вариант = тот же экран, но с другим набором/приоритетом элементов.

Формат вывода:

VARIANTS: {screen-id}

  DEFAULT: {для какой персоны / обстоятельства}
    Показывать: EL-1, EL-2, EL-3
    Скрывать: —

  VARIANT-A: {персона или обстоятельство}
    Показывать: EL-1, EL-4, EL-5
    Скрывать: EL-2 (причина: {этот outcome не актуален для этой персоны})
    Добавить: EL-6 (причина: {уникальный outcome этой персоны})

  VARIANT-B: {обстоятельство}
    Изменить: EL-3 → расширенная версия (причина: {в этом контексте outcome критичнее})

Типичные обстоятельства (circumstances), меняющие экран:

• Первый раз vs. повторный визит (онбординг vs. рабочий режим)
• Маленький бюджет vs. крупный бюджет (разные риски, разные элементы контроля)
• Один аккаунт vs. много аккаунтов (простой список vs. поиск/фильтры/группировка)
• Штатная ситуация vs. проблема (рабочий режим vs. recovery mode)

---

Как запускать скилл

Минимальный вход

Чтобы скилл заработал, нужен хотя бы один из:

1. Job Architecture — структура Big Jobs → Little Jobs с outcomes. Идеально.
2. Нормализованная JTBD-библиотека — список job statements с типами и персонами. Скилл построит иерархию сам.
3. Raw JTBD-карточки — скилл предложит сначала нормализовать и кластеризовать.

Режимы работы

Полная генерация (все 5 уровней): Используй, когда проектируешь интерфейс с нуля или выполняешь полный редизайн. На вход — Job Architecture или JTBD-библиотека. На выход — полная Screen Spec.

Генерация одного экрана (уровни 3–4): Используй, когда навигация и экраны уже определены, нужно детализировать конкретный экран. На вход — один job + его Job Map + outcomes. На выход — flow и элементы одного экрана.

Генерация вариантов (уровень 5): Используй, когда экран уже описан, нужно определить, как он адаптируется под разные персоны или обстоятельства.

Формат итогового артефакта

Итог работы — файл screen-spec-{scope}.md со следующей структурой:

# Screen Spec: {название scope}

## Навигация
{вывод Уровня 1}

## Карта экранов
{вывод Уровня 2, таблицей: screen-id | job | тип | частота | персоны}

## Детализация экранов
### {screen-id}: {название}
#### Flow
{вывод Уровня 3}
#### Элементы
{вывод Уровня 4}
#### Варианты
{вывод Уровня 5}

## Traceability Matrix
{таблица: job-id | outcome | screen-id | element-id — для проверки полноты}

Traceability Matrix — самый важный артефакт для верификации. Если job не отображён ни в одном element-id — это Gap. Если element-id не привязан к job — это потенциальный Cargo Cult.

---

Антипаттерны (чего не делать)

1. Не рисуй интерфейс, а потом проверяй через jobs. Это аудит, не генерация. Если ловишь себя на фразе «а теперь проверим, покрыты ли jobs» — ты свернул не туда.

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

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

4. Не ставь элементы «потому что так принято». Дашборд с графиками не нужен, если ни один outcome не требует визуализации тренда. Таблица не нужна, если job не включает сравнение множества объектов.

5. Не путай частоту job с важностью экрана. Ежегодный job «Пройти аудит» может порождать экран с высшим приоритетом элементов, хотя используется раз в год.

---

Связь с другими скиллами и артефактами

Что	Где	Связь
Job Architecture (методология построения)	03_knowledge/job-architecture-methodology.md	Вход для Уровня 1
JTBD → UI pipeline (аудитный подход)	03_knowledge/jtbd-to-ui-methodology.md	Альтернативный подход (проверка, не генерация)
SaaS best practices по JTBD	03_knowledge/job-architecture-saas-best-practices.md	Теоретическая база
Process Hierarchy L0–L3	03_knowledge/process-hierarchy-methodology-for-llm-and-roles.md	Домены для классификации jobs
JTBD Extraction Pipeline	03_knowledge/jtbd-extraction-pipeline-architecture.md	Источник raw JTBD
Slide Copywriter	skills/slide-copywriter/SKILL.md	Для презентации Screen Spec стейкхолдерам

---

Источники методологии

• Ulwick (ODI): Job Map → 8 шагов → Desired Outcomes. Основа для Уровня 3–4.
• Kalbach (JTBD Playbook): Job Hierarchy (Big → Little), Alignment Diagram. Основа для Уровня 1–2.
• Norman (Activity-Centered Design): Организация интерфейса вокруг деятельности, а не объектов.
• NN/g: Task-based navigation более устойчива, чем topic-based.
• Intercom: Job Stories → Circumstance-Driven Design. Основа для Уровня 5.