Дизайн, который не ломает сценарий

После модуля 11 у Бориса есть первый рабочий экран JobTrack.

Продукт открывается, сценарий проходит от начала до конца — Борис сам прокликал и убедился. Радоваться рано.

Экран сырой. Это технический черновик: стандартный вариант, который накидал агент, вроде работает — но пользоваться им противно. Иерархии нет, отступы случайные, кнопки спорят друг с другом, длинная вакансия ломает строку.

И прям тянет написать агенту:

Сделай хороший frontend.

Борис останавливается.

Потому что это та же ошибка, что и с продуктом: без проектирования агент начнёт угадывать вкус. Это как сказать стажёру «сделай красиво», не объяснив ни слова про то, что вообще нужно, — и он притащит всё, что когда-либо видел: градиенты, карточки, случайный dashboard, фильтры, тени, свежий sidebar.

Выглядит богаче, но текущий сценарий становится хуже.

Короче, рабочая версия у Бориса уже есть. И дизайн теперь либо помогает читать экран и пройти сценарий, либо идёт лесом.

Поэтому Борис не пишет «сделай хороший frontend». Сначала — что на экране главное. А иначе агент накидает компонентов и сделает вид, что так и было задумано.

В модуле 12 мы не просим агента сделай красиво. Это плохая формулировка: звучит безобидно, а на деле агент начинает угадывать вкус, рисовать настроение и протаскивать новые функции.

После m11 у тебя уже есть working slice. Первый сценарий MVP проходит. Теперь его надо довести до состояния, когда им можно пользоваться: понятный экран, нормальная плотность, читаемые состояния, аккуратный frontend без расширения продукта.

Поэтому дизайн идёт через тот же принцип SPP: сначала design, потом spec, потом implementation.

Почему дизайн нельзя делать одной задачей

UI — это не слой лака поверх продукта. Это проектирование того, как человек видит задачу, принимает решение и понимает результат.

Плохой prompt:

Сделай красиво.

Тут нет ничего, за что можно зацепиться: красиво для кого, на каком рынке, в каком жанре, с какой плотностью данных, какой главный action, какие состояния нужны, какие функции нельзя добавлять и как принимать результат.

Без этого агент рисует не интерфейс, а настроение. Симпатичное, может быть. Но продукту от красивого настроения легче не становится.

Нормальный дизайн-процесс отвечает на другие вопросы:

• кто будет пользоваться экраном;
• какие задачи он решает;
• какие интерфейсы рынка уже сформировали ожидания;
• какая визуальная плотность нужна;
• какой главный action;
• какие состояния должны быть спроектированы;
• какие правила нельзя нарушать.

Важно: спроектировать состояние — не то же самое, что добавить поведение. В m12 можно и нужно описывать empty state, ошибку валидации, success state, long text, mobile и focus. Но нельзя менять data model, добавлять новые сценарии и тихо возвращать фичи из будущих модулей.

Loading тоже не рисуется по привычке. Если стек на localStorage, сохранение мгновенное, значит loading для сохранения не проектируем и честно это пишем. Для асинхронного стека — сеть, база, API — loading уже нужен.

Как использовать SPP для дизайна

SPP здесь нужен не как магическая кнопка, а как процесс, который не даёт прыгнуть сразу в CSS.

Дизайн в SPP — это standalone-хелперы accessibility, mobile-version, ux-copywriting плюс /spp как вход в design workflow, а не номерная фаза. Отдельного SPP-скилла frontend-design нет.

Prompt:

Используй /spp.
Мы делаем frontend для моего проекта.

Контекст:
- есть working slice после m11;
- продукт и аудитория описаны в docs/discovery.md и docs/design.md;
- первый сценарий MVP уже проходит после m11;
- задача: улучшить frontend без новых функций.

Нужен design workflow:
1. собрать 5-7 референсов рынка;
2. извлечь из них принципы;
3. предложить 2-3 visual directions;
4. выбрать направление;
5. собрать минимальную дизайн-систему;
6. написать дизайн-спеку;
7. только потом реализовать UI по спецификации.

Код пока не меняй.

Если агент сразу пишет CSS, он перескочил дизайн. Останови его и верни к workflow.

Если агент умеет пользоваться web или браузером, референсы должны быть source-backed: URL, дата проверки и что именно посмотрено. Если web-доступа нет, агент обязан явно написать: это не ресерч, а известные UI-паттерны из памяти; такие паттерны можно использовать для черновика, но нельзя выдавать за исследование рынка.

Референсы рынка

Референсы нужны не для копирования внешнего вида. Они нужны, чтобы понять жанр интерфейса и ожидания пользователя.

Для JobTrack можно смотреть:

• Trello или Linear — списки, статусы, плотная рабочая навигация;
• GitHub Issues — длинные названия, метаданные, статусы, фильтрация без шума;
• Notion database — таблицы и списки с большим количеством строк;
• простые ATS/CRM-интерфейсы — pipeline, статусы, следующий шаг;
• job search trackers или kanban templates — как люди ведут поиск работы.

Prompt для агента:

Помоги собрать референсы для дизайна JobTrack.

Контекст:
- продукт для отслеживания поиска работы;
- аудитория: человек, который ведёт вакансии, статусы, заметки и следующие шаги;
- нужен рабочий интерфейс, не лендинг;
- первый MVP без auth/search/import/tags.

Если у тебя есть web/browser access:
- найди 5-7 реальных референсов;
- дай URL;
- укажи дату проверки;
- коротко опиши, какой экран или паттерн смотрел.

Если web/browser access нет:
- не выдумывай ссылки;
- пометь раздел как known UI patterns, not market research;
- используй только общеизвестные паттерны и явно скажи, что их надо проверить позже.

Для каждого выпиши:
- почему он релевантен;
- что можно взять как принцип;
- что нельзя копировать;
- какие риски для JobTrack.

После этого сгруппируй референсы в 2-3 visual directions.

Хороший результат — не список ссылок ради галочки, а проверяемые источники плюс принципы. Если источников нет, это не провал, но это должно быть честно написано.

Visual directions

После референсов нужно выбрать направление. Не настроение, не любимый цвет, а рабочую гипотезу интерфейса.

Пример для JobTrack:

Direction A. Quiet productivity tool
- плотный список;
- нейтральный фон;
- один accent для add/primary action;
- статусы читаются, но не кричат;
- подходит, если JobTrack - ежедневный рабочий инструмент.

Direction B. Personal job board
- чуть больше воздуха;
- карточки вакансий;
- мягкие empty states;
- подходит, если продукт больше про личный порядок, чем про поток задач.

Direction C. CRM-lite pipeline
- колонки или stages;
- сильный акцент на status/next step;
- подходит, если главный сценарий - вести воронку.

Выбор направления должен быть связан с docs/design.md, а не с настроением. Если MVP — личный трекер вакансий, не надо внезапно строить тяжёлую CRM. Будет богаче, но мимо задачи.

Мини-дизайн-система

Перед UI-реализацией нужна мини-дизайн-система. Не Figma на 200 компонентов, а короткий набор правил, по которому агент соберёт одинаковый интерфейс.

Минимум:

• typography: базовый размер текста, заголовки, метаданные, line-height;
• colors: фон, текст, muted text, border, accent, danger/success;
• spacing: шаг отступов и плотность списка;
• radius: единое скругление;
• borders/shadows: как отделяются блоки;
• icons: где нужны иконки, а где текст понятнее;
• components: button, input, list row/card, status badge, empty state, error state;
• states: empty, loading, error, success, one item, many items, long text, mobile, focus;
• states кнопок: hover, active, disabled — как кнопка выглядит при наведении, нажатии и когда недоступна;
• ошибки валидации формы: как показывается, что поле обязательно или заполнено неверно.

Prompt:

На основе выбранного visual direction собери мини-дизайн-систему JobTrack.

Нужно:
- typography;
- colors;
- spacing;
- radius;
- borders/shadows;
- icon usage;
- базовые components;
- states to support;
- constraints: no new features, keep behavior, no auth/search/import/tags.

Формат: короткая дизайн-спека, которую можно дать агенту для реализации.

Плохая и хорошая мини-дизайн-система

Плохая версия:

Дизайн: современный, чистый, удобный.
Цвета: приятные.
Кнопки: красивые.
Отступы: нормальные.

Это туман в банке, а не спека.

Хорошая версия:

Typography: базовый текст 16px, заголовки 20px, метаданные 13px muted, line-height 1.5.
Colors: фон #FFFFFF, текст #1A1A1A, muted #6B7280, border #E5E7EB, accent #2563EB, danger #DC2626, success #16A34A.
Spacing: шаг 8px, плотность списка - высота строки вакансии ~56px.
Radius: 8px для карточек и кнопок.
Button: primary - accent-фон/белый текст; hover - темнее на 10%; disabled - серый, cursor not-allowed.
Ошибка валидации: текст #DC2626 под полем, само поле с красной рамкой.

По второй версии агент соберёт предсказуемый интерфейс. По первой — сочинит свой.

Дизайн-спека

Дизайн-спека — это мост между вкусом и кодом. Она переводит эстетическое решение в проверяемые правила.

В ней должны быть:

• выбранное направление;
• референсы и извлечённые принципы;
• мини-дизайн-система;
• правила layout;
• реальные данные для проверки;
• states;
• accessibility baseline: контраст текста к фону не ниже 4.5:1, видимый focus у полей и кнопок, target size кликабельных элементов от 40px, ошибка не только цветом. Подробнее — в дополнительном материале «Доступность за 20 минут»;
• запреты на scope creep;
• acceptance criteria.

Пример структуры:

# UI Design Spec

## Direction
Quiet productivity tool.

## References and principles
- Linear: density, calm borders, no decorative noise.
- GitHub Issues: long text and metadata hierarchy.
- Notion database: simple typography, many rows.

## Mini design system
- typography:
- colors:
- spacing:
- radius:
- borders/shadows:
- icons:
- components:

## States
- empty:
- 1 item:
- many items:
- long text:
- loading/error/success:
- mobile:
- keyboard/focus:

## Constraints
- keep behavior from m11;
- no new features;
- no auth/search/import/tags;
- no data model changes.

## Acceptance criteria
- основной сценарий m11 проходит;
- экран читается на real data;
- long text не ломает layout;
- primary action очевиден;
- diff UI-only.

Реализация по дизайн-спеке

Только после принятой дизайн-спеки можно просить агента менять UI.

Prompt:

Прочитай docs/design.md, docs/plan.md, docs/todo.md и UI Design Spec.

Используй SPP workflow: сначала подтверди scope, потом реализуй UI по дизайн-спеке.

Задача:
- применить мини-дизайн-систему;
- улучшить layout, typography, spacing, colors, states;
- сохранить поведение из m11.

Запреты:
- no new features;
- no auth/search/import/tags;
- no data model changes;
- no random dashboard;
- no behavior changes.

После правок:
- запусти smoke check;
- запусти tests или documented manual fallback;
- пройди manual scenario из m11;
- проверь states из UI Design Spec;
- покажи diff и подтверди, что он UI-only.

Как принимать дизайн

Приёмка дизайна — не нравится / не нравится. Проверка конкретная:

• выбранное направление видно в интерфейсе;
• мини-дизайн-система применена последовательно;
• основной сценарий m11 не сломан;
• empty/loading/error/success состояния понятны;
• long text не ломает layout;
• mobile не ломает главный action;
• keyboard/focus не потерялись;
• реальные русские данные выглядят нормально;
• diff не содержит новых функций.

Если UI стал приятнее, но сценарий хуже, задача провалена.

Что делать после

После принятого UI task обнови docs/todo.md и зафиксируй commit boundary.

Если во время дизайна появились идеи про search, tags, dashboard или аналитику, не добавляй их в этот slice. Запиши в backlog. Дизайн не должен тихо расширять продукт.

Цель практики — спроектировать дизайн моего проекта и реализовать его без расширения scope. Не чинить всё подряд, не строить новый продукт, не добавлять функции. Только дизайн текущего сценария.

Шаг 1. Проверь baseline после m11

Перед дизайном убедись, что первый task работает:

• smoke check проходит;
• tests или documented manual fallback подтверждают поведение;
• manual scenario из m11 проходит.

Основной сценарий моего проекта должен проходить руками ещё в модуле 11 (шаг «Повтори цикл до рабочего сценария»): добавить вакансию, увидеть её в списке, изменить статус. Если этого нет, вернись в модуль 11 и доведи сценарий, прежде чем заниматься дизайном.

Если baseline сломан, не начинай UI. Сначала верни рабочий slice. Красивый интерфейс поверх сломанного сценария — это косметика на аварии.

Заведи дизайн-slice как задачу. Чтобы не ломать правило модуля 11 (одна задача из todo), добавь дизайн текущего сценария отдельной задачей в docs/plan.md и current в docs/todo.md. Тогда UI-работа — это обычный task с границей и rollback, а не «перерисуем всё заодно».

Шаг 2. Запусти workflow в design Superpower

Prompt:

Используй /spp.
Мы проектируем дизайн для моего проекта.

Контекст:
- есть working slice после m11;
- продукт и аудитория описаны в docs/discovery.md и docs/design.md;
- первый сценарий MVP уже проходит после m11;
- первый MVP без auth/search/import/tags.

Выбери подходящий design skill; если подходящего нет, скажи прямо и работай по /spp.
Код пока не меняй.

Сначала помоги:
1. собрать референсы рынка;
2. извлечь принципы;
3. предложить 2-3 visual directions;
4. выбрать направление;
5. собрать мини-дизайн-систему;
6. написать UI Design Spec.

Если у SPP нет отдельного skill под этот шаг, это нормально: агент должен прямо сказать об этом и дальше работать через /spp, а не выдумывать несуществующий workflow.

Если агент сразу меняет CSS, останови его. Сначала дизайн-спека.

Шаг 3. Собери референсы рынка

Попроси агента собрать референсы:

Собери 5-7 референсов рынка для моего проекта.

Если есть web/browser access, каждый референс должен содержать:
- URL;
- дату проверки;
- какой экран или паттерн смотрел;
- почему он релевантен.

Если web/browser access нет:
- не выдумывай ссылки;
- пометь результат как known UI patterns, not market research;
- перечисли, что нужно проверить позже на реальных продуктах.

Нужны не ссылки ради ссылок, а source-backed принципы:
- почему референс релевантен;
- что взять для моего проекта;
- что нельзя копировать;
- какие риски.

Контекст: рабочий интерфейс моего проекта, основной сценарий MVP,
статусы или эквивалентные состояния, заметки или другие поля сценария, много текстовых данных.

После ответа выбери 2–3 референса или паттерна, которые ближе всего к твоему продукту. Если источников не было, не называй это ресерчем в UI Design Spec.

Проверь реальность референсов: открой 2–3 URL руками и убедись, что это существующие продукты, а не выдуманные агентом ссылки. Если ссылка не открывается или продукта нет, вычеркни её и пометь принцип как known UI pattern без источника.

Шаг 4. Выбери visual direction

Попроси агента предложить 2–3 направления:

На основе референсов предложи 2-3 visual directions для моего проекта.

Для каждого:
- опиши ощущение интерфейса;
- кому подходит;
- какие плюсы;
- какие риски;
- как это связано с docs/design.md.

Порекомендуй одно направление для первого MVP.

Выбери одно. Не смешивай все направления сразу.

Шаг 5. Собери мини-дизайн-систему

Prompt:

На основе выбранного visual direction собери мини-дизайн-систему моего проекта.

Нужно:
- typography;
- colors;
- spacing;
- radius;
- borders/shadows;
- icon usage;
- breakpoints: минимум mobile и desktop, решение о них - часть мини-дизайн-системы;
- components: button, input, list row/card, status badge, empty state, error state;
- states: empty, 1 item, many items, long text, loading/error/success, mobile, keyboard/focus.

Constraints:
- keep behavior from m11;
- no new features;
- no auth/search/import/tags;
- no data model changes.

Шаг 6. Напиши UI Design Spec

Канонический путь этого файла — docs/ui-spec.md. Он коммитится вместе с design-slice в том же commit, что и реализация дизайна.

Попроси агента собрать дизайн-спеку:

Собери UI Design Spec для моего проекта в docs/ui-spec.md.

Структура:
1. Direction
2. References and extracted principles
3. Mini design system
4. Components
5. States
6. Real data for testing
7. Accessibility baseline
8. Constraints
9. Acceptance criteria

Не пиши код.

Прочитай спека сам. Если там появились новые функции, верни на правку.

Шаг 7. Реализуй дизайн по UI Design Spec

Prompt:

Прочитай docs/design.md, docs/plan.md, docs/todo.md и UI Design Spec.

Реализуй дизайн только по UI Design Spec.

Сначала повтори:
- что входит в scope;
- что не входит в scope;
- какие UI-файлы тронешь;
- какие states проверишь;
- какой smoke check и manual scenario запустишь.

Запреты:
- no new features;
- no auth/search/import/tags;
- no data model changes;
- no random dashboard;
- no behavior changes.

После правок:
- запусти smoke check;
- запусти tests или documented manual fallback;
- пройди manual scenario из m11;
- проверь states из UI Design Spec;
- покажи diff как UI-only.

Шаг 8. Проверь результат

Проверь:

• основной сценарий m11 проходит;
• выбранное visual direction видно в UI;
• мини-дизайн-система применена последовательно;
• empty/loading/error/success states понятны;
• long text не ломает layout;
• mobile не ломает главный action;
• keyboard/focus видны;
• реальные русские данные выглядят нормально;
• diff не содержит новых функций.

Как именно проверять мобильную версию (DevTools device mode, сужение окна, телефон по локальной сети) — в дополнительном материале «Мобильная версия за 30 минут».

Если поведение сломалось, UI не принят.

Шаг 8a. Скриншоты и мультимодальная сверка

Сделай скриншот главного экрана до и после дизайна. Это дешёвый способ увидеть, что реально изменилось, а не что тебе кажется.

Покажи скриншот агенту и попроси сверить его со спекой и референсами:

Вот скриншот текущего экрана моего проекта.
Сверь его с UI Design Spec (docs/ui-spec.md) и выбранным visual direction.
Не меняй код. Верни:
- что совпадает со спекой;
- что отличается;
- где мини-дизайн-система применена непоследовательно.

Скриншоты до/после — обязательный артефакт приёмки design slice. Без них «стало лучше» — это мнение, а не проверка.

Шаг 9. Сделай commit только дизайн-slice

Перед commit попроси агента показать diff и staged diff:

Покажи git diff.
Проверь, что diff UI-only.
Подготовь к commit только файлы UI slice.
Покажи staged diff.
После моего подтверждения сделай commit с сообщением:
feat: оформить дизайн MVP

Если в diff есть auth/search/import/tags, data model или новый dashboard, убери это из UI slice.