10 июля Figma опубликовала кейс Decagon о design system saturation. В кейсе этот термин используется для описания того, насколько широко компоненты дизайн-системы применяются в реальном продукте.

Это важнее, чем количество компонентов в библиотеке. Можно собрать сотни элементов в Figma, но продолжать создавать продукт из локальных решений. Тогда библиотека существует, а система фактически не работает.

Проблема не в Figma. Просто создание дизайн-системы часто начинают с технологической реализации, не определив: ✅  зачем она нужна; ✅  какие продукты охватывает; ✅ кто ею владеет; ✅  кто утверждает изменения; ✅  как дизайн связан с кодом; ✅  как измеряется реальное использование.   Figma предоставляет среду для компонентов, переменных и библиотек. Но цель, границы, ownership и governance определяет команда. В кейсе Decagon дизайн-система Deco связана с Figma, Storybook и AI-инструментами. Figma MCP передаёт AI-агентам контекст дизайна и компонентов, а Figma Make используется для быстрого прототипирования и проверки продуктовых идей. Это хороший пример того, как AI усиливает уже существующую дизайн-систему, но не создаёт её вместо компании. Здесь важно не смешивать три понятия.

Design System — это принципы, токены, компоненты, паттерны, документация, кодовые реализации и правила развития внутри определённого продуктового или коммуникационного контура. DesignOps — организация работы дизайн-функции: люди, процессы, инструменты, взаимодействие и измерение эффективности. Design Infrastructure — более широкий контур, который связывает Design System, DesignOps, CreativeOrs, данные, ассеты, согласования, производство, автоматизацию и AI.

При нескольких проектах разрыв между этими уровнями выглядит как неудобство. При портфеле более 10 000 SKU он становится операционным риском. В моём кейсе перестройка всей дизайн-функции — семи профессиональных направлений, процессов, стандартизации и автоматизации — сопровождалась ростом выпуска проектов более чем в четыре раза. Это результат не одной библиотеки, а работы со всей дизайн-инфраструктурой.   Дизайн-система начинается с цели, границ, владельцев и правил развития. Дизайн-инфраструктура начинается с понимания того, как дизайн встроен в работу бизнеса.   В следующей публикации разберу отдельно, чем DesignOps отличается от CreativeOps и почему эти понятия тоже не стоит использовать как синонимы.