Что такое дизайн-система и зачем она продукту

Коротко о главном

Дизайн-система — единый источник правды о том, как строится интерфейс продукта. В неё входят базовые значения (цвета, отступы, шрифты), готовые компоненты из них (кнопки, поля, карточки), правила их использования и документация. Важно, что она живёт и в дизайн-инструменте, и в коде, а обе стороны синхронизированы.

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

Из чего состоит дизайн-система

1. Дизайн-токены. Именованные значения, в которых хранятся базовые решения: color-primary, space-4, radius-md, font-size-body. Токены не привязаны к платформе, поэтому одни и те же значения можно отдавать в CSS, iOS и Android.

:root {
  --color-primary: #7c3aed;
  --color-text: #1a1033;
  --space-4: 16px;
  --radius-md: 8px;
}

В хороших системах два слоя: базовые токены (violet-600) и семантические (color-action-primary), которые на них ссылаются. Тогда смена темы — это переназначение семантических токенов, а не поиск по всем компонентам.

2. Компоненты. Переиспользуемые части интерфейса, собранные из токенов: кнопки, поля, чекбоксы, модальные окна, таблицы, навигация. У каждого компонента есть варианты (основная, второстепенная), размеры и состояния (hover, focus, disabled, error, loading).

3. Правила (гайдлайны). Когда использовать модальное окно, а когда отдельную страницу, сколько главных кнопок может быть на экране, как писать тексты ошибок, требования доступности — контраст, видимый фокус.

4. Документация. Место, где всё это описано с примерами, случаями «так можно / так нельзя» и фрагментами кода. Без документации система существует только в головах авторов.

5. Процесс и ответственность. Кто добавляет новые компоненты, как предлагаются и версионируются изменения, как команды узнают об обновлениях. Эта часть незаметна, но именно она решает, выживет ли система.

Дизайн-система, UI-кит и стайлгайд

UI-кит и стайлгайд — это части дизайн-системы, а не альтернативы ей.

Когда команде она действительно нужна

Признаки, что пора:

• Над одним продуктом работают несколько дизайнеров или фронтенд-разработчиков.
• Есть несколько продуктов или платформ (веб, мобильное приложение, админка), которые должны ощущаться родственными.
• Один и тот же компонент реализован по-разному в разных местах.
• Простые экраны делаются долго, потому что каждый элемент рисуется с нуля.
• Планируется ребрендинг или тёмная тема.

Когда рано:

• Один дизайнер и один разработчик делают MVP. Хватит небольшого UI-кита и файла с токенами.
• Направление продукта меняется каждые несколько недель. Стандартизировать нестабильные паттерны — значит закрепить неправильные.

Как начать и не перестараться

1. Проведите аудит существующих экранов: соберите все кнопки, цвета, шрифты и отступы, которые реально используются.
2. Определите токены для цвета, типографики, отступов, скруглений и теней.
3. Сделайте самые частые компоненты: кнопку, поле ввода, выпадающий список, карточку, модальное окно.
4. Повторите их в коде с теми же названиями, что и в дизайн-файле.
5. Напишите короткую документацию к каждому компоненту: назначение, варианты, состояния, примеры «можно / нельзя».
6. Растите по запросу: добавляйте компоненты, когда они нужны реальным экранам, а не «на всякий случай».

Частые ошибки

• Строить огромную библиотеку до появления экранов продукта.
• Держать компоненты только в дизайн-инструменте, пока код расходится с макетами.
• Называть токены по внешнему виду (purple-button), а не по назначению.
• Не назначить ответственного — система постепенно устаревает.