Вам не нужна дизайн-система
Большинство команд, выпускающих дизайн-систему, играют в зрелость. Стоимость поддержки обгоняет отдачу, AI-генерация ломает всю арифметику, а связка токенов, примитивов и вкуса бьёт полноценную систему для 95% организаций.
Скорее всего, вам не нужна дизайн-система. Вам нужны несколько дизайн-токенов, небольшая библиотека компонентов и человек в команде со вкусом. То, о чём без конца постит ваш любимый дизайнерский аккаунт в Twitter, файл в Figma с 400 опубликованными компонентами и 12 темами, это полноценный продукт на полную ставку, за который ваш стартап из восьми человек платит и ничего не получает взамен.
Это мнение, которое все в индустрии считают верным и никто не произносит вслух. Счёт за поддержку реален. Отдача по большей части выдуманная. AI-генерация только увеличила разрыв между ними.
95% команд, выпускающих дизайн-систему, играют в зрелость (LARP). 5%, которым она действительно нужна, обычно не те, кто задаёт этот вопрос.
Дизайн-система это продукт, а не побочный квест
У настоящей дизайн-системы есть собственный роадмап, собственный changelog и собственные клиенты. Эти клиенты, инженеры и дизайнеры, которые выпускают сам продукт. Если никто не выделен на поддержку системы, это не система. Это слепок.
Посмотрите, кто делает дизайн-системы хорошо. У Stripe есть отдельная команда дизайн-инфраструктуры. У Shopify Polaris своя организация. У GitHub Primer публичный репозиторий с версионными релизами.
У Atlassian годы инвестиций в систему, до масштаба которой большинство команд никогда не дотянется. Каждая из них это продуктовая команда, делающая инструменты для внутренней аудитории в тысячи человек.
Теперь посмотрите на типичный вариант. Старший дизайнер шесть недель сидел в Figma, опубликовал 80 компонентов, написал страницу в Notion, которую не читает ни один инженер, и выпустил две темы. Через полгода половина компонентов устарела, токены разошлись с кодовой базой, а команда снова копирует классы Tailwind. Система не провалилась. Команда не выделила людей на её поддержку.
Счёт за поддержку, которого нет в презентации
Питч про отдачу звучит так: построим один раз, будем переиспользовать вечно. Реальная арифметика: построим один раз, потом будем поддерживать вечно, а переиспользовать кое-что иногда.
Каждый дизайн-токен нужно синхронизировать между Figma и кодом. Каждый вариант компонента нужно тестировать при обновлении фреймворка. Каждое ломающее изменение в Radix, React или Tailwind расходится по всем зависимым продуктам. Документация протухает за квартал.
Storybook ломается после обновления зависимости, и никто не замечает три недели. Опубликованная библиотека Figma отстаёт от кода на релиз. Темы расходятся. Компоненты в системе уже не те, что в продукте.
Честный подсчёт такой. Система из шести компонентов может сэкономить реальное время. Система из 200 компонентов в компании на 12 человек это налог. Часы отдачи растут линейно, часы поддержки накапливаются, и в какой-то момент линии пересекаются. Большинство команд пересекают их незаметно, потому что поддержка выглядит как сообщения в Slack в пятницу вечером, а не как строка в отчёте о прибылях и убытках.
AI-генерация схлопнула арифметику
Весь аргумент в пользу дизайн-системы держался на одной цифре: стоимость создания нового хорошо стилизованного компонента. Теперь эта цифра ошибка округления.
Джуниор-инженер может написать «дай мне страницу настроек с сайдбаром, тремя секциями и панелью сохранения, которая следует паттерну состояния загрузки» и выпустить рабочий компонент за двадцать минут. v0 по умолчанию генерирует вывод в формате Shadcn. Cursor и Claude могут отрефакторить целый флоу под существующие примитивы. Отдача, которую раньше давала дизайн-система, быстрая генерация единообразного UI, теперь бесплатный сервис в каждой IDE на рынке.
Налог на систему не изменился. Отдача рухнула. Вот и вся история. Команды, построившие дизайн-системы в 2022 году ради скорости, теперь медленнее тех, кто выпускает Shadcn плюс Tailwind плюс промпт, потому что каждый AI-инструмент обучен на втором и игнорирует первое.
5%, которым дизайн-система правда нужна
Настоящая дизайн-система окупается, только когда выполняется целый набор условий одновременно. Не хватает одного, и арифметика разваливается.
- Несколько продуктов с одной идентичностью. У Atlassian есть Jira, Confluence, Trello и ещё десяток. Одна идентичность, много поверхностей. Система это слой унификации.
- Штат в сотни человек, а не в десятки. Ниже 50 продуктовых инженеров любой компонент чинится сообщением в Slack. Выше 200 это не масштабируется, и система становится единственным путём.
- Выделенная команда design ops или дизайн-инфраструктуры. Дизайн-система без владельца это кладбище. Владелец должен быть настоящей ролью, а не проектом на 20% времени.
- Внешние потребители. Открытые дизайн-системы вроде GitHub Primer или Shopify Polaris одновременно продукты для разработчиков. Стоимость поддержки оправдана внешним внедрением.
- Регулируемая область или область с повышенными требованиями к доступности. Здравоохранение, финансы, госсектор. Система кодирует соответствие нормам и готовность к аудиту, а такую отдачу ни одна отдельная команда не воспроизведёт.
Если команда отмечает все пять пунктов, дизайн-система верное решение. Если отмечает один-два и выпускает один продукт с 40 инженерами, дизайн-система это косплей. Материал про анти-дашборд разбирает родственный паттерн: строить инфраструктуру под размер организации, которого у вас ещё нет.
Минимально жизнеспособная визуальная система
Для 95% ответ это трёхслойный стек, который почти ничего не стоит в поддержке и даёт почти тот же результат.
| Слой | Что это | Инструменты | Стоимость поддержки |
|---|---|---|---|
| Токены | Цвет, типографика, отступы, радиусы, тени в виде переменных | Конфиг Tailwind, CSS-переменные, переменные Figma | Низкая. Один файл. Обновляется раз в квартал. |
| Примитивы | Безголовые или стилизованные компоненты, доступные по умолчанию | Shadcn, Radix, Headless UI, примитивы Cal.com | Низкая. Скопированы в код, не поддерживаются. Обновляются по необходимости. |
| Вкус | Человек, который знает, когда нарушать правила | Старший дизайнер или инженер с дизайнерским чутьём | Бесплатно, если наняли хорошо, бесконечно дорого, если нет. |
Вот и весь стек. Токены дают единообразие. Примитивы дают доступность и поведение. Вкус даёт слой, который не закодирует ни одна система: суждение о том, когда правила должны прогнуться.
Команды, выпускающие самые чистые продукты в 2026 году, используют вариацию этого подхода. Linear работает на крошечном наборе токенов, кастомных примитивах и одержимом вкусе. Vercel выпускает тяжёлый конфиг Tailwind плюс собственные примитивы.
Cal.com публикует свои примитивы открыто. Resend и Loops выпускают UI в духе Shadcn с фирменными токенами сверху.
Notion работает на небольшом наборе токенов и намеренно узком словаре компонентов. Ни у одной из них нет «дизайн-системы» в понимании Atlassian. Зато у всех есть стек маркетингового сайта, который выглядит более цельно, чем у компаний в десять раз крупнее.
Почему Shadcn съедает категорию дизайн-систем
Shadcn это не библиотека компонентов. Это механизм доставки нового стандарта. Примитивы копируются прямо в кодовую базу, стилизуются Tailwind и доступны, потому что всю тяжёлую работу под капотом делает Radix. Пользователь владеет компонентами, может свободно их править и никогда не блокируется апстрим-релизами.
Это смертельный удар для большинства внутренних дизайн-систем. Раньше команды строили свои ради контроля. Shadcn даёт контроль бесплатно. Раньше команды выпускали Storybook ради удобства поиска.
Shadcn публикует документацию открыто, и AI-инструменты её индексируют. Раньше команды публиковали библиотеки Figma ради единообразия. Примитивы Shadcn достаточно единообразны, чтобы любой промпт на их основе давал результат, который команда уже умеет оценивать.
Shadcn плюс Tailwind плюс набор токенов это визуальный стек по умолчанию в 2026 году. Его по умолчанию выдаёт каждый современный AI-инструмент для генерации кода. Его первым выпускает каждая новая продуктовая команда. Это модель примитивов плюс вкуса в двух репозиториях и одном конфиге. Дизайн-система как отдельный артефакт со своим пайплайном публикации и своей командой теперь частный случай.
Когда настоящая система наконец окупается
Честная версия вопроса «нужна ли нам дизайн-система?» звучит так: «мы уже пересекли порог поддержки?»
| Сигнал | Нужна система? |
|---|---|
| Два инженера за неделю выпустили непохожие кнопки | Нет. Добавьте файл с токенами. |
| Три продукта делят бренд и визуально расходятся | Возможно. Начните с общих токенов. |
| Несколько команд каждый квартал по-разному выпускают один и тот же компонент | Да. Пора делать общие примитивы. |
| Конкретный компонент за полгода переписали четыре команды | Да. Переведите его в систему. |
| Онбординг нового дизайнера занимает две недели, потому что договорённости живут в устной традиции | Да. Теперь система окупается. |
| Внешние разработчики используют ваши компоненты | Да. Система это продукт. |
| Аудиты на соответствие нормам или доступность попали в ваш роадмап | Да. Закодируйте один раз. |
Если команда набирает три сигнала или больше, настоящая система оправдана. Если один, хватит файла с токенами. Та же логика в том, как проблема страницы с ценами и онбординг без онбординга решают задачу координации на уровне поверхности, а не на уровне системы.
Закономерность, а затем панчлайн
Понты про зрелость перевёрнуты с ног на голову. Команды, выпускающие самые цельные продукты в 2026 году, не те, у кого самые большие дизайн-системы. Это те, у кого самый маленький визуальный долг. Компактный набор токенов, тонкий слой примитивов и дизайнер со вкусом, который часто говорит нет.
Настоящие дизайн-системы это инфраструктура для организаций, которые переросли альтернативу. Это не веха, которую должна пройти каждая команда. Это не статусный символ. Это не ответ на «мы хотим выглядеть профессиональнее».
Команда, которая строит её, не заработав бюджет на поддержку, выпускает тот же продукт в более медленном темпе и с более тяжёлым файлом. Та, что выпускает токены плюс Shadcn плюс вкус, выпускает тот же продукт быстрее и тратит сэкономленное время на то, чтобы починить проблему страницы настроек.
Вопрос не в том, «есть ли у нас дизайн-система?». Вопрос в том, «платим ли мы за поддержку на правильном уровне абстракции?»
FAQ
Чем дизайн-система отличается от библиотеки компонентов?
Библиотека компонентов это набор переиспользуемых частей UI. Дизайн-система это библиотека компонентов плюс токены, плюс документация, плюс управление, плюс владелец, плюс ритм релизов. Большинство команд выпускают библиотеку компонентов и называют её системой. Это не одно и то же, и у второго есть стоимость поддержки, которой нет у первого.
Shadcn это дизайн-система?
Нет. Shadcn это механизм доставки примитивов. Компоненты копируются в кодовую базу и принадлежат команде. Нет центральной библиотеки, нет графика апстрим-релизов и нет управления.
В этом и суть. Команда получает отдачу от системы без счёта за поддержку.
Когда стартапу стоит инвестировать в дизайн-систему?
Когда верны минимум три пункта: несколько продуктов с общей идентичностью, больше пятидесяти инженеров, делающих UI, выделенная роль design ops, внешние потребители компонентов или регулируемая область. Ниже этой планки выпускайте токены плюс примитивы плюс вкус, а сэкономленные часы вкладывайте в сам продукт.
CTA
Хотите продукт, где визуальная система соответствует размеру команды? Brainy делает стеки из токенов и примитивов для 95% и полноценные дизайн-системы для 5%, с расчётом на реальный бюджет поддержки. Нанять Brainy. Мы скажем, по какую сторону черты вы находитесь, прежде чем вы потратите квартал не на тот артефакт.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
