code-ai-installer 3.0.0 → 4.0.1-a

package/domains/product/.agents/skills/design-brief/SKILL.md

@@ -1,418 +1,433 @@
----
-name: design-brief
-description: Бриф для UX/UI дизайнера — context, goals, users, constraints, references, tone
----
-# Design Brief
-
-> **Категория:** UX  ·  **Slug:** `design-brief`
-
-## Когда использовать
-
-- Когда UX Designer передаёт инициативу дальше (downstream visual designer или внешнему исполнителю).
-- Перед большим дизайн-циклом, чтобы согласовать цели + ограничения.
-- При работе с outsourced design — бриф как контракт.
-- При переходе от low-fi wireframes к hi-fi visual design.
-
-## Вход
-
-| Поле | Обязательно | Описание |
-|------|:-----------:|----------|
-| User story / PRD | ✅ | Что решаем |
-| User research findings | ✅ | JTBD, предпочтения, боли |
-| Brand guidelines | ⬚ | Если существуют |
-| Technical constraints | ⬚ | Стек, ограничения платформы |
-| References (конкуренты, вдохновение) | ⬚ | Визуальные / интерактивные референсы |
-
-## Источники данных
-
-1. `$prd-template` — scope + цели.
-2. `$jtbd-canvas` — эмоциональные/социальные jobs → тон.
-3. `$user-flow` — взаимодействия → необходимые экраны.
-4. Существующие brand guidelines / дизайн-система.
-
-### Связь с другими скилами
-
-| Скил | Что берём | Когда вызывать |
-|------|-----------|----------------|
-| `user-flow` | Шаги потока → экраны | Перед брифом |
-| `jtbd-canvas` | Эмоциональные jobs → тон | Для определения тона |
-| `prd-template` | Цели + NFR | Для секции целей брифа |
-| `report-design` | Паттерны макета (для PRD/deck, не UI) | Разделить контексты |
-
-## Структура Design Brief
-
-1. **Overview** — 1 абзац что делаем
-2. **Goals** — чего дизайн должен достичь
-3. **Users** — основные + вторичные персоны
-4. **Jobs & Emotions** — из JTBD
-5. **Scope** — экраны / поверхности
-6. **Non-goals** — явно вне scope
-7. **Constraints** — технические, brand, сроки
-8. **References** — конкуренты, вдохновение, стиль
-9. **Tone** — голос бренда, формальность
-10. **Deliverables** — wireframes? hi-fi? прототипы?
-11. **Timeline + Checkpoints**
-
-## Протокол
-
-### Шаг 1 — Overview
-
-1-2 абзаца:
-- Что это за инициатива (название функции)
-- Кто будет использовать
-- Почему это важно (бизнес + пользователь)
-
-### Шаг 2 — Goals (специфичные для дизайна)
-
-Отличать от целей PRD:
-- **Цель PRD:** «Увеличить активацию на 15%»
-- **Цель дизайна:** «Онбординг ощущается без усилий — пользователь завершает без подсказок»
-
-Цели дизайна в терминах восприятия пользователем + поведения.
-
-Примеры:
-- Сократить time-to-first-value с X до Y
-- Сделать настройки администратора доступными для нетехнических пользователей
-- Вызывать доверие у enterprise-покупателей
-
-### Шаг 3 — Users
-
-**Основной(ые) пользователь(и):**
-- Сегмент + роль
-- Ежедневный контекст (устройство, временное давление, совместная работа)
-- Техническая грамотность
-
-**Вторичные пользователи** (если применимо):
-- Кто ещё задействован в потоке
-- Различающиеся потребности/поведение
-
-### Шаг 4 — Jobs & Emotions
-
-Из JTBD canvas:
-- **Functional:** чего они пытаются достичь
-- **Emotional:** как хотят себя чувствовать (уверенно, в контроле, продуктивно)
-- **Social:** как хотят восприниматься
-
-Дизайн должен служить эмоциональным/социальным jobs, не только функциональным.
-
-### Шаг 5 — Scope
-
-Явный список:
-- **В scope:** экраны, состояния, взаимодействия
-- **Охват:** desktop / mobile / оба
-- **Пустые состояния, ошибочные состояния, состояния загрузки** (явное упоминание)
-- **Цели accessibility** (WCAG AA или AAA)
-
-### Шаг 6 — Non-goals
-
-Что **НЕ** делаем в этом брифе:
-- «Не обновляем всю дизайн-систему»
-- «Не поддерживаем mobile в этом релизе»
-- «Не оптимизируем для скрин-ридеров сверх WCAG AA»
-
-### Шаг 7 — Constraints
-
-**Технические:**
-- Component library (shadcn / Material / custom?)
-- Платформа (web / mobile / desktop)
-- Целевые браузеры / ОС
-- Бюджеты производительности
-
-**Brand:**
-- Цветовая система (основные, нейтральные)
-- Типографика (шрифты, масштаб)
-- Голос / личность
-
-**Сроки:**
-- Желаемое завершение
-- Доступные итерации ревью
-
-### Шаг 8 — References
-
-Визуальные + интерактивные источники вдохновения (3-5):
-- Скриншоты / ссылки на опыт конкурентов
-- Что работает (конкретные элементы для подражания)
-- Что избегать
-
-НЕ копирование — демонстрация понимания ожиданий категории.
-
-### Шаг 9 — Tone
-
-Оси тона B2B SaaS:
-- **Формальный ↔ Неформальный** (enterprise = более формальный)
-- **Игривый ↔ Серьёзный** (dev tools могут быть игривыми; compliance — серьёзный)
-- **Смелый ↔ Нейтральный**
-
-Выбрать позицию с обоснованием.
-
-Примеры:
-- «Профессиональный, но доступный» — mid-market B2B
-- «Серьёзно эффективный» — enterprise DevOps инструмент
-- «Уверенная экспертность» — security / compliance инструмент
-
-### Шаг 10 — Deliverables
-
-Указать что дизайнер произведёт:
-- **Low-fi wireframes:** [N экранов]
-- **Hi-fi mockups:** [N экранов]
-- **Интерактивный прототип:** [да / нет]
-- **Design specs для eng:** [Figma handoff? Zeplin?]
-- **Обновления компонентов:** [нужны ли новые компоненты?]
-
-### Шаг 11 — Timeline
-
-| Checkpoint | Дата | Участники |
-|-----------|------|--------------|
-| Подписание брифа | YYYY-MM-DD | PM, Design Lead |
-| Ревью wireframes | YYYY-MM-DD | PM, Eng Lead, Design |
-| Ревью hi-fi | YYYY-MM-DD | Вся команда + Стейкхолдер |
-| Финальный handoff | YYYY-MM-DD | Eng |
-
-## Валидация (Quality Gate)
-
-- [ ] Все 11 секций заполнены
-- [ ] Цели сформулированы в терминах результата для пользователя, не функции
-- [ ] Определены основные + вторичные пользователи
-- [ ] Эмоциональные/социальные jobs включены (не только функциональные)
-- [ ] Non-goals явны
-- [ ] Технические ограничения реалистичны
-- [ ] 3-5 референсов
-- [ ] Позиция тона с обоснованием
-- [ ] Deliverables указаны
-- [ ] Timeline с checkpoints
-
-## Handoff
-
-Результат является входом для:
-- **Downstream Designer** (visual designer / внешний)
-- **Tech Lead** → кросс-проверка технической реализуемости
-- **PM** → сессии дизайн-ревью
-
-Формат: документ design brief (markdown или связанный Figma файл). Через `$handoff`.
-
-## Anti-patterns
-
-| Ошибка | Почему плохо | Как правильно |
-|--------|-------------|---------------|
-| Нет jobs/emotions | Дизайн ощущается обезличенным | Явные эмоциональные/социальные jobs |
-| Расплывчатые цели («сделать лучше») | Не actionable | Конкретные результаты для пользователя |
-| Нет non-goals | Расползание scope | Явные исключения |
-| Тон «сделать красивым» | Не направляет | Оси тона с обоснованием |
-| Нет референсов | Дизайнер угадывает | 3-5 конкретных референсов |
-| Нет deliverables | Неоднозначный handoff | Явный список |
-| Нет checkpoints | Поздний feedback | Вехи |
-
-## Шаблон
-
-```markdown
-# Design Brief: [Название инициативы]
-
-## Overview
-...
-
-## Goals
-1. ...
-
-## Users
-**Primary:** [сегмент + роль + контекст]
-**Secondary:** [...]
-
-## Jobs & Emotions
-- Functional: ...
-- Emotional: чувствовать [X]
-- Social: восприниматься как [Y]
-
-## Scope
-- [экраны в scope]
-- Пустые / ошибочные / состояния загрузки: ✅
-
-## Non-goals
-- ...
-
-## Constraints
-- Technical: [стек]
-- Brand: [цвета, шрифты]
-- Timeline: [дедлайн]
-
-## References
-1. [конкурент] — [что работает]
-
-## Tone
-Формальный ↔ Неформальный: [позиция]
-Серьёзный ↔ Игривый: [позиция]
-
-## Deliverables
-- Low-fi: N экранов
-- Hi-fi: N экранов
-- Prototype: yes/no
-- Handoff: Figma
-
-## Timeline
-| Checkpoint | Дата |
-| Подписание брифа | YYYY-MM-DD |
-```
-
-## Worked Example — TeamFlow Design Brief: AI Summary Review Interface
-
-```markdown
-# Design Brief: AI Summary Review UI (Story S3)
-
-## Overview
-Разработать **интерфейс со стороны менеджера** для ревью, редактирования и утверждения AI-сгенерированных резюме встреч 1:1 в TeamFlow. Этот UI является ежедневной точкой контакта, где менеджеры взаимодействуют с AI-выводом — он определяет, будут ли они доверять функции, использовать её или бросят.
-
-UI ревью появляется после завершения генерации AI-резюме (согласно Story S2). Менеджер проводит здесь 2-5 минут на каждой встрече 1:1, просматривая, потенциально редактируя, затем утверждая. Этот опыт — **решающий момент** для принятия — если менеджеры не доверяют UI, они не будут доверять AI.
-
-## Goals (специфичные для дизайна, не цели PRD)
-
-1. **Менеджер чувствует, что UI создан ДЛЯ него, а не ПРОВЕРЯЕТ его.** Каждое взаимодействие подкрепляет «это ваш документ, вы управляете».
-2. **Трение редактирования < 30 секунд** для типичных правок (исправить имя, добавить пропущенный пункт действия).
-3. **Утверждение требует одного явного клика** — не проскальзывает случайно, не ощущается принуждением.
-4. **Сигналы уверенности чёткие:** извлечённые пункты действий с низкой уверенностью визуально отличаются, чтобы менеджер знал, что требует более тщательного ревью.
-5. **Сохраняет разговорный тон** резюме — ощущается написанным вдумчивым человеком, не «корпоративным ботом».
-
-## Users
-
-### Основной: перегруженный People Manager
-- **Сегмент:** B2B SaaS компании 100-1000 сотрудников (mid-market)
-- **Роль:** Engineering / Sales / Ops менеджер, 5-15 прямых подчинённых
-- **Контекст:** Просматривает резюме в течение 0-60 мин после окончания встречи, часто между другими встречами. Desktop основной, mobile вторичный (редко).
-- **Техническая грамотность:** Комфортно работает с редакторами rich text (ежедневные пользователи Notion / Google Docs). Не глубоко техничен.
-
-### Вторичный: HR Business Partner (Admin)
-- **Тот же UI в основном не используется** — их admin-опыт другой (Story S6).
-- Но граничный случай: иногда помогают новым менеджерам просматривать резюме → UI должен быть доступен для нерегулярных пользователей.
-
-## Jobs & Emotions
-
-### Functional Jobs (из JTBD canvas)
-- **F1:** Проверить резюме на точность за 2 минуты (у менеджера 6 мин между встречами)
-- **F2:** Отредактировать конкретные элементы (неверная атрибуция, пропущенный пункт) без переписывания всего
-- **F3:** Явно отметить утверждённым, чтобы пункты действий попали в трекинг
-
-### Emotional Jobs
-- **E1:** Чувствовать **уверенность** что понимаю, что AI зафиксировал (не запутаться от непрозрачного вывода)
-- **E2:** Чувствовать **контроль** — AI служит мне, я не служу странному формату AI
-- **E3:** Чувствовать **отсутствие слежки** — это мой черновик, я утверждаю то, что сохраняется
-
-### Social Jobs
-- **S1:** Восприниматься подчинённым (которому может быть поделено резюме) как вдумчивый конспектировщик
-- **S2:** Не восприниматься руководителем как небрежно утверждающий бессмыслицу
-
-## Scope
-
-### В scope для этого брифа:
-- **Основной экран ревью** (desktop + responsive mobile)
-  - Тело резюме (редактируемый rich text)
-  - Список пунктов действий (редактируемый, индикаторы уверенности)
-  - Список тем (редактируемый)
-  - CTA утверждения
-- **Состояния:** загрузка (стриминг резюме), загружено-черновик, в редактировании, утверждено
-- **Пустые / ошибочные состояния:** предупреждение о низком качестве резюме, запасной вариант при недоступности AI, пропуск резюме для очень короткой встречи
-
-### Вне scope (отдельные брифы или будущие фазы):
-- **Admin UI для org policy** (Story S6 — отдельный бриф)
-- **Агрегированный дашборд** (Theme 2 — отдельный PRD)
-- **Email-уведомления** (используют существующие шаблоны TeamFlow)
-- **Просмотрщик audit log** (только admin, уже существующий UI-паттерн)
-- **Нативное мобильное приложение** (только web responsive для MVP)
-
-## Non-goals (явные исключения)
-
-- Не «красивый» в декоративном смысле — **утилитарная элегантность** (думать Linear, не Dropbox Paper)
-- Не изобретать редактор заново — **использовать наш существующий ProseMirror-обёртку**
-- Не геймификация (серии / значки) — менеджеры ненавидят игривый HR-tech
-- Не «лайки» / «реакции» — резюме это **рабочий процесс**, не социальная сеть
-
-## Constraints
-
-### Технические
-- **Component library:** TeamFlow DS (внутренняя, на основе Radix)
-- **Editor:** Существующая ProseMirror-обёртка (переиспользовать, не заменять)
-- **Stack:** React / Next.js / TypeScript
-- **Целевые браузеры:** Chrome/Edge/Safari/Firefox последние 2 версии; IE не поддерживается
-- **Производительность:** Первая значимая отрисовка <500ms; редактор интерактивен <1s
-- **Responsive:** Desktop-first (1200px+), tablet поддерживается (768px), mobile функционально но не оптимизировано
-
-### Brand
-- **Цветовая система:** TeamFlow primary (deep blue #0A2540), accent (amber #F2A900), нейтральные
-- **Типографика:** Inter для body (переиспользовать существующий); Source Serif Pro для самого тела резюме (тонкое различие — «AI-вывод» визуально набранный)
-- **Голос:** Профессиональный, уверенный, не болтливый. «Проверьте ваше резюме», не «Эй! Посмотри на своё резюме ✨»
-
-### Сроки
-- Подписание брифа: Неделя 3, 17 апреля 2026
-- Ревью low-fi: Неделя 5, 1 мая
-- Ревью hi-fi: Неделя 7, 15 мая
-- Финальный handoff: Неделя 8, 22 мая
-- Реализация: Недели 7-10 параллельно с дизайном
-
-### Accessibility
-- **Требуется соответствие WCAG 2.1 AA** (требование mid-market+ enterprise клиентов)
-- Полная навигация с клавиатуры
-- Метки скрин-ридера для индикаторов уверенности
-- Контрастность цвета минимум 4.5:1 для текста
-
-## References
-
-1. **Notion AI summary UI** — отличное inline-редактирование, тонкая обработка уверенности. Подражать: чистое состояние редактора, переход состояния edit/approve.
-2. **Linear issue details** — утилитарный, плотный, без лишнего. Подражать: плотность информации без перегрузки.
-3. **Gmail smart compose** — хорошая визуализация уверенности (светло-серый = предложение). Подражать: обработка уверенности.
-4. **Что избегать — Otter.ai review UI:** слишком много декора, сложно сканировать, ощущается потребительским.
-5. **Текущий UI Lattice** — к чему привыкли клиенты. Сохранять последовательность там где возможно (размещение кнопок, формат списка пунктов действий).
-
-## Tone
-
-- **Формальный ↔ Неформальный:** Позиция = **60% формальный** (профессиональный, не болтливый; «Утвердить резюме», не «Всё ок!»)
-- **Серьёзный ↔ Игривый:** Позиция = **80% серьёзный** (HR-разговоры имеют вес; никакого конфетти, никаких emoji в UI-хроме)
-- **Смелый ↔ Нейтральный:** Позиция = **55% смелый** (уверенное использование основного цвета для ключевых действий, но не дизайнерски-кричащий)
-
-Обоснование: Discovery выявило, что менеджеры доверяют тону «тихой уверенности». Игривый тон рискует показаться «игрушечным» для enterprise + покупателей, чувствительных к соответствию.
-
-## Deliverables
-
-- **Low-fi wireframes:** 8 экранов (desktop + mobile responsive)
-  - Загрузка / стриминг резюме
-  - Ревью резюме — состояние по умолчанию
-  - Ревью резюме — режим редактирования
-  - Пункты действий — варианты уверенности (высокая / низкая)
-  - Состояние утверждённого (только чтение)
-  - Пустое состояние (встреча слишком короткая)
-  - Ошибочное состояние (AI недоступен)
-  - Mobile ревью (адаптация responsive desktop)
-- **Hi-fi mockups:** Те же 8 экранов в Figma с финальной типографикой, цветами, отступами
-- **Интерактивный прототип:** Кликабельный поток через Figma для тестирования юзабилити с бета-клиентами
-- **Design specs для eng:** Режим handoff Figma (измерения, ассеты, CSS-токены)
-- **Добавления компонентов:** 2 новых компонента в DS:
-  - `<ConfidenceIndicator />` — светло-серая пунктирная рамка для AI-контента с уверенностью ниже 70%
-  - `<SummaryApprovalActionBar />` — закреплённый снизу CTA утверждения с защитой от несохранённых изменений
-
-## Timeline
-
-| Checkpoint | Дата | Участники |
-|-----------|------|--------------|
-| Подписание брифа | 2026-04-17 | PM Alex, Design Lead Jordan, Eng Lead Priya |
-| Ревью информационной архитектуры | 2026-04-24 | PM + Eng + Design |
-| Ревью low-fi wireframes | 2026-05-01 | Вся команда + VP Product |
-| Тестирование юзабилити (5 клиентов) | 2026-05-08 | Design + PM + 5 внешних тестировщиков |
-| Ревью hi-fi mockup | 2026-05-15 | Вся команда |
-| Аудит accessibility | 2026-05-19 | Внешний a11y консультант |
-| Финальный handoff дизайна | 2026-05-22 | Команде Eng |
-| Implementation review (Неделя 2) | 2026-06-05 | Design в паре с eng еженедельно |
-
-## Risk & Mitigation
-
-| Риск | Митигация |
-|------|-----------|
-| Дизайн индикатора уверенности слишком тонкий → менеджеры не замечают AI-пункты низкого качества | Тест юзабилити Неделя 5 — валидировать что уверенность замечена |
-| Слишком заметный CTA утверждения ощущается «принуждающим» / «коэрсивным» | A/B тест двух размещений; держать более мягкий вариант готовым |
-| Слишком высокое трение режима редактирования → менеджеры принимают AI слепо | План итерации: если коэффициент редактирования <10% в бете, пересмотреть трение |
-| Mobile responsive неадекватен, enterprise жалуется | Ограничено web-only для MVP; план mobile-native Q4 доведён до сведения |
-
-## Измерение успеха (после запуска)
-
-- **Коэффициент редактирования:** 30-50% резюме отредактировано (не 0% = слепое утверждение; не 100% = AI бесполезен)
-- **Время до утверждения:** медиана ≤ 2 минут
-- **Коэффициент утверждения:** 95%+ сгенерированных резюме в итоге утверждены (не заброшены)
-- **Оценка юзабилити:** SUS >70 в бета-опросе
-```
-
-> **Урок design-brief:** Разделение **целей (специфичных для дизайна)** от целей PRD критично — цели PRD — это «40 апгрейдов тарифа», цели дизайна — «утверждение ощущается некоэрсивным». Без этого разделения дизайн становится реализацией функции. Секция **Non-goals** предотвращает расползание scope («не геймификация», «не заменять редактор»). Оси тона с обоснованием заставляют команду согласоваться вместо споров «не так ощущается» при hi-fi ревью. Бриф должен быть настолько полным, чтобы внешний дизайнер (аутсорсинговое агентство) мог выполнить работу по нему.
+---
+name: design-brief
+description: Бриф для UX/UI дизайнера — context, goals, users, constraints, references, tone
+type: triggered
+domain: product
+owners:
+  - ux_designer
+gates:
+  - UX_DESIGNER
+tech: []
+topic: []
+triggers:
+  - "design-brief"
+  - "design brief"
+  - "бриф дизайнера"
+related: []
+budget_lines: 433
+schema_version: 1
+---
+# Design Brief
+
+> **Категория:** UX  ·  **Slug:** `design-brief`
+
+## Когда использовать
+
+- Когда UX Designer передаёт инициативу дальше (downstream visual designer или внешнему исполнителю).
+- Перед большим дизайн-циклом, чтобы согласовать цели + ограничения.
+- При работе с outsourced design — бриф как контракт.
+- При переходе от low-fi wireframes к hi-fi visual design.
+
+## Вход
+
+| Поле | Обязательно | Описание |
+|------|:-----------:|----------|
+| User story / PRD | ✅ | Что решаем |
+| User research findings | ✅ | JTBD, предпочтения, боли |
+| Brand guidelines | ⬚ | Если существуют |
+| Technical constraints | ⬚ | Стек, ограничения платформы |
+| References (конкуренты, вдохновение) | ⬚ | Визуальные / интерактивные референсы |
+
+## Источники данных
+
+1. `$prd-template` — scope + цели.
+2. `$jtbd-canvas` — эмоциональные/социальные jobs → тон.
+3. `$user-flow` — взаимодействия → необходимые экраны.
+4. Существующие brand guidelines / дизайн-система.
+
+### Связь с другими скилами
+
+| Скил | Что берём | Когда вызывать |
+|------|-----------|----------------|
+| `user-flow` | Шаги потока → экраны | Перед брифом |
+| `jtbd-canvas` | Эмоциональные jobs → тон | Для определения тона |
+| `prd-template` | Цели + NFR | Для секции целей брифа |
+| `report-design` | Паттерны макета (для PRD/deck, не UI) | Разделить контексты |
+
+## Структура Design Brief
+
+1. **Overview** — 1 абзац что делаем
+2. **Goals** — чего дизайн должен достичь
+3. **Users** — основные + вторичные персоны
+4. **Jobs & Emotions** — из JTBD
+5. **Scope** — экраны / поверхности
+6. **Non-goals** — явно вне scope
+7. **Constraints** — технические, brand, сроки
+8. **References** — конкуренты, вдохновение, стиль
+9. **Tone** — голос бренда, формальность
+10. **Deliverables** — wireframes? hi-fi? прототипы?
+11. **Timeline + Checkpoints**
+
+## Протокол
+
+### Шаг 1 — Overview
+
+1-2 абзаца:
+- Что это за инициатива (название функции)
+- Кто будет использовать
+- Почему это важно (бизнес + пользователь)
+
+### Шаг 2 — Goals (специфичные для дизайна)
+
+Отличать от целей PRD:
+- **Цель PRD:** «Увеличить активацию на 15%»
+- **Цель дизайна:** «Онбординг ощущается без усилий — пользователь завершает без подсказок»
+
+Цели дизайна в терминах восприятия пользователем + поведения.
+
+Примеры:
+- Сократить time-to-first-value с X до Y
+- Сделать настройки администратора доступными для нетехнических пользователей
+- Вызывать доверие у enterprise-покупателей
+
+### Шаг 3 — Users
+
+**Основной(ые) пользователь(и):**
+- Сегмент + роль
+- Ежедневный контекст (устройство, временное давление, совместная работа)
+- Техническая грамотность
+
+**Вторичные пользователи** (если применимо):
+- Кто ещё задействован в потоке
+- Различающиеся потребности/поведение
+
+### Шаг 4 — Jobs & Emotions
+
+Из JTBD canvas:
+- **Functional:** чего они пытаются достичь
+- **Emotional:** как хотят себя чувствовать (уверенно, в контроле, продуктивно)
+- **Social:** как хотят восприниматься
+
+Дизайн должен служить эмоциональным/социальным jobs, не только функциональным.
+
+### Шаг 5 — Scope
+
+Явный список:
+- **В scope:** экраны, состояния, взаимодействия
+- **Охват:** desktop / mobile / оба
+- **Пустые состояния, ошибочные состояния, состояния загрузки** (явное упоминание)
+- **Цели accessibility** (WCAG AA или AAA)
+
+### Шаг 6 — Non-goals
+
+Что **НЕ** делаем в этом брифе:
+- «Не обновляем всю дизайн-систему»
+- «Не поддерживаем mobile в этом релизе»
+- «Не оптимизируем для скрин-ридеров сверх WCAG AA»
+
+### Шаг 7 — Constraints
+
+**Технические:**
+- Component library (shadcn / Material / custom?)
+- Платформа (web / mobile / desktop)
+- Целевые браузеры / ОС
+- Бюджеты производительности
+
+**Brand:**
+- Цветовая система (основные, нейтральные)
+- Типографика (шрифты, масштаб)
+- Голос / личность
+
+**Сроки:**
+- Желаемое завершение
+- Доступные итерации ревью
+
+### Шаг 8 — References
+
+Визуальные + интерактивные источники вдохновения (3-5):
+- Скриншоты / ссылки на опыт конкурентов
+- Что работает (конкретные элементы для подражания)
+- Что избегать
+
+НЕ копирование — демонстрация понимания ожиданий категории.
+
+### Шаг 9 — Tone
+
+Оси тона B2B SaaS:
+- **Формальный ↔ Неформальный** (enterprise = более формальный)
+- **Игривый ↔ Серьёзный** (dev tools могут быть игривыми; compliance — серьёзный)
+- **Смелый ↔ Нейтральный**
+
+Выбрать позицию с обоснованием.
+
+Примеры:
+- «Профессиональный, но доступный» — mid-market B2B
+- «Серьёзно эффективный» — enterprise DevOps инструмент
+- «Уверенная экспертность» — security / compliance инструмент
+
+### Шаг 10 — Deliverables
+
+Указать что дизайнер произведёт:
+- **Low-fi wireframes:** [N экранов]
+- **Hi-fi mockups:** [N экранов]
+- **Интерактивный прототип:** [да / нет]
+- **Design specs для eng:** [Figma handoff? Zeplin?]
+- **Обновления компонентов:** [нужны ли новые компоненты?]
+
+### Шаг 11 — Timeline
+
+| Checkpoint | Дата | Участники |
+|-----------|------|--------------|
+| Подписание брифа | YYYY-MM-DD | PM, Design Lead |
+| Ревью wireframes | YYYY-MM-DD | PM, Eng Lead, Design |
+| Ревью hi-fi | YYYY-MM-DD | Вся команда + Стейкхолдер |
+| Финальный handoff | YYYY-MM-DD | Eng |
+
+## Валидация (Quality Gate)
+
+- [ ] Все 11 секций заполнены
+- [ ] Цели сформулированы в терминах результата для пользователя, не функции
+- [ ] Определены основные + вторичные пользователи
+- [ ] Эмоциональные/социальные jobs включены (не только функциональные)
+- [ ] Non-goals явны
+- [ ] Технические ограничения реалистичны
+- [ ] 3-5 референсов
+- [ ] Позиция тона с обоснованием
+- [ ] Deliverables указаны
+- [ ] Timeline с checkpoints
+
+## Handoff
+
+Результат является входом для:
+- **Downstream Designer** (visual designer / внешний)
+- **Tech Lead** → кросс-проверка технической реализуемости
+- **PM** → сессии дизайн-ревью
+
+Формат: документ design brief (markdown или связанный Figma файл). Через `$handoff`.
+
+## Anti-patterns
+
+| Ошибка | Почему плохо | Как правильно |
+|--------|-------------|---------------|
+| Нет jobs/emotions | Дизайн ощущается обезличенным | Явные эмоциональные/социальные jobs |
+| Расплывчатые цели («сделать лучше») | Не actionable | Конкретные результаты для пользователя |
+| Нет non-goals | Расползание scope | Явные исключения |
+| Тон «сделать красивым» | Не направляет | Оси тона с обоснованием |
+| Нет референсов | Дизайнер угадывает | 3-5 конкретных референсов |
+| Нет deliverables | Неоднозначный handoff | Явный список |
+| Нет checkpoints | Поздний feedback | Вехи |
+
+## Шаблон
+
+```markdown
+# Design Brief: [Название инициативы]
+
+## Overview
+...
+
+## Goals
+1. ...
+
+## Users
+**Primary:** [сегмент + роль + контекст]
+**Secondary:** [...]
+
+## Jobs & Emotions
+- Functional: ...
+- Emotional: чувствовать [X]
+- Social: восприниматься как [Y]
+
+## Scope
+- [экраны в scope]
+- Пустые / ошибочные / состояния загрузки: ✅
+
+## Non-goals
+- ...
+
+## Constraints
+- Technical: [стек]
+- Brand: [цвета, шрифты]
+- Timeline: [дедлайн]
+
+## References
+1. [конкурент] — [что работает]
+
+## Tone
+Формальный ↔ Неформальный: [позиция]
+Серьёзный ↔ Игривый: [позиция]
+
+## Deliverables
+- Low-fi: N экранов
+- Hi-fi: N экранов
+- Prototype: yes/no
+- Handoff: Figma
+
+## Timeline
+| Checkpoint | Дата |
+| Подписание брифа | YYYY-MM-DD |
+```
+
+## Worked Example — TeamFlow Design Brief: AI Summary Review Interface
+
+```markdown
+# Design Brief: AI Summary Review UI (Story S3)
+
+## Overview
+Разработать **интерфейс со стороны менеджера** для ревью, редактирования и утверждения AI-сгенерированных резюме встреч 1:1 в TeamFlow. Этот UI является ежедневной точкой контакта, где менеджеры взаимодействуют с AI-выводом — он определяет, будут ли они доверять функции, использовать её или бросят.
+
+UI ревью появляется после завершения генерации AI-резюме (согласно Story S2). Менеджер проводит здесь 2-5 минут на каждой встрече 1:1, просматривая, потенциально редактируя, затем утверждая. Этот опыт — **решающий момент** для принятия — если менеджеры не доверяют UI, они не будут доверять AI.
+
+## Goals (специфичные для дизайна, не цели PRD)
+
+1. **Менеджер чувствует, что UI создан ДЛЯ него, а не ПРОВЕРЯЕТ его.** Каждое взаимодействие подкрепляет «это ваш документ, вы управляете».
+2. **Трение редактирования < 30 секунд** для типичных правок (исправить имя, добавить пропущенный пункт действия).
+3. **Утверждение требует одного явного клика** — не проскальзывает случайно, не ощущается принуждением.
+4. **Сигналы уверенности чёткие:** извлечённые пункты действий с низкой уверенностью визуально отличаются, чтобы менеджер знал, что требует более тщательного ревью.
+5. **Сохраняет разговорный тон** резюме — ощущается написанным вдумчивым человеком, не «корпоративным ботом».
+
+## Users
+
+### Основной: перегруженный People Manager
+- **Сегмент:** B2B SaaS компании 100-1000 сотрудников (mid-market)
+- **Роль:** Engineering / Sales / Ops менеджер, 5-15 прямых подчинённых
+- **Контекст:** Просматривает резюме в течение 0-60 мин после окончания встречи, часто между другими встречами. Desktop основной, mobile вторичный (редко).
+- **Техническая грамотность:** Комфортно работает с редакторами rich text (ежедневные пользователи Notion / Google Docs). Не глубоко техничен.
+
+### Вторичный: HR Business Partner (Admin)
+- **Тот же UI в основном не используется** — их admin-опыт другой (Story S6).
+- Но граничный случай: иногда помогают новым менеджерам просматривать резюме → UI должен быть доступен для нерегулярных пользователей.
+
+## Jobs & Emotions
+
+### Functional Jobs (из JTBD canvas)
+- **F1:** Проверить резюме на точность за 2 минуты (у менеджера 6 мин между встречами)
+- **F2:** Отредактировать конкретные элементы (неверная атрибуция, пропущенный пункт) без переписывания всего
+- **F3:** Явно отметить утверждённым, чтобы пункты действий попали в трекинг
+
+### Emotional Jobs
+- **E1:** Чувствовать **уверенность** что понимаю, что AI зафиксировал (не запутаться от непрозрачного вывода)
+- **E2:** Чувствовать **контроль** — AI служит мне, я не служу странному формату AI
+- **E3:** Чувствовать **отсутствие слежки** — это мой черновик, я утверждаю то, что сохраняется
+
+### Social Jobs
+- **S1:** Восприниматься подчинённым (которому может быть поделено резюме) как вдумчивый конспектировщик
+- **S2:** Не восприниматься руководителем как небрежно утверждающий бессмыслицу
+
+## Scope
+
+### В scope для этого брифа:
+- **Основной экран ревью** (desktop + responsive mobile)
+  - Тело резюме (редактируемый rich text)
+  - Список пунктов действий (редактируемый, индикаторы уверенности)
+  - Список тем (редактируемый)
+  - CTA утверждения
+- **Состояния:** загрузка (стриминг резюме), загружено-черновик, в редактировании, утверждено
+- **Пустые / ошибочные состояния:** предупреждение о низком качестве резюме, запасной вариант при недоступности AI, пропуск резюме для очень короткой встречи
+
+### Вне scope (отдельные брифы или будущие фазы):
+- **Admin UI для org policy** (Story S6 — отдельный бриф)
+- **Агрегированный дашборд** (Theme 2 — отдельный PRD)
+- **Email-уведомления** (используют существующие шаблоны TeamFlow)
+- **Просмотрщик audit log** (только admin, уже существующий UI-паттерн)
+- **Нативное мобильное приложение** (только web responsive для MVP)
+
+## Non-goals (явные исключения)
+
+- Не «красивый» в декоративном смысле — **утилитарная элегантность** (думать Linear, не Dropbox Paper)
+- Не изобретать редактор заново — **использовать наш существующий ProseMirror-обёртку**
+- Не геймификация (серии / значки) — менеджеры ненавидят игривый HR-tech
+- Не «лайки» / «реакции» — резюме это **рабочий процесс**, не социальная сеть
+
+## Constraints
+
+### Технические
+- **Component library:** TeamFlow DS (внутренняя, на основе Radix)
+- **Editor:** Существующая ProseMirror-обёртка (переиспользовать, не заменять)
+- **Stack:** React / Next.js / TypeScript
+- **Целевые браузеры:** Chrome/Edge/Safari/Firefox последние 2 версии; IE не поддерживается
+- **Производительность:** Первая значимая отрисовка <500ms; редактор интерактивен <1s
+- **Responsive:** Desktop-first (1200px+), tablet поддерживается (768px), mobile функционально но не оптимизировано
+
+### Brand
+- **Цветовая система:** TeamFlow primary (deep blue #0A2540), accent (amber #F2A900), нейтральные
+- **Типографика:** Inter для body (переиспользовать существующий); Source Serif Pro для самого тела резюме (тонкое различие — «AI-вывод» визуально набранный)
+- **Голос:** Профессиональный, уверенный, не болтливый. «Проверьте ваше резюме», не «Эй! Посмотри на своё резюме ✨»
+
+### Сроки
+- Подписание брифа: Неделя 3, 17 апреля 2026
+- Ревью low-fi: Неделя 5, 1 мая
+- Ревью hi-fi: Неделя 7, 15 мая
+- Финальный handoff: Неделя 8, 22 мая
+- Реализация: Недели 7-10 параллельно с дизайном
+
+### Accessibility
+- **Требуется соответствие WCAG 2.1 AA** (требование mid-market+ enterprise клиентов)
+- Полная навигация с клавиатуры
+- Метки скрин-ридера для индикаторов уверенности
+- Контрастность цвета минимум 4.5:1 для текста
+
+## References
+
+1. **Notion AI summary UI** — отличное inline-редактирование, тонкая обработка уверенности. Подражать: чистое состояние редактора, переход состояния edit/approve.
+2. **Linear issue details** — утилитарный, плотный, без лишнего. Подражать: плотность информации без перегрузки.
+3. **Gmail smart compose** — хорошая визуализация уверенности (светло-серый = предложение). Подражать: обработка уверенности.
+4. **Что избегать — Otter.ai review UI:** слишком много декора, сложно сканировать, ощущается потребительским.
+5. **Текущий UI Lattice** — к чему привыкли клиенты. Сохранять последовательность там где возможно (размещение кнопок, формат списка пунктов действий).
+
+## Tone
+
+- **Формальный ↔ Неформальный:** Позиция = **60% формальный** (профессиональный, не болтливый; «Утвердить резюме», не «Всё ок!»)
+- **Серьёзный ↔ Игривый:** Позиция = **80% серьёзный** (HR-разговоры имеют вес; никакого конфетти, никаких emoji в UI-хроме)
+- **Смелый ↔ Нейтральный:** Позиция = **55% смелый** (уверенное использование основного цвета для ключевых действий, но не дизайнерски-кричащий)
+
+Обоснование: Discovery выявило, что менеджеры доверяют тону «тихой уверенности». Игривый тон рискует показаться «игрушечным» для enterprise + покупателей, чувствительных к соответствию.
+
+## Deliverables
+
+- **Low-fi wireframes:** 8 экранов (desktop + mobile responsive)
+  - Загрузка / стриминг резюме
+  - Ревью резюме — состояние по умолчанию
+  - Ревью резюме — режим редактирования
+  - Пункты действий — варианты уверенности (высокая / низкая)
+  - Состояние утверждённого (только чтение)
+  - Пустое состояние (встреча слишком короткая)
+  - Ошибочное состояние (AI недоступен)
+  - Mobile ревью (адаптация responsive desktop)
+- **Hi-fi mockups:** Те же 8 экранов в Figma с финальной типографикой, цветами, отступами
+- **Интерактивный прототип:** Кликабельный поток через Figma для тестирования юзабилити с бета-клиентами
+- **Design specs для eng:** Режим handoff Figma (измерения, ассеты, CSS-токены)
+- **Добавления компонентов:** 2 новых компонента в DS:
+  - `<ConfidenceIndicator />` — светло-серая пунктирная рамка для AI-контента с уверенностью ниже 70%
+  - `<SummaryApprovalActionBar />` — закреплённый снизу CTA утверждения с защитой от несохранённых изменений
+
+## Timeline
+
+| Checkpoint | Дата | Участники |
+|-----------|------|--------------|
+| Подписание брифа | 2026-04-17 | PM Alex, Design Lead Jordan, Eng Lead Priya |
+| Ревью информационной архитектуры | 2026-04-24 | PM + Eng + Design |
+| Ревью low-fi wireframes | 2026-05-01 | Вся команда + VP Product |
+| Тестирование юзабилити (5 клиентов) | 2026-05-08 | Design + PM + 5 внешних тестировщиков |
+| Ревью hi-fi mockup | 2026-05-15 | Вся команда |
+| Аудит accessibility | 2026-05-19 | Внешний a11y консультант |
+| Финальный handoff дизайна | 2026-05-22 | Команде Eng |
+| Implementation review (Неделя 2) | 2026-06-05 | Design в паре с eng еженедельно |
+
+## Risk & Mitigation
+
+| Риск | Митигация |
+|------|-----------|
+| Дизайн индикатора уверенности слишком тонкий → менеджеры не замечают AI-пункты низкого качества | Тест юзабилити Неделя 5 — валидировать что уверенность замечена |
+| Слишком заметный CTA утверждения ощущается «принуждающим» / «коэрсивным» | A/B тест двух размещений; держать более мягкий вариант готовым |
+| Слишком высокое трение режима редактирования → менеджеры принимают AI слепо | План итерации: если коэффициент редактирования <10% в бете, пересмотреть трение |
+| Mobile responsive неадекватен, enterprise жалуется | Ограничено web-only для MVP; план mobile-native Q4 доведён до сведения |
+
+## Измерение успеха (после запуска)
+
+- **Коэффициент редактирования:** 30-50% резюме отредактировано (не 0% = слепое утверждение; не 100% = AI бесполезен)
+- **Время до утверждения:** медиана ≤ 2 минут
+- **Коэффициент утверждения:** 95%+ сгенерированных резюме в итоге утверждены (не заброшены)
+- **Оценка юзабилити:** SUS >70 в бета-опросе
+```
+
+> **Урок design-brief:** Разделение **целей (специфичных для дизайна)** от целей PRD критично — цели PRD — это «40 апгрейдов тарифа», цели дизайна — «утверждение ощущается некоэрсивным». Без этого разделения дизайн становится реализацией функции. Секция **Non-goals** предотвращает расползание scope («не геймификация», «не заменять редактор»). Оси тона с обоснованием заставляют команду согласоваться вместо споров «не так ощущается» при hi-fi ревью. Бриф должен быть настолько полным, чтобы внешний дизайнер (аутсорсинговое агентство) мог выполнить работу по нему.