Дизайн-система против UI-кита: чем отличаются подходы

Прямой ответ

Дизайн‑система содержит правила применения и уровни значений, UI‑кит — набор готовых элементов, поэтому система определяет, как применять элемент, а кит — какие элементы доступны.

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

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

Состав и уровни значений

Состав подхода определяет, где задаются значения внешнего вида, поэтому изменение значения выполняется на разном уровне.

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

Значения в элементах кита. Значение задано внутри элемента, поэтому изменение требует правки каждого элемента с этим значением.

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

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

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

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

Правило применения определяет выбор элемента в ситуации, поэтому наличие правил отличает систему от набора элементов.

Условие применения. Система описывает, когда элемент уместен, поэтому выбор между вариантами определяется правилом.

Перечень элементов. Кит перечисляет доступные элементы, поэтому выбор между двумя подходящими выполняется на месте.

Примеры использования. Система содержит рабочие примеры с описанием назначения, поэтому поведение проверяется до применения.

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

Стоимость поддержки и масштаб продукта

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

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

Поддержка кита. Требует обновления элементов, поэтому стоимость ниже при малом числе экранов и растёт с числом элементов.

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

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

О значениях внешнего вида — в статье про дизайн‑токены; о выпуске набора элементов — в статье про публикацию библиотеки.

Сравнение по задачам

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

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

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

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

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

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

Практика: выбор подхода к систематизации

1. Оценивайте число экранов и продуктов. Объём систематизации определяется масштабом.

2. Используйте набор элементов для продукта с несколькими экранами. Расхождения устраняются правкой элемента.

3. Переходите к системе при росте числа экранов. Значение задаётся один раз, поэтому расхождения сокращаются.

4. Выделяйте значения в токены при переходе. Изменение значения не требует правки каждого элемента.

5. Описывайте условие применения элемента. Выбор между вариантами определяется правилом.

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

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

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

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

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

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

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

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

FAQ

Чем дизайн-система отличается от UI-кита? Система содержит уровни значений, правила применения и документацию. Кит — набор готовых элементов без описания условий применения.

Когда достаточно UI-кита? При продукте с несколькими экранами. Расхождения немногочисленны и устраняются правкой элемента.

Почему изменение цвета не применяется ко всем экранам в ките? Значение задано внутри каждого элемента. Изменение выполняется поэлементно, поэтому часть элементов сохраняет прежнее значение.

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

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