Дизайн-система — это не библиотека компонентов. Это договор

Первый раз, когда мы собирали дизайн-систему, мы думали, что главное — это кнопки, формы и иконки. Сделали Figma-файл, загрузили в код, провели презентацию. Думали, проблема решена. Через два месяца выяснилось: разработчики всё ещё рисуют свои отступы. Копирайтеры пишут свои заголовки. Аналитики добавляют свои дашборды без стилей. Система существует, но её не используют. Почему? Потому что мы спроектировали артефакты. Но не спроектировали процесс. Дизайн-система — это не папка с файлами. Это живой договор между всеми, кто касается продукта. Договор о том, как мы принимаем решения, когда сталкиваемся с неоднозначностью. Что мы изменили: Перестали говорить «используйте компоненты». Начали говорить «вот как решать типовые задачи». Не «кнопка primary», а «когда использовать primary, когда secondary, а когда ссылку». Контекст важнее формы. Добавили принцип «один источник правды». Если компонент меняет поведение, он меняется в коде, в Figma, в документации одновременно. Иначе рассинхрон. А рассинхрон — это баги, которые не ловятся тестами. Ввели роль «хранителя системы». Не дизайнера-полицейского. А человека, который помогает командам адаптировать систему под новые задачи, не ломая целостность. Он не запрещает. Он направляет. Сделали систему открытой. Не «только для дизайн-команды». Любой разработчик может предложить изменение. Любой тестировщик — сообщить о несоответствии. Система растёт не сверху вниз. А вокруг реальных кейсов. И главное: мы перестали считать систему «завершённой». Она никогда не будет завершённой. Продукт меняется. Рынок меняется. Пользователи меняются. Система должна быть достаточно гибкой, чтобы выдержать это, и достаточно строгой, чтобы не превратиться в хаос. Сейчас, когда дизайнер открывает новый макет, он не рисует с нуля. Он собирает. Как конструктор. И это экономит не дни. Это экономит нервы. Дизайн-система не делает продукт красивым. Она делает процесс предсказуемым. А предсказуемость — это основа масштабируемости.