На самом деле вам не нужна дизайн-система

[greenfork]

Интересно почитать, спасибо за точку зрения. Где вы проводите грань между дизайн системой и библиотекой визуальных компонентов? Аля сторибук, но даже не обязательно формализовывать.

Наверное для стартапа всё-таки хочется иметь набор классов CSS, которые описывают первичные и вторичные кнопки. А иногда даже выбор фреймворка, как tailwindcss, просто заставляет разносить всё по компонентам.

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

[kamushken]

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

Библиотека компонентов для меня это витрина и удобный способ переиспользовать готовые куски UI. Там может быть Storybook, может быть просто папка с React-компонентами и парой примеров. Её ценность в скорости сборки и в том, что люди видят, что уже есть.

Дизайн-система начинается там, где появляется контракт. Компоненты становятся вторичными по отношению к правилам: токены, состояния, сетка, типографика, принципы. И главное, появляется механизм контроля качества: что считается валидным использованием, кто принимает изменения, как ведётся версионирование, как вы ловите рассинхрон между макетом и кодом. Если витрина есть, а контракта и процесса нет, это библиотека.

Про набор CSS-классов для кнопок на старте я полностью согласен. Более того, я обычно считаю это разумным минимумом: пара базовых токенов + 2–3 компонента, которые встречаются везде (кнопка, инпут, бейдж, возможно модалка). Tailwind как раз подталкивает к этому естественно: в какой-то момент понимаешь, что проще вынести повторяющийся набор утилит в компонент или хотя бы в аккуратный набор классов.

Про степень свободы. Я стараюсь держать её в рамках, чтобы не плодить визуальный шум, но не превращать работу в бюрократию.

☛ Жёстко фиксирую: типографику (2–3 размера, веса), базовые отступы (шаг), радиусы (1–2 значения), нейтральную палитру и семантические цвета для статусов, состояния интерактива (hover, active, disabled, focus). Это та часть, где хаос быстро становится дорогим.

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

Если упростить до одного критерия: пока вы чаще меняете смысл и структуру экранов, чем шлифуете консистентность, вам нужна библиотека и маленький слой токенов. Дизайн-система начинается в тот момент, когда изменения становятся не поиском, а тиражированием и сопровождением.