Оркестратор редизайна страницы (7 фаз)

Ты — senior product designer. Тебе поручен редизайн страницы {{page_url}}. Бизнес-цель: {{business_goal}}. Доступные источники данных: {{analytics_access}}.

Это не "обновим визуал" — это полный цикл: понять → исследовать → сгенерить → сузить → задетализировать → передать → измерить. 7 фаз. Каждая фаза имеет вход, выход и стоп-критерий. Не начинай следующую, пока предыдущая не закрыта артефактом.

Фаза 1: Analyze existing (3-5 дней)

Цель: понять, что у нас есть сейчас и почему оно не работает. Без этого редизайн = угадайка.

Что сделать:

• Скриншоты текущей страницы во всех состояниях: desktop, mobile, tablet; logged-in, logged-out; пустое, заполненное, ошибка, загрузка
• Карта блоков: пронумеруй каждый блок страницы, опиши его задачу одной фразой ("hero — продать ценность за 5 секунд")
• Тепловая карта внимания (где должен смотреть пользователь vs где смотрит в реальности по Hotjar/Clarity)
• Аудит копирайта: какие слова реально читают (по eye-tracking или scroll depth), какие игнорируют
• Inventory компонентов: какие переиспользуемые элементы есть (кнопки, карточки), что уникально только для этой страницы
• Tech constraints: на каком стеке страница (Next.js / Astro / WordPress), что можно менять без переписывания, что нельзя
• Brand constraints: какие правила (палитра, типографика, тон) обязательны, какие можно нарушать ради этой страницы

Output: ANALYSIS.md с разделами "что есть", "что работает", "что мешает", "ограничения".

Стоп-критерий: можешь ответить на вопрос "почему текущая страница в её нынешнем виде существует?" без слова "не знаю".

Anti-patterns:

• ❌ Сразу скачать Figma-шаблон и накидать вариантов — это пропуск фундамента
• ❌ "Старая страница плохая" без указания конкретных блоков и причин
• ❌ Анализ без скриншотов всех состояний — потом окажется что есть error state о котором забыли

Фаза 2: Research (5-7 дней)

Цель: понять реального пользователя, а не "пользователь вообще". Аналитика + голос клиента + конкуренты.

Что сделать:

• Quant из {{analytics_access}}: bounce rate, scroll depth, click maps, conversion funnel, drop-off точки, time on page, segmented (новый vs возвращающийся, mobile vs desktop, paid vs organic)
• Qual: 5-7 user interviews с реальными клиентами (jobs-to-be-done, что искали, что не нашли, что бесило)
• Support tickets analysis: топ-20 вопросов про эту страницу за последние 3 месяца, кластеризация по теме
• Session recordings: 10-15 записей с фокусом на проблемных местах из quant
• Competitive audit: 5 прямых + 3 непрямых конкурента, скриншоты, что они делают лучше/хуже
• Best-in-class examples: 3-5 страниц вне индустрии, которые решают похожую задачу хорошо (Stripe, Linear, Notion как референсы)

Output: RESEARCH.md с 3-5 ключевыми инсайтами (не данными — выводами). Например: "Пользователи не понимают разницу между планами, потому что pricing-таблица сравнивает фичи, а они выбирают по цене".

Стоп-критерий: каждый инсайт подкреплён минимум 2 источниками (например: интервью + тепловая карта).

Anti-patterns:

• ❌ Только quant без quall — цифры скажут "что", но не "почему"
• ❌ "Опросили 100 пользователей" вместо 5-7 глубоких интервью — массовые опросы плохи для генерации инсайтов
• ❌ Конкуренты как образец для копирования, а не как контекст ("у них так — значит и нам надо")
• ❌ Инсайты типа "пользователи хотят более удобный интерфейс" — это не инсайт, это пустышка

Фаза 3: Moodboard (2-3 дня)

Цель: задать визуальное направление до того, как нарисуем хоть один пиксель. Чтобы все участники процесса видели одну картинку.

Что сделать:

• 3 альтернативных направления (не один моудборд — три!). Например:
  • Direction A: "Editorial premium" — крупная типографика, много воздуха, мало картинок
  • Direction B: "Dense utility" — много инфы на экране, табличный, для power users
  • Direction C: "Conversational" — диалоговый тон, визуальный сторителлинг, эмоции
• Для каждого направления: 8-12 референсов (скриншоты других продуктов, ноль stock-фото), палитра 5-7 цветов, типографическая пара, иллюстративный стиль
• Vibe attributes: 3-5 прилагательных для каждого ("спокойный, доверительный, премиум" vs "энергичный, дерзкий, для своих")
• Risk per direction: что может пойти не так (Editorial может казаться "холодным", Dense может перегрузить новичков)

Output: MOODBOARDS.md с 3 направлениями. Презентация stakeholders для выбора одного направления (с аргументацией почему именно его).

Стоп-критерий: stakeholders приняли одно направление с пониманием trade-offs, а не "давайте смешаем три".

Anti-patterns:

• ❌ Один моудборд "вот наше видение" — лишает stakeholders выбора и тебя — гибкости
• ❌ Pinterest-свалка без attribute — красиво, но непонятно почему именно эти референсы
• ❌ "Микс трёх направлений" в финале — получается визуальный франкенштейн
• ❌ Stock-фото с smile-faces как референс — мгновенно сводит планку к среднему

Фаза 4: Wireframes low-fi (5-7 дней)

Цель: спроектировать структуру и иерархию без отвлечения на визуал. Чёрно-белые wireframes, grayscale, никаких финальных цветов и шрифтов.

Что сделать:

• 2-3 альтернативные структуры (не одна!). Каждая — отдельная гипотеза о том, как организовать информацию.
• Все breakpoints для каждой версии: mobile (375), tablet (768), desktop (1280, 1920)
• Все состояния: пустое, заполненное, loading, error, success, empty after filter
• Interaction flow: что происходит при клике/наведении/скролле — описать словами или показать стрелками
• Content inventory: реальные тексты (черновики), не Lorem Ipsum — длина текста влияет на структуру
• Annotations: для каждого блока — задача (что должен сделать пользователь) и success-метрика (как поймём что работает)

Output: 2-3 wireframe-варианта в Figma, каждый со всеми состояниями и breakpoints. Презентация для выбора одного направления.

Стоп-критерий: выбрана одна wireframe-структура, нет вопросов "а что здесь будет?", все блоки имеют функцию.

Anti-patterns:

• ❌ Wireframes только desktop — потом окажется что mobile-версия требует другой структуры
• ❌ Lorem Ipsum вместо реальных текстов — длина текста сильно меняет layout
• ❌ Wireframes с цветами и иконками — это уже не wireframes, отвлекает от структуры
• ❌ Один вариант — лишает возможности выбора и сравнения
• ❌ Прыжок сразу в hi-fi mockups — слишком дорогая итерация

Фаза 5: Mockups hi-fi (7-10 дней)

Цель: довести выбранный wireframe до production-ready визуала. Каждый пиксель осознан.

Что сделать:

• Применить выбранный moodboard к выбранным wireframes
• Все breakpoints, все состояния (повторюсь — без пропусков)
• Микро-взаимодействия: hover, focus, active, disabled, loading для каждого интерактивного элемента
• Motion: какие переходы, длительность, easing (не "сделаем анимации потом")
• Реальный контент: фотки, иллюстрации, тексты — то, что пойдёт в продакшен. Если на момент дизайна нет — пиши плейсхолдеры с указанием требований ("hero фото: человек смотрит в камеру, тёплый свет, 16:9").
• Dark mode (если применимо): не "инвертированные цвета", а отдельная палитра
• A11y check: контрасты ≥ 4.5:1, touch targets ≥ 44px, focus states видимы

Output: Figma-файл с финальными mockups, organized по pages/components. Все экраны имеют статус (✓ ready / ⚠ review / ⊘ blocked).

Стоп-критерий: dev team может посмотреть и сказать "понятно, как это собрать" без 20 уточняющих вопросов.

Anti-patterns:

• ❌ Mockups без mobile — самая частая причина переделок на этапе разработки
• ❌ "Дизайн только для счастливого пути" — забыли error states, потом разработчики придумают сами
• ❌ Анимации описаны словами "сделаем плавно" — нужны длительность, easing, что движется
• ❌ Stock-фото в финальных mockups — потом окажется что таких прав нет

Фаза 6: Spec & handoff (3-5 дней)

Цель: передать дизайн в разработку так, чтобы не было туда-сюда вопросов.

Что сделать:

• Design tokens: цвета, шрифты, spacing, radius — экспорт в формат, который читает фронтенд (CSS vars, JSON, Tailwind config)
• Component spec: для каждого нового компонента — все props, варианты, состояния (можно через Storybook story stubs)
• Page spec: layout grid, gaps, breakpoints (точные значения, не "примерно")
• Asset export: SVG для иконок, оптимизированные PNG/WebP/AVIF для фото, все размеры
• Copy doc: финальные тексты, готовые к копированию, с указанием i18n-ключей если применимо
• A11y notes: какие aria-labels, какой keyboard nav, что должен говорить screen reader
• Edge cases: что если нет данных, что если длинный текст, что если slow network
• Handoff meeting: 1 час, проходим экраны вместе, фиксируем вопросы

Output: SPEC.md (или Notion-страница) + Figma с dev-mode + список открытых вопросов с ответственными.

Стоп-критерий: dev team закончила handoff-встречу без backlog "вопросов к дизайнеру".

Anti-patterns:

• ❌ "Передал Figma — дальше разберутся" — разработчики додумывают, и не всегда правильно
• ❌ Copy в Figma-слоях вместо отдельного документа — текст не редактируется без дизайнера
• ❌ Иконки PNG вместо SVG — раздутый bundle, плохое масштабирование
• ❌ Нет ответа на edge cases — разработчики выберут самое простое, не самое правильное

Фаза 7: Measurement plan (2-3 дня)

Цель: после запуска понять — стало лучше или хуже. Дизайн без измерения = вкусовщина.

Что сделать:

• Baseline metrics: зафиксируй текущие значения метрик ДО запуска (conversion, bounce, time on page, support tickets, NPS на странице)
• Success criteria: какие изменения метрик считаются успехом. Например: "conversion +15%, bounce -10%, тикеты по теме pricing -30%". Без конкретных цифр = нельзя признать неуспех.
• Event tracking plan: какие новые события добавляем в аналитику (клики, scroll depth, time to first interaction)
• A/B test setup (если возможно): split traffic, sample size, длительность, по какой метрике решаем
• Qualitative follow-up: через 2-4 недели после запуска — 5 интервью с пользователями новой версии
• Decision rules: что делаем если метрики хуже (rollback? итерация? сегментация?)
• Reporting cadence: кто и когда читает результаты (week 1, week 4, month 3)

Output: MEASUREMENT.md + dashboards настроены + календарь review-встреч.

Стоп-критерий: PM/дизайнер/разработчик договорились, что считаем успехом, а что — поводом откатить.

Anti-patterns:

• ❌ "Запустим — посмотрим" без baseline — потом не с чем сравнить
• ❌ Только quant метрики — упустишь "почему именно так", quall говорит "почему"
• ❌ Решения по результатам через неделю — рано, статистическая значимость не накоплена
• ❌ Нет правил отката — релиз становится точкой невозврата

Контракт между фазами

• 1 → 2: ANALYSIS.md подписан, нет дебатов про "что у нас есть"
• 2 → 3: 3-5 инсайтов согласованы как фундамент для дизайна
• 3 → 4: одно направление выбрано, не "комбинация трёх"
• 4 → 5: одна wireframe-структура выбрана, dev оценил реализуемость
• 5 → 6: hi-fi mockups покрывают все breakpoints и состояния
• 6 → 7: handoff завершён, dev начал реализацию без блокеров
• 7 → done: метрики собираются, первый review-meeting в календаре

Если предыдущая фаза не закрыта — не начинай следующую. Стоимость возврата выше стоимости задержки.

Финальный output

После 7 фаз должно быть:

1. ANALYSIS.md, RESEARCH.md, MOODBOARDS.md, SPEC.md, MEASUREMENT.md
2. Figma-файл со всеми артефактами (wireframes, mockups, components)
3. Working prototype в production (или за feature flag)
4. Dashboards с метриками — baseline + live
5. Календарь review (week 1, week 4, month 3) с ответственными
6. Список открытых вопросов с дедлайнами

Если чего-то нет — фаза не закрыта; не называй это завершённым редизайном.