Дизайн-система как внутренний продукт компании предназначен для экономии финансовых и временных/трудовых ресурсов в производственном процессе.

Помимо основной важности внедрения дизайн-системы для front-end разработчиков (storybook), также важно использовать дизайн-систему как инструмент сборки быстрых макетов для тестирования гипотез, проверки идей или визуальных композиций со стороны менеджеров, аналитиков и прочих заинтересованных лиц без привлечения ресурса дизайнеров.

Чтобы выстроить такую систему и экономить время других отделов разработки (например отдела дизайна), дизайнерам необходимо собрать архитектуру дизайн-системы таким образом, чтобы заложить в ней на этапе проектирования дизайн-системы несколько категорий:

1. Элементы (токены) — исходная сущность стиля используемая в компонентах.

Элементы это категория ядра, в котором находятся только опытные дизайнеры.

2. Компоненты — составные части более сложных объектов. В свою очередь делятся на простой компонент и комбинированный компонент.

• простой компонент — сущность состоящая из совокупности элементов. Логически обособленная, самостоятельно не функционирующая часть системы (чекбокс, кнопка, поле ввода, тогл и т.д.).

• комбинированный компонент — сущность состоящая из нескольких простых компонентов и элементов. Самостоятельно не функционирующая часть системы (пагинация, хлебные крошки, табы и т.д.).

Примечание: простой и комбинированный компоненты не существуют отдельно от блоков и шаблонов наделенных контекстными функциями, и потому не являются самостоятельно функционирующими частями системы.

3. Блоки — логически законченная, самостоятельно функционирующая часть системы. Является составной часть шаблона.

4. Шаблоны — группа блоков с условными значениями (неопределенным контентом)

Блоки, компоненты и шаблоны должны быть доступны в библиотеке для менеджеров и аналитиков, чтобы они могли без помощи дизайнеров использовать их для сборки новых шаблонов и построения сценариев для дальнейшего быстрого тестирования гипотез, осмысления новых функций и в прочих подобных действиях, независимо от команды дизайна.

После шаблонов следуют категории «страницы» и «сценарии». О них, а также о более подробном взгляде на архитектуру дизайн-системы, вы можете почитать в моей статье про архитектуру дизайн-системы. https://vc.ru/id1598278/645674-arhitektura-dizain-sistemy-kritikuem-i-predlagaem Статья довольно старая, но, возможно, даст вам свои мысли и возможности к переосмыслению.

И помните, дизайн-система должна быть системой и работать как система, без «детачей» и прочих «костылей». Достижение этой цели зависит далеко не только лишь от команды разработчиков, но в первую очередь от «зрелости» бизнеса и осознания преимуществ такой системы в перспективе.