dzhokhov 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.
Что делать:
- Каждый Big Job = раздел верхнего уровня навигации.
- Если Big Job имеет 2+ подработы с принципиально разными контекстами — допускается подраздел.
- Навигация строится вокруг глаголов пользователя, не существительных системы.
Формат вывода:
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.
Что делать:
- Каждый значимый Little Job = один экран (или состояние экрана).
- Тривиальные Little Jobs (1 действие, 0 решений) могут быть элементом на экране родительского job, а не отдельным экраном.
- Если 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.
Что делать:
- Каждый шаг Job Map, где пользователю нужно совершить действие или принять решение = отдельное состояние экрана или шаг wizard'а.
- Шаги «Define» и «Locate» часто объединяются в начальный экран / форму.
- Шаги «Monitor» и «Modify» часто объединяются в рабочую панель.
- Шаг «Conclude» = экран подтверждения / результата.
- Порядок шагов 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.
Что делать:
- Каждый Desired Outcome порождает один или несколько UI-элементов, которые помогают пользователю достичь этого outcome.
- Outcome типа «Minimize X» → элемент, который показывает текущее значение X (для контроля).
- Outcome типа «Reduce time to Y» → автоматизация Y или shortcut к Y.
- 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).
Что делать:
- Определить, какие экраны выглядят по-разному для разных персон.
- Определить, какие обстоятельства (контексты) меняют содержание экрана.
- Вариант ≠ отдельный экран. Вариант = тот же экран, но с другим набором/приоритетом элементов.
Формат вывода:
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)
Как запускать скилл
Минимальный вход
Чтобы скилл заработал, нужен хотя бы один из:
- Job Architecture — структура Big Jobs → Little Jobs с outcomes. Идеально.
- Нормализованная JTBD-библиотека — список job statements с типами и персонами. Скилл построит иерархию сам.
- 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.
Антипаттерны (чего не делать)
Не рисуй интерфейс, а потом проверяй через jobs. Это аудит, не генерация. Если ловишь себя на фразе «а теперь проверим, покрыты ли jobs» — ты свернул не туда.
Не называй разделы существительными системы. «Баланс», «Отчёты», «Настройки» — это внутренняя модель данных. Пользователь думает глаголами: «Пополнить», «Понять, что происходит», «Настроить под себя».
Не создавай экран без job. Каждый экран должен отвечать на вопрос: «Какой job этот экран помогает выполнить?» Если ответа нет — экран не нужен.
Не ставь элементы «потому что так принято». Дашборд с графиками не нужен, если ни один outcome не требует визуализации тренда. Таблица не нужна, если job не включает сравнение множества объектов.
Не путай частоту 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.