какие форматы бывают у дизайн-системы

привет, это 🔴 Коля Михайлов, руководитель дизайн-системы hh.ru хочу поделиться мыслями кое о чём

дизайн-систему часто воспринимают как бинарную вещь: она или есть, или нет

в реальности всё сложнее — дизайн-система может существовать в разных форматах, которые зависят от задач продукта

какие варианты бывают

1️⃣ дизайн-система как справочник команда фиксирует базовые элементы, приводит в порядок макеты, договаривается о паттернах дизайн-система практически не влияет на процессы, связь с кодом здесь не обязательна

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

3️⃣ дизайн-система как основа интерфейса продукта со временем дизайн-система начинает спасать от рассинхрона без неё падает скорость, а любое изменение обходится слишком дорого

4️⃣ дизайн-система как продукт внутри продукта финальный босс, самый нагруженный и сложный формат дизайн-системы на этом этапе появляются ожидания, приоритеты и конфликтующие запросы, возникает необходимость смотреть на конкретные метрики такой формат нужен не всем, но там, где без него нельзя, дизайн-система начинает жить по полноценной продуктовой логике

отдельный вопрос — связь фигмы и кода

сама по себе она не говорит о зрелости дизайн-системы, а показывает, в каком формате система работает, чего от неё ждут

на ранних этапах жёсткая связка часто оказывается не преимуществом, а дорогим авансом

дизайн-система не обязана быть большой, сложной или «зрелой» она обязана быть уместной, работать на тот запрос, который есть у продукта, и в том формате, который этот запрос требует

всё остальное обычно приводит к завышенным ожиданиям и сложностям в работе