Hexa UI

Формат: кейс по публичным материалам (Storybook + GitHub + npm, Apache-2.0). Дата обращения: апрель 2026.

Главное

Контекст

Позиционирование: унификация дизайна и разработки как организационная цель

Hexa UI позиционируется как инструмент унификации не только визуального языка, но и процесса проектирования и разработки. Для исследования это важный сигнал: дизайн-система описана как организационная инфраструктура, где дизайн и разработка — две равноправные части системы. В документации явно разделены зоны ответственности, а также указаны контакты ответственных — это редкий маркер зрелого governance.

Состав системы

Foundations: токены как отдельный продуктовый слой (@kaspersky/hexa-ui-core)

3.1 Разделение токенов по контексту использования

Токены вынесены в отдельный пакет @kaspersky/hexa-ui-core, и это не просто «палитра». Цвета разделены на несколько доменов: staticColors (база), productColors (для продуктовых команд), componentColors (для компонентов библиотеки). Это архитектурный приём: продуктовые цвета и библиотечные цвета не смешиваются, что снижает риск регрессий при обновлениях и упрощает поддержку.

3.2 Уникальная практика: гранулярный импорт токенов по компоненту

Можно подключать CSS-переменные только для нужных компонентов (например, button), а не весь набор переменных. Практический эффект: снижается размер бандла и ускоряется загрузка — критично для enterprise B2B приложений с большим количеством интерфейсов.

3.3 Автоматизированная синхронизация Figma → JSON → CSS → npm

В репозитории описаны команды обновления токенов (например, update-colors и update-typography), которые импортируют значения из Figma в JSON и генерируют CSS-переменные. Это снимает ручной перенос значений и снижает рассинхронизацию дизайн↔код на уровне foundations.
Компоненты как система: стандарт документации, версии и типобезопасный API

Каждый компонент в Storybook имеет Docs и Stories (интерактивные примеры), а в шапке есть кнопки Versions (история изменений) и All Props. Отдельный сильный маркер — публичный «Шаблон документации компонентов»: компоненты документируются по единому стандарту, а не «как получится».

Типизация — часть продуктового контракта: отдельные страницы в DOCS объясняют подход к TypeScript, что снижает количество ошибок при интеграции.

Процессы развития

Управление изменениями: open-source workflow вместо закрытых релизов

Hexa UI — полноценный open-source репозиторий: исходники, Issues, Pull Requests, релизы и теги. История изменений видна в git, а не только в «красивом» changelog. В Storybook дополнительно подсвечиваются версии на уровне каждого компонента.

Документация

Карта документации: сначала правила и процессы, потом компоненты

Документация живёт в Storybook и разделена на блоки DOCS и DESIGN. В DOCS вынесены процессные и архитектурные страницы: установка, архитектура компонентов, типизация, разработка, Definition of Done, шаблон документации компонентов, настройка THEME_CONFIG, useThemedComponent, тестовые атрибуты (testId/klId). Только после этого идут компоненты (в алфавите) с историей версий и быстрым просмотром пропсов.

Это явная структура приоритетов: сначала стандарты и качество, потом витрина компонентов. Для анализа подхода это ключевой плюс кейса.

Контроль качества

Тестируемость как часть API: testId / klId

Hexa UI встроила E2E-тестируемость в публичный API компонентов: testId/klId и утилиты для тестовых атрибутов описаны как отдельный раздел документации. Это значит, что DS проектируется под реальные enterprise-процессы QA, а не только под визуальную консистентность.

Уникальные практики и «фишки» кейса

Уникальные практики (в логике исследования)

Выводы и принципы

Ограничения кейса

Источники

Избранные цитаты