Дизайн-система начинается там, где появляется право на изменение

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

Время чтения: 8–9 минут

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

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

Компоненты создают порядок только до первого исключения

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

У команды есть несколько вариантов. Можно изменить основной компонент, создать варианты, собрать локальную композицию или сделать полностью собственное решение.

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

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

Система ломается не тогда, когда появляется исключение. Исключения неизбежны. Она ломается тогда, когда не знает, что делать с исключениями.

Governance — это не дизайнерская полиция

Слово governance легко вызывает неправильную ассоциацию: центральная команда сидит над продуктами и проверяет, правильно ли остальные используют радиусы и цвета.

Такой подход действительно способен превратить дизайн-систему в бюрократический аппарат.

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

В IBM Carbon этот процесс формализован достаточно подробно. В систему могут вноситься изменения кода, дизайна и документации; маленькие исправления и крупные новые компоненты проходят разные процессы, а большие изменения требуют более серьёзной проверки ценности и качества.

То есть зрелая система не говорит:

Она говорит:

Разница принципиальная.

Не каждое хорошее решение должно попасть в систему

Это, вероятно, один из самых важных принципов.

Если дизайнер создал удачный компонент, который используется только в одном специфическом сценарии, его необязательно переносить в core library.

Brad Frost предлагает различать общие элементы системы и так называемые recipes — композиции, специфичные для отдельного продукта или семейства продуктов. Такой слой позволяет командам экспериментировать быстрее, используя основные элементы системы, не заставляя центральную библиотеку немедленно поглощать каждую новую конструкцию. Если несколько продуктов независимо приходят к сходному решению, оно уже становится кандидатом на повышение до уровня общего компонента.

Это хорошая модель развития:

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

Поэтому хорошая дизайн-система иногда должна уметь сказать новому компоненту «пока нет».

Стабильность и эксперимент требуют разных пространств

IBM Carbon в 2026 году формализовал эту идею через Carbon Labs — отдельную среду для компонентов, паттернов и утилит, которые ещё находятся в исследовательской стадии и не достигли определения готовности основной системы. Причина вполне практическая: раньше незавершённые эксперименты находились рядом со стабильными компонентами, из-за чего пользователям было трудно понимать, что безопасно использовать в production.

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

Поэтому системе нужны разные скорости.

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

Система становится устойчивой не потому, что всё внутри неё стабильно, а потому, что она умеет различать степень стабильности.

Definition of Done важнее количества компонентов

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

На практике рост библиотеки сам по себе ничего не доказывает.

Carbon использует подробный component checklist, где стабильность компонента определяется набором требований к дизайну, коду, тестированию и документации. Только после прохождения соответствующих критериев элемент может считаться готовым.

В этом подходе есть важная логика: компонент — это не нарисованный прямоугольник с состояниями. Это обещание системе.

Он должен вести себя предсказуемо.

Работать в коде.

Поддерживать необходимые состояния.

Соответствовать accessibility-требованиям.

Иметь документацию.

Переживать типичный и нетипичный контент.

И, что особенно важно, иметь владельца и путь дальнейшего изменения.

Добавить компонент легко. Принять ответственность за его существование гораздо дороже.

Поэтому иногда здоровая дизайн-система должна не расширяться, а сокращаться.

Система должна уметь удалять

Design tokens сделали системный слой ещё глубже

Долгое время системность преимущественно обсуждалась на уровне компонентов: кнопка, поле, dropdown, modal.

Design tokens перенесли эту идею ниже.

Цвет, размер, spacing, типографика, длительность motion и другие значения могут существовать как именованные сущности, связанные между собой и передаваемые между инструментами. В октябре 2025 года Design Tokens Community Group опубликовала финальный Community Group Report спецификации формата design tokens, направленный на унификацию их представления между различными инструментами.

Это важное изменение не потому, что появился ещё один JSON-формат.

Token превращает конкретное значение в смысловое решение.

Не #0057FF, а action-primary.

Не 16 px, а определённый spacing-role.

Значение можно изменить, сохранив назначение.

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

Чем глубже система, тем дороже случайное изменение

Консистентность — не конечная цель

У дизайн-систем есть опасное искушение: считать максимальную одинаковость показателем качества.

Если все кнопки одинаковые, все карточки используют одинаковый radius, а каждый продукт соблюдает одну сетку, система выглядит дисциплинированной.

Но продукт существует не для обслуживания дизайн-системы.

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

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

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

Слишком мало правил — система распадается.

Слишком много — перестаёт развиваться.

У дизайн-системы всегда два типа пользователей

Первый очевиден — конечный пользователь продукта.

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

Если система технически идеальна, но команды постоянно её обходят, она не выполняет свою функцию.

Именно поэтому Carbon открывает contribution process для дизайнеров и разработчиков, поддерживает office hours, guilds, issues и несколько способов участия.

Дизайн-система в этом смысле сама является продуктом.

У неё есть пользователи.

Проблемы adoption.

Документация.

Поддержка.

Версии.

Технический долг.

И даже конкуренты — локальные библиотеки, которые команды создадут сами, если центральная система окажется слишком медленной или неудобной.

Поэтому нельзя просто «внедрить дизайн-систему».

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

Главный продукт системы — не компонент

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

Поэтому зрелость design system удобнее всего проверять не вопросом:

А другим:

Кто замечает проблему?

Кто принимает решение?

Где появляется эксперимент?

Как он проверяется?

Когда становится общим?

Как остальные узнают об изменении?

Что происходит со старым решением?

Если на эти вопросы есть понятные ответы, перед нами действительно система.

Если нет — пока только хорошая библиотека.

Источники

Brad Frost — A Design System Governance Process. Практическая модель управления изменениями дизайн-системы: от обнаружения нового требования до проверки, публикации и внедрения компонента.
Brad Frost — A Design System Governance Process

Brad Frost — Maintaining Design Systems. О необходимости постоянной поддержки, governance, коммуникации изменений и организационной ответственности за систему.
Atomic Design — Maintaining Design Systems

Brad Frost — The Art of Design System Recipes. Модель разделения core system и продуктовых recipes, позволяющая продуктам экспериментировать без немедленного разрастания центральной системы.
The Art of Design System Recipes

IBM Carbon Design System — Contributing. Актуальная модель contributions, включающая дизайн, код, документацию, улучшение компонентов и разные уровни процесса для изменений разного масштаба.
Carbon — Contributing Overview

IBM Carbon Design System — Carbon Labs. Отдельный экспериментальный слой для решений, которые ещё не соответствуют критериям стабильной части системы.
Carbon Labs

IBM Carbon Design System — Component Checklist. Definition of Done для стабильного компонента, охватывающий дизайн, код, тестирование и документацию.
Carbon — Component Checklist

Design Tokens Community Group — Design Tokens Format Module 2025.10. Финальный Community Group Report, опубликованный 28 октября 2025 года и определяющий общий формат представления design tokens.
Design Tokens Format Module 2025.10