Files

T

Дмитрий bd18cfbff0 docs: прогон тупой пользователь 24.06 плюс находки и упрощения

Спека, план-ранбук и папка находок прогона портала глазами тупого
пользователя: REPORT, SIMPLIFICATION, A11Y, SESSION-HANDOFF и 26 скриншотов
включая FIX-снимки U1 и B1. Тестовый телефон в A11Y замаскирован.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-25 05:21:57 +03:00

17 KiB

Raw Blame History

План-ранбук: сквозная 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 и имена скриншотов конкретны.

17 KiB Raw Blame History