# План-ранбук: сквозная UX-прогулка «глазами тупого пользователя»

> **Для исполнителя:** это исследовательский ранбук, не TDD-код. Каждый шаг = перейти
> по точному URL → сделать скриншот → посмотреть на экран как неискушённый человек →
> зафиксировать находки. Где помечено 🔧 — подключить точечный скил. Шаги — чекбоксы
> для отслеживания. Пригоден ко **второму прогону** (повторить те же шаги).

**Цель:** пройти кабинет клиента + поток лидов на dev и собрать (1) список упрощений
работы клиента «было → стало», (2) список дефектов (баги/блокировки/визуал/a11y).

**Подход:** живой проход через Playwright MCP по `http://127.0.0.1:8000`, скриншот
каждого шага в `docs/superpowers/findings/2026-06-24-dumb-user-walk/` с префиксом-номером.

**Среда:** Laravel 13 + Vue 3 + Vuetify 3, PostgreSQL, Redis. Портал поднят (HTTP 200).
Спека: `docs/superpowers/specs/2026-06-24-dumb-user-walkthrough-design.md`.

**Персона:** «тупой пользователь» — не знает внутренней логики, делает как понятно,
ленится читать длинные тексты, легко путается, ждёт очевидных дефолтов.

---

## Соглашение об именах скриншотов

`NN-краткое-описание.png`, где NN — сквозной номер шага. Пример: `01-landing.png`,
`05-register-form-filled.png`. Папка: `docs/superpowers/findings/2026-06-24-dumb-user-walk/`.

## Соглашение о фиксации находок

В конце каждого раздела — мини-список находок строками:
`[ТИП] экран — суть (скриншот NN)`, где ТИП ∈ {UX, БАГ, БЛОК-ПРОЕКТ, БЛОК-ДЕНЬГИ, ВИЗУАЛ, A11Y}.
Для UX-находок добавлять `было → стало`.

---

## Раздел 0: Подготовка

- [ ] **Шаг 1: Открыть браузер на корне портала**
  URL: `http://127.0.0.1:8000/`
  Скриншот: `01-landing.png`
  Смотреть: что видит человек с улицы — есть ли понятный вход/регистрация, что это за продукт.

- [ ] **Шаг 2: Снять консоль и сеть**
  Действие: `browser_console_messages` + `browser_network_requests` (нет ли ошибок/500).
  Фиксировать ошибки как потенциальные БАГ.

---

## Раздел 1: Регистрация нового аккаунта (новый тенант)

- [ ] **Шаг 3: Перейти на регистрацию**
  URL: `http://127.0.0.1:8000/register` (если редирект — идти по реальной кнопке «Регистрация» с лендинга/логина).
  Скриншот: `02-register-empty.png`
  Смотреть как тупой: понятно ли, какие поля обязательны, что от меня хотят, нет ли жаргона.

- [ ] **Шаг 4: Заполнить форму регистрации правдоподобными данными**
  Данные теста: имя «Тест Тупов», email `dumbuser-2026-06-24@example.org`, пароль `password123`
  (компания — если поле есть). Заполнять через `browser_fill_form`.
  Скриншот: `03-register-filled.png`
  Смотреть: индикатор силы пароля, валидация на лету, понятны ли требования к паролю.

- [ ] **Шаг 5: Отправить и поймать результат**
  Действие: нажать кнопку отправки.
  Скриншот: `04-register-result.png`
  Смотреть: куда попал (дашборд? письмо-подтверждение? ошибка?). Зафиксировать каждый
  непонятный момент. Снять консоль/сеть (ошибки 500 при сбое почты — известный риск из ЭТАЛОН).
  🔧 Если 500/падение — `superpowers:systematic-debugging`.

- [ ] **Шаг 6: Зафиксировать находки раздела регистрации.**

---

## Раздел 2: Первый экран / дашборд / онбординг

- [ ] **Шаг 7: Рассмотреть дашборд глазами новичка**
  URL: куда привела регистрация (обычно `/dashboard`).
  Скриншот: `05-dashboard-first.png`
  Смотреть: приветствие (реальное имя или захардкоженное?), стартовый блок/онбординг для
  пустого аккаунта, понятно ли «что делать дальше», нет ли мок-цифр, выдаваемых за реальные.

- [ ] **Шаг 8: Прочитать каждую цифру/виджет дашборда**
  Скриншот: `06-dashboard-widgets.png` (при необходимости прокрутки — доп. кадры).
  Смотреть: «хватит на N дней», средние, счётчики — соответствуют ли пустому аккаунту,
  не вводят ли в заблуждение. Любая мок-заглушка, похожая на реальные данные — UX-находка.

- [ ] **Шаг 9: Зафиксировать находки дашборда.**

---

## Раздел 3: Проекты — создание, список, источник, лимиты

- [ ] **Шаг 10: Открыть раздел «Проекты»**
  URL: `http://127.0.0.1:8000/projects` (или по кнопке меню).
  Скриншот: `07-projects-empty.png`
  Смотреть: пустое состояние — понятно ли, как создать первый проект, есть ли явный CTA.

- [ ] **Шаг 11: Запустить создание проекта**
  Действие: нажать «Создать/Новый проект».
  Скриншот: `08-project-create-form.png`
  Смотреть как тупой: сколько полей, что обязательно, понятны ли «источник», «лимит»,
  «регионы», «дни доставки», нет ли внутреннего жаргона. Это ключевой экран для упрощения.
  🔧 `design:design-critique` по этому экрану — где затыки.

- [ ] **Шаг 12: Заполнить минимально и создать проект**
  Данные: имя «Мой первый проект», источник/регион — как предлагает форма по дефолту.
  Скриншот: `09-project-create-filled.png`
  Смотреть: дефолты разумны? Можно ли создать «на отвали» и получить рабочий проект?

- [ ] **Шаг 13: Отправить и увидеть результат**
  Скриншот: `10-project-created.png`
  Смотреть: понятен ли итог, появился ли проект в списке, нет ли сырых ошибок SQL/500.
  Снять консоль/сеть. 🔧 При ошибке — `systematic-debugging`.

- [ ] **Шаг 14: Проверить список проектов и карточку**
  URL: `/projects`, открыть созданный.
  Скриншот: `11-project-card.png`
  Смотреть: статусы, метки блокировок, понятность полей.

- [ ] **Шаг 15: Зафиксировать находки проектов + дать упрощения**
  🔧 `frontend-design:frontend-design` + `design:ux-copy` — как упростить форму создания
  проекта (меньше полей/шагов, понятные подписи, дефолты). 🔧 `ui-ux-pro-max` — паттерны.

---

## Раздел 4: Биллинг / баланс / пополнение / тариф

- [ ] **Шаг 16: Открыть биллинг/баланс**
  URL: `http://127.0.0.1:8000/billing` (или по меню).
  Скриншот: `12-billing-overview.png`
  Смотреть: понятен ли баланс, тариф, как пополнить, где история списаний.

- [ ] **Шаг 17: Пройти сценарий пополнения баланса**
  Действие: нажать «Пополнить баланс», заполнить сумму (напр. 10000 ₽).
  Скриншот: `13-topup-form.png` → `14-topup-result.png`
  Смотреть: понятен ли поток оплаты (на dev — без реальной ЮKassa), что происходит после.
  🔧 `billing-audit` — корректно ли отражается баланс, не теряются ли копейки.

- [ ] **Шаг 18: Рассмотреть тарифную сетку и историю операций**
  Скриншот: `15-billing-tariff.png`, `16-billing-history.png`
  Смотреть: понятна ли ступень тарифа, даты (известный косметический баг «с 1970»),
  колонка «Операция»/провенанс заполнена ли, читаемо ли человеку.

- [ ] **Шаг 19: Зафиксировать находки биллинга.**
  🔧 `billing-audit` — деньги; `design:ux-copy` — формулировки сумм/ошибок.

---

## Раздел 5: Поток лидов — реальный приход (webhook → сделка → списание)

- [ ] **Шаг 20: Привязать проект к источнику лидов (если требуется)**
  Смотреть в карточке проекта/настройках, как клиент понимает, что проект «получает лиды».
  Скриншот: `17-project-source-link.png`

- [ ] **Шаг 21: Сэмулировать приход лида**
  Действие: отправить тестовый webhook на endpoint приёма лида (формат и секрет — по
  коду приёмника; на dev — локальный POST). Если webhook требует настройки поставщика,
  использовать имеющийся демо-механизм (`_demo_*` скрипты упомянуты в ЭТАЛОН) ИЛИ
  смоделировать создание сделки штатным путём.
  Скриншот: `18-lead-incoming.png`
  🔧 При непонятках с каналом — `systematic-debugging`, не гадать.

- [ ] **Шаг 22: Увидеть лид/сделку в кабинете и списание**
  URL: `/leads` или `/deals`.
  Скриншот: `19-deal-created.png`, `20-deal-card.png`
  Смотреть как клиент: понятно ли, откуда лид, сколько списали, что с балансом.
  🔧 `billing-audit` — списание идемпотентно и точно; баланс уменьшился ровно на цену.

- [ ] **Шаг 23: Зафиксировать находки потока лидов.**

---

## Раздел 6: Блокировки (проект / деньги)

- [ ] **Шаг 24: Спровоцировать блокировку по балансу**
  Действие: довести баланс до нуля/ниже порога (списаниями) и посмотреть, как портал
  блокирует проект и что показывает клиенту.
  Скриншот: `21-balance-block-banner.png`, `22-project-blocked-label.png`
  Смотреть: честная ли блокировка, понятно ли клиенту ПОЧЕМУ и ЧТО делать (пополнить),
  есть ли кнопка «Пополнить» прямо в сообщении.
  🔧 `billing-audit` — блокировка соответствует балансу; 🔧 `design:ux-copy` — текст блока.

- [ ] **Шаг 25: Снять блокировку пополнением и проверить разблокировку**
  Действие: пополнить баланс, убедиться, что блок снят «всё-или-ничего».
  Скриншот: `23-unblocked-after-topup.png`
  Смотреть: разблокировка очевидна и моментальна для клиента?

- [ ] **Шаг 26: Зафиксировать находки блокировок.**

---

## Раздел 7: Остальные сервисы кабинета

- [ ] **Шаг 27: Напоминания**
  URL: `http://127.0.0.1:8000/reminders`
  Скриншот: `24-reminders.png`
  Смотреть: понятно ли, заголовок топбара корректен (был баг «Страница»), как создать напоминание.

- [ ] **Шаг 28: Импорт (CSV)**
  URL: `http://127.0.0.1:8000/import`
  Скриншот: `25-import.png`
  Смотреть: понятен ли формат, есть ли пример/шаблон, что будет при битом файле.

- [ ] **Шаг 29: Настройки профиля**
  URL: `/settings` или меню профиля.
  Скриншот: `26-settings.png`
  Смотреть: смена пароля/данных понятна, нет ли пугающего жаргона.

- [ ] **Шаг 30: Меню/навигация/выход**
  Действие: открыть меню профиля в топбаре, проверить «Выйти» (был баг off-screen меню).
  Скриншот: `27-topbar-menu.png`
  Смотреть: всё на экране, выход работает.

- [ ] **Шаг 31: Зафиксировать находки остальных сервисов.**

---

## Раздел 8: Доступность (сквозная)

- [ ] **Шаг 32: A11y-проход по ключевым экранам**
  🔧 `design:accessibility-review` по собранным скриншотам ключевых экранов
  (регистрация, создание проекта, биллинг, блокировка).
  Смотреть: контраст текста, видимость фокуса, подписи полей/кнопок, читаемость ошибок.
  Зафиксировать A11y-находки.

---

## Раздел 9: Синтез и упрощения (главная задача)

- [ ] **Шаг 33: Свести затыки в список упрощений «было → стало»**
  🔧 `frontend-design:frontend-design` + `design:ux-copy` + `ui-ux-pro-max` (материал,
  последовательно). Для каждого затыка: экран, что мешает, конкретное упрощение, эффект.

- [ ] **Шаг 34: Свести дефекты (баги/блокировки/визуал/a11y) в отдельный список** с
  приоритетом и скриншотом-доказательством.

---

## Раздел 10: Верификация и отчёт

- [ ] **Шаг 35: Верификация перед вердиктом**
  🔧 `superpowers:verification-before-completion` — все области §3 спеки пройдены, по
  каждой есть скриншоты, оба списка собраны.

- [ ] **Шаг 36: Отчёт владельцу**
  Файл: `docs/superpowers/findings/2026-06-24-dumb-user-walk/REPORT.md` — резюме,
  список упрощений, список дефектов, ссылки на скриншоты. Отдать на согласование и
  возможный второй прогон.

---

## Self-review плана vs спека

- §1 Цель (упрощение + дефекты) → разделы 9 (упрощения), 3–7 (дефекты по ходу). ✓
- §2 Где гоняем (dev) → раздел 0 / все URL на 127.0.0.1:8000. ✓
- §3 Охват (кабинет + поток лидов) → разделы 1–7 (кабинет), 5 (поток лидов). ✓
- §4 Цепочка скилов → точечные 🔧-вставки по разделам соответствуют таблице спеки. ✓
- §5 Фиксация находок → соглашение о находках + разделы 9–10. ✓
- §6 Критерий готовности → раздел 10 (verification + отчёт). ✓
- §7 Не делаем (не чиним код, не трогаем прод) → ранбук только наблюдает + предлагает. ✓
- Заглушек нет; URL и имена скриншотов конкретны.
