Документ дизайн-системы для внутренних бизнес-инструментов

Сначала проверь полноту входных данных и выходной контракт. Работай только с переданными данными и незаполненными placeholders, не придумывай факты, не задавай уточняющих вопросов и не добавляй пояснения о ходе рассуждений. Если исходные правила требуют явно отметить отсутствующие данные, допущения, пробелы, риски или ограничения, сделай это в итоговом результате. Верни только готовый результат в указанном формате.

Вы — инженер по дизайну мирового класса, специализирующийся на дизайн‑системах для бизнес‑приложений. Ваша цель — улучшить пользовательский опыт и обеспечить согласованность дизайна на разных платформах. [НАЗВАНИЕ ПРОЕКТА] хочет создать масштабируемую дизайн‑систему, реализуемую во внутренних инструментах.

Входные данные (заполните перед выполнением):
- [ТЕКУЩИЕ КОМПОНЕНТЫ] — список текущих компонентов: для каждого компонента укажите имя, краткое описание, где используется (инструмент/страница), варианты/стейты (size, color, disabled, loading и т.д.), частоту использования (high/medium/low), ссылки на код/дизайн (при наличии). Формат: список или таблица.
- [ОБРАТНАЯ СВЯЗЬ ПОЛЬЗОВАТЕЛЕЙ] — набор отзывов по удобству использования: для каждого отзыва укажите источник (исследование/саппорт/аналитика), дату, связанный компонент/экран, описанный поведенческий эффект, количественная метрика (если есть) и приоритет/влияние. Формат: список записей.
- [БРЕНД-ГАЙДЛАЙНЫ] — документ или краткая сводка руководства по бренду: лого, палитра, типографика, сетки и отступы, стиль иконок, фотографический стиль, голос/тон, ограничения использования. Можно вставить полную выдержку или ссылку.
- [ТИПЫ ПРИЛОЖЕНИЙ] — перечень типов внутренних приложений и платформ (например: веб админ-панель, мобильное приложение iOS/Android, embedded интерфейсы, консольные панели), с указанием целевых браузеров/версий и технологического стека при необходимости.
- [ДИЗАЙН-СИСТЕМА] — если есть существующие наработки дизайн‑системы (токены, компоненты, правила именования), приложите их; если нет — укажите «нет».

Задачи (выполнить последовательно и полно):
1) Инвентаризация компонентов
   - Составьте таблицу текущих компонентов (используйте данные из [ТЕКУЩИЕ КОМПОНЕНТЫ]). Для каждого компонента укажите: уникальный идентификатор, место(а) использования, вариации, текущие реализации по платформам, доступность (ARIA/WCAG), зависимости (другие компоненты/токены), проблемные места и приоритет унификации.
   - Выведите краткий свод по количеству дубликатов/альтернатив и где требуется срочная стандартизация.

2) Анализ отзывов по удобству
   - Синтезируйте данные из [ОБРАТНАЯ СВЯЗЬ ПОЛЬЗОВАТЕЛЕЙ]: выделите повторяющиеся проблемы, влияющие на несколько компонентов или потоков, оцените серьёзность (низкая/средняя/высокая) и вероятные корневые причины (напр., непоследовательность поведения, пересекание визуальной иерархии, неадекватные размеры/контраст).
   - Для каждой выявленной проблемы предложите конкретные рекомендации по исправлению и консолидации (кратко: что изменить и почему).

3) Аудит соответствия бренду
   - Сопоставьте текущие визуальные элементы и взаимодействия с [БРЕНД-ГАЙДЛАЙНЫ]. Для каждого ключевого токена (цвета, типографики, отступов, иконографики) отметьте: «соответствует», «частично соответствует — требует доработки» или «несоответствует». Укажите примеры расхождений и предлагаемые правки.
   - Если необходимо, предложите набор дизайн‑токенов (имя токена + значение + роль) для включения в систему, согласованных с бренд‑гайдом.

4) Полный перечень компонентов и правил использования
   - Создайте исчерпывающий каталог компонентов и стилей, которые должны войти в дизайн‑систему. Для каждого компонента дайте:
     - Название и краткое описание цели.
     - Анатомию и визуальные части (иконки, текст, отступы).
     - Состояния и поведения (hover, active, focus, disabled, loading и т.д.).
     - Правила адаптивности (как изменяется на мобильных/других платформах).
     - Доступность (ARIA роли, keyboard interactions, контраст, фокусная видимость).
     - Примеры использования и запреты («использовать когда», «не использовать когда»).
     - Список связанных дизайн‑токенов и пример именования/значений.
     - Если возможно, краткая псевдо‑реализация или props API (для разработчиков).
   - Включите также раздел с глобальными стилями и токенами: цветовая палитра, типографика (contextual styles), сетки/отступы, тени, радиусы, анимации (включая ограничения).

5) Слабое предположение и риск принятия
   - Определите единственное самое слабое предположение в ваших рекомендациях (одно предложение).
   - Подробно опишите, как команда может протестировать это предположение: гипотеза, метрики успеха, метод тестирования (A/B, пилотный релиз, пользовательское исследование), минимальный объём и длительность эксперимента, инструменты для измерения.
   - Назовите один реалистичный сценарий, в котором эта дизайн‑система может быть отвергнута организацией (операционные, политические или технические факторы), и дайте краткие рекомендации по снижению риска.

Формат окончательного результата:
- Представьте структурированный документ дизайн‑системы, пригодный для передачи командам разработчиков и дизайнерам. Документ должен содержать четкие заголовки и разделы в этом порядке:
  1. Краткое резюме (цели и охват)
  2. Инвентаризация компонентов (таблица + выводы)
  3. Анализ отзывов и приоритеты улучшений
  4. Аудит соответствия бренду и предложенные токены
  5. Каталог компонентов и правил использования (подробно)
  6. Глобальные дизайн‑токены и стили
  7. Самое слабое предположение + план тестирования
  8. Риск непринятия (1 сценарий) и смягчение
  9. Рекомендованные первые шаги для внедрения (микро‑план: первые 3 релиза/итерации)
- Тон: подробный, методичный, ориентированный на команды разработки — избегайте рекламного языка.
- Объём: достаточно подробно, чтобы команда могла начать реализацию без дополнительных высокоуровневых уточнений; при этом избегайте излишне длинных философских рассуждений.
- Формат представления: чистый текст с чёткой структурой разделов и маркерами; табличные данные можно представить в виде маркеров с четкими полями.
- Не задавайте вопросов — если входные данные неполные, используйте здравые допущения и чётко пометьте их как «допущения».

Выполните все пункты, используя предоставленные входные данные: [ТЕКУЩИЕ КОМПОНЕНТЫ], [ОБРАТНАЯ СВЯЗЬ ПОЛЬЗОВАТЕЛЕЙ], [БРЕНД-ГАЙДЛАЙНЫ], [ТИПЫ ПРИЛОЖЕНИЙ], [ДИЗАЙН-СИСТЕМА]. В результате верните полный структурированный документ согласно вышеуказанному формату.