TL;DR. Дизайн-система — это не набор компонентов в Figma и не style guide в PDF. Это живое соглашение о том, как выглядит и ведёт себя интерфейс: дизайн-токены, компоненты, правила использования и документация, которая позволяет любому дизайнеру или разработчику делать новые страницы, не нарушая консистентность.
Без неё каждый новый блок — это лотерея: «тот же синий или чуть другой?». Дальше — зачем это нужно даже среднему бизнесу, как отличить настоящую систему от Figma-файла с компонентами, и что из этого реально выживает после ухода автора проекта.
Откуда вообще этот вопрос
Нас позвали на проект — редизайн корпоративного сайта, который существовал три года. За это время над ним работало два разных дизайнера, сменилось три разработчика, и каждый добавлял блоки по-своему. К моменту нашего прихода на сайте было четыре варианта «основного синего», кнопки с восемью разными отступами, и заголовки H2, которые на разных страницах выглядели по-разному — потому что стили переопределялись локально.
Перекрасить это в единый вид было невозможно без полного пересмотра CSS. Редизайн занял вдвое больше времени, чем мог бы, потому что сначала нужно было разобраться, что вообще есть на сайте. Именно так выглядит проект без дизайн-системы через два года.
Что такое дизайн-система и чем она отличается от набора компонентов
Многие путают дизайн-систему с библиотекой компонентов в Figma или со style guide — документом, который описывает цвета и шрифты. Это части системы, но не вся система.
Настоящая дизайн-система состоит из трёх слоёв:
- Дизайн-токены — именованные переменные для всех базовых решений: цвета, отступы, радиусы, тени, типографика. Не «синий #2563EB», а
color-primary-600. Токен можно поменять в одном месте — и он обновится везде, где используется. - Библиотека компонентов — кнопки, карточки, формы, навигация — собранные из токенов и задокументированные: когда использовать, какие варианты есть, чего делать нельзя.
- Документация и правила — гайдлайны по тону, сетке, иконкам, состояниям компонентов (hover, disabled, error). Без этого компоненты есть, но люди продолжают использовать их по-своему.
Figma library — это второй слой без первого и третьего. Это полезно, но недостаточно: без токенов компоненты рассыпаются при первом же изменении цветовой схемы, а без документации новый дизайнер всё равно делает свои интерпретации.
Артефакт | Что даёт | Чего не хватает |
|---|---|---|
Style guide (PDF) | Зафиксированные цвета и шрифты | Не живёт в инструментах, быстро устаревает |
Figma library | Переиспользуемые компоненты | Нет токенов, нет правил использования |
Storybook без токенов | Компоненты в коде | Дизайн и код расходятся при первом обновлении |
Полная дизайн-система | Токены + компоненты + документация | Требует инвестиций на старте |
Storybook — это отдельная история: он живёт на стороне разработки и позволяет документировать React-компоненты вместе с их состояниями. В связке с Figma и дизайн-токенами это уже зрелая система, где дизайн и код синхронизированы. Разработчик открывает Storybook и видит все компоненты в их состояниях — это лучше, чем любой PDF-документ, потому что это живой код, который можно проверить прямо в браузере. Клиент тоже может открыть Storybook как каталог компонентов и убедиться, что реализация совпадает с согласованным дизайном.
Почему система должна переживать автора
Главный критерий качества дизайн-системы — не то, насколько она красива, а то, насколько легко с ней работает человек, который не участвовал в её создании.
Дизайнеры уходят. Разработчики меняются. Агентства заканчивают контракт. Если система жива только в голове у одного человека или понятна только тому, кто её строил, — это не система, это технический долг в ожидании момента, когда он взорвётся.
Поэтому мы закладываем два жёстких требования к любой системе, которую выпускаем:
Всё именовано и объяснено. Каждый токен имеет понятное имя и комментарий. Каждый компонент в Figma — описание, когда использовать и когда нет. Каждый компонент в Storybook — примеры всех состояний и props. Новый участник команды должен разобраться без звонка автору.
Есть единый источник правды. Figma и код должны говорить об одном. Если токен spacing-4 в Figma — это 16px, то в Tailwind или CSS-переменных он тоже 16px. Рассинхрон между дизайн-файлом и реализацией — это начало хаоса, который мы видели на проекте выше.
Когда дизайн-система оправдана, а когда — нет
Мы честно скажем: для лендинга из пяти блоков дизайн-система — это оверинжиниринг. Токены и библиотека компонентов оправданы там, где продукт будет развиваться: добавляться новые страницы, разделы, возможно — новые продукты под тем же брендом.
Практические триггеры, при которых мы рекомендуем закладывать систему:
- Сайт будет расти: планируются новые лендинги, личный кабинет, отдельные продуктовые страницы.
- Над интерфейсом будут работать больше одного человека (дизайнер + разработчик или несколько разработчиков).
- Продукт выйдет на несколько каналов: веб, мобильное приложение, email-рассылки — и нужно держать единый визуальный язык.
- Клиент хочет самостоятельно редактировать контент через CMS — тут важно, чтобы редактор не мог сломать вёрстку выбором «неправильного» варианта.
Если ни один пункт не про вас — честный ответ: начните с простого style guide и хорошей Figma library. Систему можно вырастить потом. Дизайн-система — это инвестиция, которая окупается на горизонте полутора-двух лет; для короткоживущего проекта она избыточна по определению.
Что происходит с сайтом без дизайн-системы через два года
Это не абстрактный риск — мы видели эту картину на нескольких проектах, которые к нам приходили на редизайн или поддержку. Без системы сайт деградирует предсказуемо: каждый новый раздел добавляется «по образцу», но образцы берутся разные. Дизайнеры интерпретируют стили чуть по-своему. Разработчики переопределяют CSS локально, потому что «так быстрее». Со временем кодовая база разбухает от дублирующихся стилей, а визуальная консистентность исчезает.
Конкретные симптомы, которые мы регулярно видим на таких проектах: кнопки одного типа с пятью разными отступами по всему сайту; три версии «основного серого» — #666, #6b7280 и #718096 — все три вроде бы для второстепенного текста, но ни одна не зафиксирована как стандарт; H2 на лендинге и H2 в блоге с разными line-height, потому что их правили в разное время разные люди. Это не катастрофа, но это постоянные трения: каждое небольшое изменение требует проверки «а точно этот вариант?», и эти трения накапливаются в часы работы и ошибки в продакшне.
Дизайн-система решает эту проблему структурно: она делает «правильное решение» самым простым. Разработчику не нужно думать, какой отступ использовать — есть токен spacing-4, и это всегда 16px. Дизайнеру не нужно искать «правильный синий» — он берёт color-primary-600 и знает, что это именно то, что было согласовано.
Как мы строим дизайн-системы на проектах
Мы начинаем не с компонентов, а с аудита: что уже есть, что реально используется, где расхождения. Для нового проекта — с инвентаризации дизайн-решений: выписываем все цвета, отступы, типографику и смотрим, где можно зафиксировать токены.
Дальше строим слоями. Сначала токены — в Figma Variables и параллельно в CSS-переменных или Tailwind config, чтобы дизайн и код с первого дня говорили одинаково. Потом базовые компоненты: типография, кнопки, формы, карточки. Каждый компонент фиксируется в Storybook со всеми состояниями — это и документация, и тест: если компонент не рендерится в Storybook без ошибок, он не считается готовым.
Документацию пишем по ходу, а не в конце. В конце её не пишет никто — это мы знаем по опыту. Поэтому правило простое: компонент без описания «когда использовать» и «чего не делать» не считается принятым в систему.
Отдельная тема — версионирование. Когда дизайн-система используется на нескольких проектах одновременно, изменение компонента в одном месте может ломать другие. Мы решаем это через явные правила: изменения, ломающие обратную совместимость (breaking changes), помечаются отдельно и согласовываются с командами всех зависимых проектов до применения. Это не бюрократия — это страховка от ситуации, когда обновление кнопки в одном проекте неожиданно меняет её вид в трёх других.
Важный момент, который часто упускают: дизайн-система — это не проект с датой завершения. Это продукт, который живёт и развивается вместе с сайтом. Новые компоненты добавляются, старые пересматриваются, документация обновляется. Без этого обслуживания система через год начинает отставать от реального кода и теряет ценность. Поэтому мы всегда оговариваем с клиентом: кто отвечает за поддержку системы после передачи — внутренняя команда или мы на поддержке.
Дизайн-система и CMS: как они работают вместе
Отдельная тема, которую часто упускают при обсуждении дизайн-систем: как система соотносится с CMS, через которую клиент редактирует контент. Это важно, потому что редактор в CMS — тоже пользователь системы, и если он может собрать страницу из компонентов произвольным образом, вся консистентность рассыпается.
В наших проектах мы используем Payload CMS — это даёт полный контроль над тем, какие блоки доступны редактору и в каком порядке он может их использовать. Компоненты дизайн-системы реализуются как блоки в Payload: редактор выбирает из заранее определённого набора, а не рисует страницу с нуля. Это означает, что даже человек без дизайнерских навыков не может нарушить визуальную консистентность — он просто не имеет доступа к «неправильным» вариантам.
Figma-компоненты и Payload-блоки при таком подходе соответствуют друг другу один к одному: дизайнер добавляет новый тип блока в Figma, разработчик реализует его в Payload, редактор получает его в интерфейсе. Это работает в обе стороны: если дизайнер хочет изменить поведение блока, он сначала обновляет компонент в Figma с документацией, а разработчик затем обновляет реализацию. Система остаётся согласованной.
Это противоположность ситуации с конструкторами типа Tilda или WordPress с page builder, где редактор может переставлять блоки произвольно, менять цвета и отступы вручную. Такая гибкость звучит как преимущество, но на практике она означает, что через год сайт выглядит как набор несвязанных страниц, каждую из которых делал разный человек в разное время. Для контентных проектов это может быть приемлемым компромиссом. Для брендового B2B-сайта — нет.
Что такое дизайн-система простыми словами
Это набор правил и инструментов, которые позволяют создавать новые страницы и разделы сайта, не придумывая дизайн заново с нуля. Цвета, кнопки, отступы, типографика — всё зафиксировано один раз и переиспользуется. Как конструктор: из готовых блоков можно собирать новые страницы и быть уверенным, что они выглядят консистентно.
Чем дизайн-система отличается от style guide
Style guide — это обычно статичный документ с описанием цветов, шрифтов и правил бренда. Дизайн-система — это живая инфраструктура: она существует в Figma, в коде и в документации одновременно, и обновляется вместе с продуктом. Style guide устаревает через полгода; система — нет, если её поддерживать.
Нужна ли дизайн-система небольшому сайту
Зависит от планов на развитие. Для статичного сайта-визитки или короткого лендинга — нет, избыточно. Для корпоративного сайта, который будет пополняться разделами и за которым работают несколько людей, — да, иначе через год будет то, что мы описали в начале статьи.
Сколько стоит создать дизайн-систему
Зависит от масштаба. Минимальная система под корпоративный сайт — токены и базовые компоненты в Figma и Storybook — это несколько недель работы дизайнера и разработчика. Полноценная система для продуктовой компании с множеством компонентов и подробной документацией — это месяцы. Мы всегда начинаем с минимально достаточного для текущего проекта и закладываем расширяемость, а не строим «на вырост» с запасом ×10.
Что такое дизайн-токены
Дизайн-токены — это именованные переменные для базовых визуальных решений: цветов, отступов, радиусов, теней, размеров шрифтов. Вместо того чтобы хардкодить #2563EB в каждом месте, вы используете color-primary-600 — и если бренд меняет оттенок синего, вы меняете одну переменную, а не ищете все вхождения по всему коду. Токены — это фундамент любой масштабируемой дизайн-системы.
