Дизайн-система: из чего состоит и как устроена

Прямой ответ

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

{ "color": { "text": { "value": "#1a1a1a" } } }

Разделение на уровни позволяет изменять значения токенов без правки компонентов, а состав шаблонов — без изменения токенов. О формате токенов — в статье про дизайн-токены.

Уровни системы и границы между ними

Каждый уровень отвечает за свою часть решения, поэтому изменение выполняется на уровне, которому оно принадлежит.

Токены. Содержат значения цвета, размера и отступа, поэтому правка значения применяется ко всем компонентам, использующим токен.

Компоненты. Используют токены вместо литеральных значений, поэтому внешний вид изменяется через токен без правки компонента.

Шаблоны. Собирают компоненты в экран, поэтому новый экран составляется из существующих элементов без создания нового компонента.

Практическое следствие: компонент с литеральным значением цвета не реагирует на изменение токена, поэтому правка требует поиска всех мест с литералом.

Отдельный аспект — направление зависимости. Компонент зависит от токена, но не от шаблона, поэтому изменение состава экрана не затрагивает компоненты. Обратная зависимость создаёт связь, при которой изменение экрана требует правки компонента.

Правила применения и документация

Правило применения определяет, в какой ситуации используется элемент, поэтому документация содержит не только пример, но и условие использования.

Условие применения. Описание состояния, при котором элемент уместен, поэтому выбор элемента не зависит от предпочтений.

Варианты элемента. Перечень допустимых состояний и размеров, поэтому комбинация, не описанная в правилах, не используется.

Пример использования. Работающий пример с описанием назначения, поэтому поведение элемента проверяется до применения в продукте.

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

Порядок внедрения и объём системы

Объём системы определяется числом экранов, использующих общие элементы, поэтому внедрение начинается с повторяющихся частей.

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

Уникальные экраны. Экран, встречающийся один раз, не требует общего компонента, поэтому создание компонента для единичного случая увеличивает объём системы без пользы.

Переходный период. Существующие экраны переводятся на компоненты постепенно, поэтому старая и новая реализация сосуществуют до завершения перевода.

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

О переиспользуемых элементах — в статье про web components; о требованиях к элементам — в статье про доступность интерфейсов.

Практика: построение уровней системы

1. Начинайте с токенов. Значения цвета и отступа задаются до создания компонентов, поэтому компоненты используют токены сразу.

2. Не используйте литеральные значения в компонентах. Изменение токена применяется ко всем элементам без правки компонента.

3. Создавайте компонент только для повторяющегося элемента. Элемент с единственным применением не требует компонента.

4. Описывайте условие применения, а не только внешний вид. Выбор между вариантами определяется правилом.

5. Фиксируйте допустимые варианты элемента. Комбинация, не описанная в правилах, не применяется.

6. Переводите существующие экраны постепенно. Старая и новая реализация сосуществуют до завершения перевода.

7. Ведите документацию вместе с изменением элемента. Описание, отставшее от реализации, вводит в заблуждение.

Рекомендации:

1. Не создавайте компонент для единичного экрана. Объём системы растёт без сокращения расхождений между экранами.
2. Разделяйте токен и его применение в компоненте. Компонент ссылается на токен, поэтому значение изменяется в одном месте.
3. Не допускайте зависимости компонента от шаблона. Изменение экрана не должно требовать правки компонента.
4. Фиксируйте правило перевода экрана на компонент. Переходный период завершается по явному признаку.
5. Пересматриваем состав компонентов при изменении продукта. Элемент, ставший повторяющимся, требует систематизации.

Практический сценарий: изменение цвета не применилось ко всем экранам

Контекст: значение основного цвета изменилось, но часть экранов отображала прежнее значение.

1. Диагностика. Поиск показал, что часть компонентов содержала литеральное значение цвета, а часть ссылалась на токен. Изменение токена применилось только к компонентам со ссылкой, поэтому экраны с литералом сохранили прежнее значение.
2. Причина. Компоненты создавались до введения токенов, поэтому значения задавались непосредственно, и перевод на токены не был завершён.
3. Действия. (а) Составили перечень компонентов с литеральными значениями, чтобы объём правки был известен; (б) заменили литералы на ссылки на токены, чтобы значение задавалось в одном месте; (в) добавили проверку на отсутствие литеральных значений цвета в компонентах, чтобы новый компонент не повторял ошибку; (г) перевели оставшиеся экраны на компоненты системы, чтобы экраны без компонента не содержали собственные значения; (д) применили изменение токена и убедились, что значение обновилось на всех экранах.
4. Результат. Изменение значения токена применяется ко всем экранам, поскольку компоненты ссылаются на токен вместо литерального значения.

Вывод: изменение значения не применяется к компоненту с литеральным значением, поэтому систематизация требует завершения перевода компонентов на токены. Проверка на отсутствие литералов предотвращает возвращение расхождения при создании нового компонента.

FAQ

Из каких уровней состоит дизайн-система? Из токенов, компонентов, шаблонов и документации. Каждый уровень отвечает за свою часть решения.

Почему изменение токена не применилось к компоненту? Компонент содержит литеральное значение вместо ссылки на токен. Правка токена не затрагивает литерал.

Когда создавать компонент системы? Когда элемент повторяется на нескольких экранах. Компонент для единичного применения увеличивает объём системы без сокращения расхождений.

Что описывать в документации элемента? Условие применения, допустимые варианты и работающий пример. Описания внешнего вида недостаточно для выбора между вариантами.

Источники: W3C Design Tokens, Semantic Versioning, RFC 8259 JSON — ссылки в шапке.