Проектирование дизайн-системы, которая переживёт редизайн
Дизайн-система, которая умирает после первого редизайна, — не система, а библиотека компонентов. Настоящая система живёт дольше визуального стиля бренда: она описывает, как принимаются решения, а не только как выглядит кнопка. Рассказываем, что заложить в фундамент, чтобы редизайн 2027-го не превратился в переписывание с нуля.
Средняя жизнь визуального стиля продукта — три-четыре года, средняя жизнь хорошо спроектированной дизайн-системы — вдвое дольше. Разница между ними не в красоте, а в архитектуре: система, построенная на значениях, умирает вместе со значениями; система, построенная на правилах, переживает сколько угодно смен палитры. Разберём четыре уровня этой архитектуры и принципы, которые удерживают её целой.
Первое и главное правило: компоненты не знают значений. В кнопке нет цвета «#FF5A2E» — есть ссылка на токен «акцентное действие». В карточке нет отступа в 24 пикселя — есть токен «внутренний отступ уровня два». Когда бренд меняется, вы переписываете словарь значений, а не тысячи макетов. Это звучит банально ровно до первого редизайна, после которого половина продуктовых команд начинает считать пиксели заново — потому что значения были прибиты гвоздями.
Уровней токенов обычно три: примитивы («оранжевый 500», «шаг сетки 8»), семантика («цвет опасного действия», «отступ между группами») и компонентные («фон вторичной кнопки в наведении»). Смысл разделения в направлении зависимостей: компоненты зависят от семантики, семантика — от примитивов, и никогда наоборот. Примитивы меняются при редизайне чаще всего, компонентные — почти никогда: это и есть признак здоровой системы.
Отдельно про синхронизацию. Пока токены живут отдельно в Figma и отдельно в коде, они расходятся с каждой пятой задачей. Единственный рабочий способ, который мы пробовали, — токены как код: единый источник в репозитории, из которого генерируются и переменные дизайнера, и CSS-переменные разработчика. Ручная синхронизация двух словарей не выживает дольше квартала.
Типографика — самая долгоживущая часть любой системы. Палитра и иконки меняются с каждым редизайном, а шкала размеров, интерлиньяж и ритм отступов живут десятилетиями: они про чтение, а не про моду. Именно поэтому шкалу проектируют первой и защищают строже всего. Хорошая шкала — это пять-семь ступеней с чёткими ролями: заголовок страницы, заголовок раздела, подзаголовок, основной текст, подпись. Каждая ступень имеет заданный интерлиньяж и допустимый контекст применения.
Частая ошибка — произвольные размеры в макетах: 17 пикселей здесь, 19 там, потому что «так лучше смотрится». Через год в продукте сорок размеров текста, и никто не может объяснить логику. Лекарство только одно: новый размер появляется в шкале через явное решение, а не через копирование из чужого макета. Если ступеней не хватает — сначала попробуйте обойтись имеющимися, и лишь потом расширяйте.
«
Типографика — это контракт дизайн-системы с её будущим: пока шкала жива, редизайн меняет значения, а не правила.
Второй уровень защиты — компоненты, построенные на семантических токенах и не содержащие ни одного «сырого» значения. Кнопка описывается вариантами (первичная, вторичная, опасная), размерами и состояниями — и одинаково собирается из токенов любого бренда. При смене стиля меняется тема, а не компоненты: это ключевая проверка зрелости системы. Если редизайн требует трогать каждый компонент, значит, бренд протёк в фундамент.
Проверка простая: соберите мок-тему с абсурдными значениями — зелёный акцент, огромная шкала, моноширинный шрифт. Если продукт остаётся собирательным и не разваливается, система здорова. Если расползается — вы нашли места протечки, и лучше найти их сейчас, чем в середине реального редизайна.
Ни одна система не вводится одним релизом. Рабочая стратегия — поэтапная миграция с правилом «новые экраны — только на системе»: старые экраны переводятся по мере касания, а не по отдельному плану, который всегда проигрывает фичам. Важная деталь — явный список устаревшего: компонент помечается как deprecated с указанием замены, и новые задачи на него уже не проходят ревью.
Здесь дизайн-система встречается с инженерной дисциплиной: отступления от шкалы и токенов должны ловиться автоматически, а не на глаз. Тот же принцип работает и в коде — строгий TypeScript без any ловит нарушение контрактов на этапе компиляции, точно так же, как дизайн-система ловит нарушение правил на этапе ревью. Инструменты разные, идея одна: правила, которые не проверяются машиной, — это пожелания.
Хорошая дизайн-система незаметна: в ней не думают о пикселях, потому что решения приняты, записаны и проверяются сами. Редизайн для неё — не катастрофа, а плановая смена темы: меняется словарь значений, и продукт на следующей неделе выглядит по-новому. Именно к этому состоянию стоит стремиться с первого дня — а не после третьего неудачного редизайна.
