Как стать автором
Обновить

Архитектура дизайн-системы. Критикуем и предлагаем

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров4.2K
Всего голосов 2: ↑2 и ↓0+2
Комментарии2

Комментарии 2

В целом хорошо, но взгляд на токены устаревший. Если продукт требует дизайн-систему, то он достаточно масштабен и не конечен. В этом случае мы токенами покрываем все элементы цепочки «атом – ⋯ – страница», как в статике, так и в динамике. Масштаб покрытия ограничивается только ресурсами и целесообразностью. Я называю это облаком токенов, в котором существуют все элементы системы :). В итоге получается инструмент, с помощью которого разработчики быстро и просто создают продукт, а дизайнер (или DesignOps) может управлять продуктом напрямую, мимо разработчиков, просто редактируя значения токенов.

Спасибо за комментарий.

Токены в этой части упоминаются в рамках классического понимания, для общего представления, т.к. эта часть про архитектуру структурного построения дизайн-системы по её сущностям. В третей части мы как раз раскроем тему про токены более подробно, не в таком устаревшем и простом понимании, как упоминается в данной части.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации