Ростелеком

Формат: кейс по публичным материалам (design.rt.ru + Storybook + история релизов/объявлений).

Дата обращения: апрель 2026.

Главное

Контекст

Контекст и позиционирование

Ростелеком показывает дизайн-систему как продукт, рассчитанный на внешнего наблюдателя: система доступна публично и собрана так, чтобы по ней было видно не только «как выглядит», но и «как устроено». Ключевая идея — консистентность и предсказуемость поведения компонентов, которую можно поддерживать в масштабе продуктовых команд.

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

Токены: видны и «на уровне системы», и «на уровне компонента»

Ростелеком выделяет токены в отдельный слой: в Storybook есть раздел Design Tokens (базовые токены), а также компонентные токены, которые доступны прямо на страницах компонентов. Это важная практическая деталь: токены не спрятаны «внутри», их можно просматривать и проверять рядом с компонентом — там, где они используются.

Отдельно в публичных анонсах упоминается вкладка токенов у компонентов с возможностью просмотра и редактирования — это усиливает прозрачность и снижает барьер для команд, которые внедряют DS и ищут причины визуальных отличий.
Переход на 2-е поколение (Atomaro): обновление архитектуры

В публичных материалах фиксируется переход на 2-е поколение дизайн-системы (Atomaro): новая архитектура должна дать дизайнерам и разработчикам больше возможностей и более предсказуемый процесс развития. Для исследования это удобный сюжет: видно, что дизайн-система развивается версиями и переживает крупные архитектурные изменения.

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

Управление изменениями: changelog и история релизов

У системы есть видимый слой управления изменениями: changelog внутри Storybook и отдельная история релизов на сайте. Это помогает потребителям понимать, что изменилось, и снижает риск неожиданного «сломалось после обновления».

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

«Прозрачная витрина»: почему Storybook здесь — центральный артефакт

В этом кейсе Storybook выступает не как «дополнительная витрина», а как основная рабочая поверхность: в нём есть вводные страницы, инструкции, документация, компоненты, а также changelog. Это делает систему пригодной для исследовательского анализа: внешний наблюдатель может увидеть структуру, правила и динамику изменений.

Синхронизация дизайна и кода

Установка/подключение как маркер инженерного слоя

Наличие отдельной страницы Installation показывает, что система живёт не только в дизайне, но и в инженерной среде: библиотека подключается как зависимость, задаёт базовые правила и ограничения, а значит снижает влияние «случайных» стилевых различий. Для исследования это важный индикатор того, что DS работает как инфраструктура, а не как файл-витрина.

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

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

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

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

Источники

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