# Jtbd To Interface > Генеративная трансформация JTBD в спецификацию интерфейса. Jobs порождают экраны, а не проверяют их. На входе: нормализованные JTBD (job statements, job maps, outcomes, персоны). На выходе: Screen Spec — какие экраны существуют, что на них, какой flow между ними, какие варианты по персонам. ОБЯЗАТЕЛЬНО используй этот скилл, когда пользователь просит: сгенерировать интерфейс из jobs, спроектировать экраны на основе JTBD, «какие экраны нужны для этих jobs», «превратить jobs в интерфейс», «от jobs к макетам», «interface from jobs», «screen spec из JTBD», «какие экраны вытекают из jobs», «jobs → навигация», «jobs → экраны», «сгенерируй UI-спеку из JTBD», «что должно быть на экране для этого job». Также используй, когда пользователь загружает файл с JTBD-библиотекой или Job Architecture и хочет получить структуру интерфейса. НЕ используй для аудита существующего интерфейса через JTBD-линзу — это другой подход (проверка, а не генерация). - Skill: `dzhokhov/jtbd-to-interface` (Agent Skill) - Install (CLI): `npx skillmds@latest add dzhokhov/jtbd-to-interface` - Raw SKILL.md: https://api.skillmd.com/api/skills/dzhokhov/jtbd-to-interface/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dzhokhov (https://skillmd.com/u/dzhokhov) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dzhokhov/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` со следующей структурой: ```markdown # 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.