Что считается «кейсом» в этом исследовании?
Кейсом считается публичный источник, где можно найти не только интерфейсные примеры, но и подход: структуру документации, токены, правила использования, установку/подключение, статусы или процесс обновлений.
В отбор попадают системы, где есть хотя бы минимальное авторское мнение «зачем так сделано» или объяснение принципов. Это позволяет опираться на проверяемые материалы.
Почему сравнение строится «по подходу», а не по компонентам
Сравнение по компонентам часто приводит к поверхностным выводам: в большинстве систем набор элементов похож и отражает общий рынок. При этом различия проявляются в другом: как вносятся изменения, как ведётся документация, как поддерживаются платформы и как синхронизируется дизайн с кодом.
Метод: desk research + интервью
Используется комбинированный метод: анализ открытых источников (Storybook, docs, статьи), дополненный интервью с практиками из продуктовой компании и дизайн-студии.
Кейс 1: Дизайн-система Ростелекома
Документация дизайн-системы Ростелекома показывает, что система описывается не как «набор компонентов», а как инфраструктура для консистентного пользовательского опыта и предсказуемого поведения интерфейса.
Это видно уже в вводном разделе: дизайн-система связывает стандарты, инструменты и процессы, а также явно разделяет поколения (1-е и 2-е), демонстрируя эволюцию архитектуры и изменений.
Отдельно подчёркивается инженерная сторона: система поставляется как библиотека, доступна для разных стеков (например, React/Vue) и имеет отдельные артефакты для дизайнерской работы (Pixso), что снижает вероятность «случайных» расхождений между продуктами.
Для исследования этот кейс важен как пример «прозрачной витрины», где наружу вынесены не только примеры, но и принципы принятия решений.
В разделе по темам и палитрам раскрывается логика дизайн-токенов: тема задаёт визуальный стиль элементов, описываются варианты цветовых схем и правила использования (например, рекомендация уменьшать интенсивность и/или количество цветов в сложных интерфейсах, чтобы избежать перегрузки).
Наличие таких правил, примеров и понятной навигации в формате Storybook делает кейс пригодным для анализа именно подхода к работе: как система документируется, как ею пользуются команды и как она подключается в разработке через установку и зависимости.
Кейс 2: Plasma (SberDevices) — семантические токены и темы как инфраструктура системы
Документация Plasma (SberDevices) удобна для анализа тем, что она явно выделяет слой тем и семантических токенов как основу управления параметрами.
В «Билдере» показано, что система описывает не отдельные цвета или размеры, а семантические схемы: цветовую, типографическую, скругления и другие наборы значений.
Такой подход переводит дизайн в формат управляемых правил и параметров, а не ручных правок на уровне макетов.
Рядом с каждым набором видно, где он поддерживается (например, Web, React-Native, iOS, Android). Токены в Plasma работают как общий слой синхронизации между дизайном и разработкой и помогают удерживать единый визуальный язык при работе на разных платформах.
Для исследования этот кейс важен как пример системы, где «фундамент» (темы и токены) представлен публично и достаточно прозрачно, чтобы анализировать не компоненты, а подход к управлению стилем и масштабированию дизайн-системы.
Кейс 3: VKUI — «зачем токены» прямо в документации
VKUI удобна для исследования тем, что это не просто витрина компонентов, а публичная документация, где поясняется логика устройства системы. Уже в разделе «Обзор» система описывается как библиотека адаптивных React-компонентов, основанная на дизайн-системе ВКонтакте, и сразу выносит на первый план преимущества, связанные с предсказуемостью и масштабируемостью: адаптивность под разные экраны, мультиплатформенность и поддержка разных цветовых схем.
В разделе «Дизайн-токены» в документации напрямую сформулировано «почему так»: токены определяются как набор базовых переменных (отступы, цвета, типографика, анимации), а также объясняется, что токены используются вместо конкретных значений, чтобы компоненты было легче подстраивать под платформы и цветовые режимы.
Дополнительно показано, что токены поставляются в нескольких форматах (например, CSS и другие), имеют соглашение по именованию (префикс и структура классов), а также приводится пример применения токена в коде. Для исследования это ключевой признак «аргументированной» системы: объяснение встроено в документацию и подкреплено тем, как токены реально подключаются и используются.
Таким образом, VKUI выступает как пример кейса, где токены не просто показаны, а объяснены через роль (зачем нужны), форму поставки (в каких форматах живёт) и практику применения (пример и правила), что позволяет делать выводы именно о подходе к работе с дизайн-системой.
Кейс 4: Hexa UI (Kaspersky) — дизайн-система как продукт с ролями и правилами
Документация Hexa UI демонстрирует подход, где дизайн-система описывается как полноценная рабочая среда, а не как «папка со стилями». Уже в вводном разделе сформулирована цель системы: унификация визуального дизайна, проектирования и разработки пользовательских интерфейсов внутри организации. Это сразу задаёт рамку: дизайн-система рассматривается как инструмент для согласованной работы команд.
Отдельно подчеркнуто разделение ответственности: обозначены две группы, связанные с дизайном и разработкой, а также приведены контакты ответственных. Такой формат важен для исследования практик, потому что делает видимой организационную часть: у системы есть лидеры, процессы и контакт для коммуникации.
Дополнительно фиксируется технологический контекст — указано, на каких инструментах построена реализация (например, styled-components и antd).
В результате Hexa UI можно использовать как пример «системы с рамками»: когда помимо компонентов есть, кто отвечает за развитие, как устроено сопровождение и в каком технологическом окружении система применяется.
Сравнение подходов
В совокупности эти четыре кейса дают наблюдаемую картину разных дизайн-систем в российском контуре: от витринной документации с практическими правилами, через токенно-ориентированные системы с темизацией и мультиплатформенностью, до библиотек и платформ, где объяснение и структура становятся частью самой системы.
Наиболее часто повторяются практики, связанные с организацией и масштабированием: витрина, токены, документация, инженерный слой и управление изменениями.
Они формируют «базу» дизайн-системы, на которую уже впоследствии накладываются визуальные решения. Эти пункты становятся основой для структуры будущего онлайн-медиа.
Уникальные практики и «фишки» команд
Помимо повторяемых решений, в кейсах и интервью встречаются уникальные практики, которые показывают уникальность процесса. Именно такие «фишки» особенно ценны для опыта, потому что их редко описывают в общих гайдах
Добавление иконки в Figma → автоматизация в код
В кейсе Додо описан процесс, где работа с иконками организована так, чтобы изменение в Figma не превращалось в ручную «перекладку файлов» между командами. Такой подход уменьшает человеческий фактор: важными становятся правила именования, формат и автоматическая доставка в репозиторий/проект. Практика иллюстрирует зрелую связь дизайн↔код на уровне ассетов.
Токены/значения → конвертация под платформы
Токены становятся «источником», если изменения проходят путь до кода в платформах. В интервью упоминается конвертация и проверка, что делает обновления более безопасными и управляемыми. Эта практика показывает, как дизайн-решение превращается в инженерный процесс.
«Нажал синхронизировать с гитхабом, на гитхаб уходят новые токены с помощью автоматизации, которую мы сами написали, не используя никаких сторонних продуктов. "
Sandbox для «протыкать» компоненты по платформам
Sandbox-пространства позволяют проверить компонент в интерактиве, а не только в макете, и заранее увидеть несоответствия поведения. Это снижает риск, что компонент «красивый», но непредсказуемый в реальной реализации. Практика особенно важна при параллельной поддержке iOS и Android.
Студийный подход «много мелких улучшений»
В студийном контексте ценны практики, которые экономят время на масштабе: нейминг, фон превью, сортировка и правила хранения. Эти детали не выглядят «большими решениями», но в сумме снижают трение и ускоряют работу разных дизайнеров. Практика полезна тем, что легко переносится в команды с любым уровнем навыков и опыта.
«я игрался с названием этих компонентов таким образом, чтобы у меня в системе ассетов там работает алфавитная сортировка. Мне очень хотелось, чтобы сначала у меня алфавитная сортировка была по компонентам, а потом отдельно по модулям.»
Уникальные практики часто проявляются в автоматизации и формализации: меньше ручной работы, больше проверок и прозрачных правил.
При этом часть подходов универсальна и переносима даже без больших ресурсов, например стандарты нейминга и чек-листы качества. Эти выводы используются дальше как основа для разделов «кейсы / глоссарий / гайды ” в проектируемом медиа.
Главный вывод: уровень проработанности = процессы \+ доказательства \+ синхронизация
Сравнение показывает, что уровень проработанности дизайн-системы определяется не количеством компонентов, а устойчивостью процессов: как устроены изменения, как ведётся документация, как поддерживаются токены и как синхронизируется дизайн с кодом. Там, где есть ясные правила и прозрачные статусы, система лучше масштабируется и уменьшает ошибки.
