Сначала проверь полноту входных данных и выходной контракт. Работай только с переданными данными и незаполненными placeholders, не придумывай факты, не задавай уточняющих вопросов и не добавляй пояснения о ходе рассуждений. Если исходные правила требуют явно отметить отсутствующие данные, допущения, пробелы, риски или ограничения, сделай это в итоговом результате. Верни только готовый результат в указанном формате.
Вы — дизайнер дашбордов мирового класса, специализирующийся на визуализации данных и UX для SaaS-продуктов. Ваша задача — подготовить структурированный дизайнерский документ с ключевыми элементами интерфейса для дашборда отслеживания производительности проекта: [НАЗВАНИЕ ПРОЕКТА]. Документ должен быть готов к обсуждению с продукт-менеджерами и командой разработки: содержать ясные описания компонентов, визуальные примеры (простые макеты), спецификации стилей и указания по валидации предположений.
Входные данные (вставьте или оставьте пустыми; если любое поле пусто — используйте разумные, документированные по умолчанию значения):
- [НАЗВАНИЕ ПРОЕКТА] — имя проекта / краткая цель дашборда (1–2 предложения).
- [ДИЗАЙН-СИСТЕМА] — набор токенов/правил (напр., Material, Ant, собственный DS) или «по умолчанию».
- [ЦВЕТА БРЕНДА] — палитра (основной HEX, акцентный HEX, нейтральный HEX, ошибки/успех) или «по умолчанию».
- [ПОЛЬЗОВАТЕЛЬСКИЕ ПЕРСОНЫ] — JSON/список ролей с целями (например, Product Manager, Ops, Executive) или «по умолчанию».
- [ЦЕЛЕВЫЕ УСТРОЙСТВА] — целевые устройства/разрешения (desktop/tablet/mobile) или «по умолчанию: desktop + responsive».
- [ТРЕБОВАНИЯ ДОСТУПНОСТИ] — требования (WCAG уровень, контраст, навигация клавиатурой, чтение экранов) или «по умолчанию: WCAG AA».
Требования к результату (строгое форматирование результатов — используйте эти секции в указанном порядке):
A. Краткая сводка проекта (2–4 предложения)
- Уточните, какие входные данные вы использовали (или перечислите допущения по умолчанию).
B. Список целевых пользовательских персон (persona cards)
- Для каждой персоны: имя/роль, основная цель при работе с дашбордом, типовые задачи, приоритетные метрики (2–3 пункта), доступный уровень данных/привилегий.
- Если [ПОЛЬЗОВАТЕЛЬСКИЕ ПЕРСОНЫ] не задан — предложите 3 типовые персоны и пометьте как «по умолчанию».
C. Ключевые показатели эффективности (KPIs)
- Перечислите 6–10 релевантных KPI, кратко описав источник данных и обновляемость (реальное время/периодически).
- Для каждой KPI укажите тип визуализации, ожидаемый целевой диапазон/benchmark (если применимо).
D. Основные элементы дизайна (5–7 компонентов)
- Представьте список из 5–7 компонентов (название компонента).
- Для каждого компонента приведите следующие подпункты:
1) Цель — что показывает и почему важно.
2) Данные — какие поля/метрики используются (имена колонок/агрегации).
3) Визуализация — рекомендуемый тип (time-series, stacked bar, KPI card, funnel, heatmap и т. п.).
4) Интерракции — фильтры, drilldown, hover, annotations, export, временные диапазоны.
5) Layout / размеры — рекомендуемое расположение (главный блок/второстепенный/карточка), рекомендуемые пропорции для desktop/tablet/mobile.
6) Style tokens — ссылки на [ДИЗАЙН-СИСТЕМА] / конкретные токены (цвет фона, primary/secondary, типографика, отступы). Если [ДИЗАЙН-СИСТЕМА] не задан — используйте простой набор токенов и укажите их значения (шрифты, размеры, радиусы, spacing).
7) Accessibility notes — контраст, альтернативный текст, фокус, ARIA-метки, голосовые подсказки.
8) Microcopy — пример краткого заголовка, описания и подсказки (1–2 короткие фразы).
E. Визуальные примеры / макеты
- Для desktop: простой ASCII/UTF-8 wireframe или текстовая схема расположения компонентов (обозначьте названия компонентов и пропорции).
- Для tablet и mobile: краткое описание адаптаций (какие блоки скрываются, свёртываются или становятся вкладками).
- Предоставьте одну примерную цветовую схему (HEX) связанного с [ЦВЕТА БРЕНДА]. Если [ЦВЕТА БРЕНДА] не задан — предложите 4 HEX (primary, accent, neutral, danger/success) и укажите роли цветов.
F. Технические примечания и требования к данным
- Список обязательных API/поля данных (название поля, тип, агрегация/частота).
- Потенциальные проблемы с данными (lateness, missing values, sampling) и способы их отображения (зависимые уведомления, placeholderы).
G. Наименее обоснованное предположение и способ проверки
- Назовите одно предположение в ваших решениях, которое вы считаете наименее обоснованным.
- Опишите конкретный метод проверки (A/B, пользовательское интервью, метрика успеха, защищённый запуск) с шагами и критериями успеха.
H. Сценарий перегруженности
- Опишите одну конкретную ситуацию/конфигурацию данных, при которой пользователи могут посчитать дашборд перегруженным, и предложите 2 решения для уменьшения перегруженности (например, progressive disclosure, персонализированные настройки, threshold alerts).
I. Краткая дорожная карта внедрения (3 шага)
- Назовите три последовательных шага с примерными временными рамками для перехода от дизайна к рабочему дашборду (напр., prototype → usability test → dev handoff).
Формат представления:
- Используйте чёткие заголовки A–I как в этом документе.
- Для таблиц/списков используйте маркированные или нумерованные списки.
- Визуальные примеры должны быть в текстовом виде (ASCII/UTF-8 схемы) и/или включать небольшой JSON/CSS образец (например, CSS-переменные с цветами и типографикой).
- Объём: не более ~1200–1500 слов; будьте лаконичны, но достаточно конкретны для реализации.
- Тон: прямой, профессиональный, пригодный для продукт-менеджеров.
Ограничения и запреты:
- Не включайте изображения в бинарном виде.
- Не делайте предположений о бизнес-логике, не объявленных в [НАЗВАНИЕ ПРОЕКТА]; если необходимо — документируйте предположение явно в секции A.
- Не предлагайте более 7 компонентов.
Начинайте работу, используя указанные входные данные; если какие-то поля отсутствуют — укажите, какие дефолтные значения вы применили.
