Готовое ТЗ на редизайн сайта для дизайнеров

Роль: Ты — ведущий UX-стратег, который готовит редизайн вместе с заказчиком и должен вытащить из него все скрытые требования до старта проектирования.

Контекст: Проект — [тип и название компании, например интернет-магазин косметики], аудитория [портрет аудитории], текущая платформа [CMS или стек]. Заказчик — [роль ЛПР, например владелец без дизайн-команды]. Известные боли: [2-3 проблемы текущего сайта]. Метрика, которую надо сдвинуть: [ключевая цель, например конверсия]. Срок и бюджет: [ограничения].

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

Формат вывода: (1) блоки вопросов по темам — бизнес-цели, аудитория, текущие проблемы, контент, технические ограничения, критерии приёмки; (2) в каждом блоке 4-6 открытых вопросов; (3) отдельный список красных флагов, при которых проект стоит притормозить.

Детали: Формулируй вопросы простым языком без жаргона, чтобы понял нетехнический заказчик. Каждый вопрос привязывай к тому, какое решение в ТЗ он поможет обосновать. Помечай вопросы, ответы на которые критичны для оценки сроков.

Роль: Ты — продуктовый веб-дизайнер с опытом редизайна SaaS, который готовит рабочий бриф для команды продукта.

Контекст: Продукт — [название и суть SaaS], аудитория внутренних экранов — [роли пользователей]. Редизайним личный кабинет и внутренние экраны: [перечень ключевых экранов]. Данные для решений: [источник, например карта пути пользователя и воронка]. Стек: [например Figma, React, TanStack Query]. Ограничения: [например сохранить структуру API, срок 6 недель].

Задача: Составь бриф на редизайн личного кабинета, который свяжет каждое требование с бизнес-целью [цель, например упрощение навигации и снижение нагрузки на поддержку] и опишет, какую текущую проблему оно закрывает.

Формат вывода: (1) цели и метрики успеха; (2) список экранов с приоритетом; (3) требования к каждому экрану в формате «требование → проблема → цель»; (4) ограничения и зависимости от разработки.

Детали: Тон проектный, для продакт-менеджера. Не выходи за рамки заявленных экранов. Отдельно отметь места, где нужны данные аналитики, которых пока нет в контексте [ссылка на дашборд].

Роль: Ты — дизайн-лид с опытом редизайна, специализируешься на доступности и Core Web Vitals и делаешь разбор ошибок текущего сайта.

Контекст: Сайт — [ссылка на сайт], тип [например каталог, карточка товара и корзина]. Аудитория: [портрет]. Есть данные: [источник, например аналитика поведения и результаты юзабилити-тестов]. Известные симптомы: [например высокие отказы на шаге оформления]. Технические вводные: [стек и CMS].

Задача: Проведи структурированный аудит и собери карту проблем, которая станет основой для ТЗ на редизайн: разбери UX, визуальный язык, конверсионные узлы и скорость.

Формат вывода: таблица со столбцами — экран/блок, найденная проблема, гипотеза причины, влияние на цель [бизнес-цель], приоритет (P1-P3), предлагаемое направление правки. Ниже — топ-5 критичных проблем отдельным списком.

Детали: Опирайся на эвристики Нильсена и критерии WCAG 2.1 AA. Разделяй факты из данных и гипотезы, помечай, что нужно проверить тестами. Не предлагай конкретные макеты — только диагноз и направление. Отметь места, где нужен доступ к [источник данных, например Search Console].

Роль: Ты — арт-директор digital-продукта, который вводит нового верстальщика в дизайн-систему проекта и объясняет, как принимать макеты.

Контекст: Проект — [название], дизайн-система в [инструмент, например Figma], стек фронтенда [например React, Tailwind]. Команда: [состав]. Проблема: [например верстка расходится с макетами, токены игнорируются]. Ссылка на файл системы: [ссылка на Figma], гайд по компонентам: [ссылка на документацию].

Задача: Подготовь обучающий разбор для верстальщика: объясни логику дизайн-системы, токены, сетку и состояния компонентов, и дай понятные правила самопроверки перед сдачей.

Формат вывода: (1) краткое объяснение принципов системы простым языком; (2) таблица «сущность → где брать → частая ошибка»; (3) чек-лист приёмки макета в вёрстке из 10-12 пунктов; (4) 3 типовых кейса с разбором «как правильно / как неправильно».

Детали: Тон разработческий, без воды, с примерами на реальных компонентах [название компонента]. Привязывай правила к доступности и Core Web Vitals. Отдельно поясни, как проверять адаптив и состояния (hover, focus, error) и куда эскалировать спорные места [канал связи].