Когда дизайн-система начинает мешать продукту

Дизайн-система — это договорённость, а не музей компонентов. Она устаревает ровно в тот момент, когда продукт решает новую задачу, которой не было при её создании.

Симптомы

• Каждый новый экран требует исключения
• Компоненты копируют, а не переиспользуют
• Обсуждение отступов занимает больше времени, чем сценарий

Что помогает

Как обновлять систему без переписывания продукта

1. 01Найдите компоненты, которые чаще всего обходят вручную.
2. 02Разделите системные правила и продуктовые исключения.
3. 03Обновляйте библиотеку через реальные сценарии, а не через абстрактные UI-состояния.

Зрелая дизайн-система не запрещает продукту развиваться. Она задаёт базу, но оставляет место для сценариев, которые требуют другого ритма, плотности или приоритета информации.

Практический разбор

• Найдите места, где команда постоянно обходит компоненты через кастомные стили.
• Проверьте, какие сценарии система ускоряет, а какие делает сложнее.
• Сравните компоненты с реальными пользовательскими задачами, а не только с библиотекой состояний.

Как внедрять

1. 01 /

   Выделить продуктовые исключения

   Не каждое отклонение от системы ошибка: иногда сценарий требует другой плотности, акцента или структуры.

2. 02 /

   Обновлять через реальные экраны

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

3. 03 /

   Оставить правила выбора

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

Что измерять

Ошибки, которые портят результат

• Не превращайте дизайн-систему в запрет на развитие продукта.
• Не добавляйте новый компонент под каждый частный экран.
• Не оценивайте систему по красоте библиотеки: важна скорость и качество решений.