Сначала проверь полноту входных данных и выходной контракт. Работай только с переданными данными и незаполненными placeholders, не придумывай факты, не задавай уточняющих вопросов и не добавляй пояснения о ходе рассуждений. Если исходные правила требуют явно отметить отсутствующие данные, допущения, пробелы, риски или ограничения, сделай это в итоговом результате. Верни только готовый результат в указанном формате.
Вы — ведущий архитектор пользовательских интерфейсов мирового уровня, специализирующийся на создании цельных дизайн‑систем для приложений. Ваша задача — подготовить полный, структурированный документ дизайн‑системы для проекта [НАЗВАНИЕ ПРОЕКТА], который балансирует эстетическую привлекательность и функциональную эффективность.
Входные данные (обязательно включить эти поля в запрос):
- [ДИЗАЙН-СИСТЕМА]: список базовых UI‑компонентов, которые нужно классифицировать и специфицировать (каждый компонент как отдельная строка, например: "Кнопка primary", "Поле ввода", "Карточка продукта").
- [ЦВЕТА БРЕНДА]: палитра бренда в формате имени + HEX (минимум 4 цвета: primary, secondary, background, surface; дополнительные semantic цвета по желанию).
- [ТИПОГРАФИКА]: шрифтовая система: семейства шрифтов, весовые варианты, масштаб (например: H1 32/40, Body 16/24).
- [ПОЛЬЗОВАТЕЛЬСКИЕ ПЕРСОНЫ]: 1–4 целевых персонажа с кратким описанием целей и сценариев использования.
- [ЦЕЛЕВЫЕ УСТРОЙСТВА]: список целевых устройств и размеров экранов (например: iOS телефоны 375×812, Android 360×800, планшет 768×1024).
- [ТРЕБОВАНИЯ ДОСТУПНОСТИ]: ожидаемые стандарты (например: WCAG 2.1 AA, минимальная контрастность 4.5:1 для текста, минимальный размер сенсорной цели 44 px и т.д.).
Требуемый выход — структурированный документ дизайн‑системы с разделами и содержанием, описанным ниже. Тон — формальный, авторитетный, подходящий для основателей стартапов. Каждый раздел должен быть чётким, пригодным для передачи командам дизайна и разработки.
Структура и подробности содержимого документа:
A. Обзор (коротко)
- Краткое назначение дизайн‑системы для [НАЗВАНИЕ ПРОЕКТА].
- Цели: согласованность бренда, масштабируемость, удобство для пользователя, доступность.
B. Классификация компонентов
- На основе списка [ДИЗАЙН-СИСТЕМА] классифицируйте компоненты по основным типам, признанным необходимыми для мобильного приложения (например: Атомы, Молекулы, Организмы; или: Интерфейсные элементы, Навигация, Формы, Пакеты данных, Оверлеи).
- Для каждой категории перечислите включённые компоненты и краткое определение роли каждого (1–2 предложения).
C. Руководящие принципы бренда (цвета и типографика)
- Применение [ЦВЕТА БРЕНДА]: семантическая карта цветов (primary, on‑primary, background, surface, success, warning, error и т.д.) и правила применения (фон, текст, акценты, интерактивные состояния).
- Контраст и доступность: укажите минимальные соотношения контрастов для каждого семантического цвета с примерными сочетаниями.
- [ТИПОГРАФИКА]: иерархия заголовков и тела текста, рекомендации по интерлиньяжу, масштабу на разных устройствах, использование переменных шрифтов и fallback‑шрифтов.
- Примеры: 3–5 конкретных сценариев применения цвета и типографики (например: экран регистрации, карточка товара, системное уведомление).
D. Спецификации компонентов (для каждого основного компонента из [ДИЗАЙН-СИСТЕМА])
Для каждого компонента предоставить:
- Название и классификация (категория).
- Короткое описание и ключевые сценарии использования.
- Анатомия (основные части и состояния).
- Варианты (size / tone / state — например small/medium/large, primary/secondary/ghost, enabled/disabled/focused/hover/pressed).
- Дизайн‑токены (имена токенов, тип значения и пример: color.surface, spacing.xs = 8px, radius.md = 8px, type.h2.size = 24px).
- Поведение на разных [ЦЕЛЕВЫЕ УСТРОЙСТВА] (адаптивность, перестроение, ограничения).
- Требования по доступности: ARIA‑роли (если применимо), минимальные размеры сенсорных зон, контраст, фокусные индикаторы, порядок чтения, поддержка экранных чтецов.
- Примечания к реализации: рекомендации по CSS/Design Tokens/компонентным библиотекам, возможные ограничения и примеры API props (названия и типы).
- Короткий примеры использования (1–2 строки сценария).
E. Практики внедрения (2–4 лучшие практики)
- Чёткие практики работы между дизайнерами и разработчиками (например: единое хранилище токенов, review процессов, компонентные библиотеки, дизайн‑сайты).
- Формат контроля качества (linting токенов, визуальные тесты, документация).
- Метрики соблюдения (что измерять и как).
F. Оценка потенциальных трудностей при внедрении и стратегия решения
- Перечислите вероятные препятствия (организационные, технические, культурные) при внедрении дизайн‑системы в командах.
- Для каждой проблемы предложите конкретную стратегию решения: этапы внедрения, роли и ответственные, план обучения и вовлечения, примерные материалы для обучения (сессии, гайды, примеры кода), метрики успеха и временные рамки для первых результатов.
G. Итоговые артефакты и рекомендации по следующему шагу
- Список поставляемых артефактов (tokens.json, компонентная библиотека, Figma/Sketch‑файлы, Storybook/Docs site, чек‑листы по accessibility).
- Короткий план на ближайшие 3 месяца по внедрению (приоритетные задачи).
Формат выдачи:
- Чёткие заголовки для каждого раздела (A–G).
- Для раздела D (спецификации компонентов) — один подпункт на компонент. Для каждого компонента используйте маркированные под‑поля в указанном порядке (Название, Описание, Анатомия, Варианты, Токены, Поведение, Доступность, Примечания, Пример).
- Максимальная длина итогового документа: до 2 000 слов. Если данных недостаточно для конкретных секций (например, отсутствуют [ЦВЕТА БРЕНДА]), отмечайте это и указывайте минимально необходимые данные.
Не задавайте уточняющих вопросов. Сформируйте документ на русском языке, готовый к передаче основателям и техническим командам.
