Содержание · 8
Библиотека компонентов — не дизайн-система. Разбираем, из чего она состоит на самом деле, когда её стоит заводить и почему большинство систем умирает через год.
Из чего состоит система
Дизайн-система — это не файл в редакторе макетов, а набор из четырёх частей: принципы, токены, компоненты и процесс. Отсутствие любой из них превращает систему в библиотеку, которая устаревает за полгода.
Чаще всего в проектах есть только компоненты. Именно поэтому они и не работают: непонятно, как принимать решения, когда нужного компонента нет.
Токены
Токен — это именованное значение: не «#1B37E0», а «accent/primary». Смысл в том, что имя переживает значение: цвет можно поменять, и все места, где он используется, обновятся согласованно.
Хорошая система токенов состоит из двух уровней: базовые значения (палитра, шкала размеров) и семантические (фон, текст, граница, акцент), которые ссылаются на базовые.
- Базовый уровень: blue-600, space-4, text-lg.
- Семантический: color-accent, surface-raised, text-secondary.
- Компонентный (по желанию): button-bg-hover.
- Тёмная тема — это переопределение семантического уровня.
Когда система нужна
Дизайн-система — накладной расход. Она окупается при определённом масштабе и не окупается ниже него.
Когда заводить систему
Почему системы умирают
Основная причина — отсутствие владельца и процесса. Систему собирают на энтузиазме в свободное время, после чего продукт уходит вперёд, а система остаётся в прошлой версии.
Вторая причина — избыточность: команда пытается описать всё сразу, тратит месяцы и выкатывает систему, которая уже не соответствует продукту.
- Нет выделенного владельца — система не обновляется.
- Слишком много компонентов на старте.
- Дизайн и код расходятся: разные названия, разные значения.
- Нет способа предложить изменение — команды делают своё.
Систему собирают на энтузиазме в свободное время, после чего продукт уходит вперёд, а система остаётся в прошлой версии.
Как измерить, что система работает
Дизайн-система — расход, и как любой расход её стоит измерять. Полезнее всего два показателя. Первый — доля интерфейса, собранная из компонентов системы: её видно по коду, и она честно показывает, пользуются системой или обходят её. Второй — время от постановки типовой задачи до готового макета: если оно не падает, система решает не ту проблему.
Дополнительный сигнал даёт количество исключений. Один-два обхода в квартал — нормальная жизнь; десяток означает, что система описывает не то, с чем реально работает команда, и её нужно менять, а не защищать.
Как принимаются изменения
Самая недооценённая часть системы — процедура внесения нового. Пока она не описана, изменения происходят двумя способами: либо через владельца в личных сообщениях, либо в обход. Оба ведут к расхождению.
- Предложение формулируется как задача, а не как готовый компонент: какая проблема и где встречается.
- Проверка на дублирование: решает ли задачу существующий компонент с новым состоянием.
- Порог включения: правило попадает в систему после второго-третьего повторения, а не с первого случая.
- Версионирование и запись изменений: что поменялось, почему и что сломается у потребителей.
- Срок жизни устаревшего: компонент помечается устаревшим и удаляется только после переезда.
Несколько брендов на одной системе
Когда продуктов становится больше одного, возникает соблазн сделать отдельную систему под каждый. Обычно разумнее разделить слои: общая механика компонентов и структура токенов остаются едиными, а различия выносятся в тему — палитру, типографику, радиусы, плотность.
Практическое условие для этого — семантические имена. Система, где компоненты ссылаются на «синий-600», не темизируется; система, где они ссылаются на «поверхность-акцент», меняет облик переопределением одного слоя. Это же условие делает возможной тёмную тему без дублирования компонентов.
Что в итоге
Дизайн-система — это принципы, токены, компоненты и процесс. Без последнего пункта она превращается в архив.
Начинайте с малого, назначьте владельца и добавляйте компонент только тогда, когда он понадобился во второй раз.
Коротко
- Когда дизайн-система действительно нужна?
- Когда одинаковые задачи решаются многократно и разными людьми. Признак, что момент настал: в макетах несколько версий одной кнопки и никто не может сказать, какая правильная.
- Почему дизайн-системы перестают работать?
- Три причины: расхождение с кодом, отсутствие владельца и избыточность. Первая делает систему архивом, вторая — набором исключений, третья — неподъёмной в поддержке.
- Можно ли сделать одну систему на несколько брендов?
- Да, если компоненты ссылаются на семантические имена токенов, а не на конкретные значения. Тогда различия выносятся в тему — палитру, типографику, плотность, — а механика остаётся общей.
Токены дизайн-системы
Именование определяет живучесть системы. Разбираем схемы наименования, уровни абстракции и типичные ошибки, из-за которых токены становятся бесполезными.ДальшеЧитайте также
Посмотреть примеры
Нашли ошибку или неточность в атрибуции? Напишите нам
Обсуждение
Загружаем…