Дизайн-система: с чего начать и как не забросить
Как выстроить дизайн-систему поэтапно: токены, компоненты, документация и синхронизация макетов с кодом — без месяцев подготовки и лишних затрат.
Дизайн-система нужна не ради красоты, а ради скорости: когда кнопки, поля и отступы определены один раз, новая страница собирается за часы, а не за дни. При этом большинство дизайн-систем умирает на этапе «нарисовали библиотеку в макетах, а в коде всё по-старому». Разберу, как этого избежать.
Четыре уровня зрелости
- Стайл-гайд: зафиксированы цвета, шрифты, отступы. Живёт в документе.
- UI-кит: набор переиспользуемых компонентов в макетах.
- Дизайн-система: токены, правила применения, состояния, документация.
- Платформа: токены и компоненты синхронизированы между макетами и кодом, изменения раскатываются централизованно.
Перепрыгивать уровни не нужно. Большинству команд достаточно третьего, а четвёртый оправдан там, где несколько продуктов и несколько команд.
Начинайте с токенов
Токены — это именованные значения: цвета, типографика, отступы, радиусы, тени. Ключевое правило — имена по смыслу, а не по внешнему виду. «Основной цвет действия» переживёт ребрендинг, а «синий-500» — нет. Семантические имена позволяют позже добавить тёмную тему без переписывания компонентов.
- Цвета: фон, текст, поверхность, граница, основной, опасный, успешный.
- Типографика: 4–6 размеров, не больше двух шрифтов.
- Отступы: одна шкала, кратная 4 пикселям.
- Радиусы и тени: 2–3 значения, иначе интерфейс теряет единство.
Какие компоненты делать первыми
Не пытайтесь описать всё. Соберите статистику по существующим экранам: обычно 80% интерфейса состоит из десятка элементов.
| Очередь | Компоненты | Почему |
|---|---|---|
| Первая | Кнопка, поле ввода, ссылка, заголовки | Встречаются на каждом экране |
| Вторая | Карточка, таблица, модальное окно, уведомление | Основные способы подачи данных |
| Третья | Фильтры, шаги, графики, пустые состояния | Нужны не везде и часто специфичны |
Почему дизайн-системы забрасывают
- Её делают «проектом» на три месяца вместо постепенной работы внутри задач.
- Нет владельца: правки вносят все, правила не обновляются.
- Макеты и код расходятся, и разработчики перестают доверять библиотеке.
- Слишком много вариантов компонентов: проще написать свой, чем разобраться в чужих.
Живая дизайн-система — та, которую быстрее использовать, чем обойти. Всё остальное решается регламентами, и обычно безуспешно.
Практичный старт: выделите один спринт на токены и пять базовых компонентов, переведите на них одну реальную страницу и дальше расширяйте систему только тогда, когда очередная задача этого требует.