Хорошая система не делает всё одинаковым

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

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

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

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

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

Это довольно важная граница. Дизайн-система существует для продукта, а не продукт для дизайн-системы.

Одинаковость — самый простой вид порядка

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

На первый взгляд это просто здравый смысл. Но фактически здесь меняется определение системы.

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

Это хорошо видно за пределами интерфейсов. В сильной бренд-системе невозможно заранее нарисовать каждый будущий плакат, упаковку, выставочный стенд или публикацию. Если любой новый объект просто воспроизводит заранее утверждённый макет, бренд получает узнаваемость, но быстро теряет способность говорить. Система здесь скорее напоминает язык: грамматика сохраняется, хотя предложения постоянно меняются.

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

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

Исключение не всегда означает, что кто-то нарушил систему

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

Самый простой системный ответ — добавить ещё один параметр в компонент.

Затем ещё один.

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

Так система начинает разрушаться именно в процессе собственной защиты.

GOV.UK использует более осторожную модель. Чтобы новый компонент или паттерн попал в общую дизайн-систему, недостаточно показать, что он понадобился одной команде. Нужно доказать, что потребность встречается шире, что новое решение действительно отличается от уже существующих, протестировано на пользователях и способно работать в нескольких сервисах и контекстах.

В этом подходе исключение сначала рассматривается не как новый компонент, а как информация о границе существующей системы.

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

Это значительно здоровее идеи, что дизайн-система обязана содержать ответ на всё.

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

Но свобода сама по себе тоже ничего не решает

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

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

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

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

Цвет, типографическая иерархия, accessibility или поведение критического состояния могут требовать очень строгих правил. Композиция страницы, плотность пространства или способ соединения компонентов могут допускать значительно больше свободы. Не все решения одинаково важны для узнаваемости, доступности и пользовательского доверия.

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

Это уже не вопрос Figma или React. Это вопрос модели.

Свобода не обязательно уменьшает удобство

Особенно интересен здесь Material 3 Expressive. Новое поколение Material Design сознательно увеличило выразительность интерфейса: более разнообразные формы, размеры, цвет, движение и композиционные возможности. На поверхности это выглядит почти как отход от прежней идеи строгой унификации.

Google Research проверила часть этих изменений экспериментально в исследовании CHI 2026. Сорок восемь участников выполняли задачи в десяти приложениях, созданных по новым Material 3 Expressive guidelines и по предыдущей версии системы. В новых вариантах участники в среднем на 33% быстрее фиксировали взгляд на нужном элементе и примерно на 20% быстрее завершали задачи; субъективные оценки интерфейсов также были выше. Авторы при этом отдельно отмечают, что увеличение гибкости создаёт новые риски и требует внимательного применения.

Это исследование проведено командой Google вокруг собственной системы, поэтому его не стоит превращать в универсальное доказательство превосходства Material 3. Но оно разрушает слишком удобную связь между одинаковостью и удобством.

Более выразительный интерфейс не обязательно менее системный.

Иногда различие помогает пользователю лучше различать и сами функции.

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

Возможно, компонент вообще не является центром системы

В 2026 году группа исследователей из LEGO Group и нескольких датских университетов попыталась разобраться, что профессиональное сообщество вообще называет design system. Причина исследования показательна сама по себе: термин используется повсеместно, но разные команды вкладывают в него настолько разные значения, что это начинает создавать те же несогласованности, которые дизайн-системы должны устранять.

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

Мне кажется, в этом есть полезное смещение.

Кнопку можно скопировать.

Token можно импортировать.

Компонент можно поставить из библиотеки.

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

Именно поэтому две организации могут использовать одинаково аккуратные component libraries, но иметь дизайн-системы совершенно разной зрелости. В одной библиотека хранит формы. В другой она хранит решения и способы их продолжать.

Масштабирование — это не размножение

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

Для программного кода это действительно иногда работает.

Для дизайна — только частично.

Чем больше становится продукт, тем больше появляется ситуаций, которых исходная система никогда не видела. Новые рынки, языки, устройства, типы пользователей, законодательные требования, AI-функции, accessibility-сценарии постепенно проверяют не то, насколько хорошо система умеет повторять известное, а насколько она способна принять неизвестное.

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

Она проявляется при первом хорошем исключении.

Сломается ли компонент? Появится ли локальная копия? Будет ли команда месяц ждать решения центральной группы? Или система позволит разобраться, что именно оказалось новым: частный случай, недостающий паттерн или сигнал, что прежнее правило больше не описывает реальность?

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

Они похожи на точки давления. Именно по ним видно, где система встречается с миром.

Система хранит не форму, а пределы формы

Возможно, поэтому самые полезные дизайн-системы постепенно становятся менее похожими на каталоги.

Atlassian поверх общего ADS использует дополнительные UI kits и специализированные компоненты отдельных продуктов. GOV.UK принимает новые паттерны только после доказанной потребности и проверки их пригодности для более широкого использования. Исследования новых систем вроде Material 3 показывают, что дополнительная выразительность не обязательно разрушает функциональность.

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

Оно требует ясности относительно того, что должно оставаться общим, когда всё остальное начинает различаться.

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

Шаблон заранее знает, как должен выглядеть следующий результат.

Система — нет.

Она знает только, какие отношения нельзя потерять, пока этот результат появляется.

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

Она просто защищает себя.

Atlassian Design System — Values & Principles. Принципы системы, в которых последовательно разводятся общая основа, намеренная консистентность и необходимость не превращать систему ни в жёсткий стандарт, ни в бесконечно настраиваемый конструктор.
Atlassian Design System — Values & Principles

GOV.UK Design System — Contribution criteria. Критерии, по которым локальный компонент или паттерн может стать частью общей системы: доказанная потребность, уникальность, usability, consistency и возможность использования в различных сервисах.
GOV.UK Design System — Contribution criteria

GOV.UK Design System — Community principles. О повторном использовании существующего, доказательности изменений и необходимости проектировать решения, способные развиваться за пределами одной команды.
GOV.UK Design System — Community principles

Frank Bentley et al. — Usability Hasn’t Peaked: Exploring How Expressive Design Overcomes the Usability Plateau. CHI 2026. Исследование Material 3 Expressive и связи большей визуальной выразительности с выполнением задач и пользовательскими оценками. Источник Google Research, поэтому результаты следует учитывать вместе с заинтересованностью разработчика системы.
Google Research — Usability Hasn’t Peaked

Margrethe Nielsen, Peter Vistisen, Nanna Inie, Michael Mose Biskjaer — Exploring Current Understandings of ‘Design Systems’: Toward a Conceptual Framework. Design Research Society, 2026. Исследование различных трактовок понятия design system и попытка описать систему через элементы, свойства и участников.
Design Research Society — Exploring Current Understandings of Design Systems