Дизайн-система почти всегда начинается как решение проблем. А потом незаметно становится одной из них

Я видел это несколько раз в продуктовых командах. В чем это обычно проявляется:

Когда изменение кнопки превращается в проект

И чтобы поменять один компонент, вам и вашей команде нужно обновить токены, пройти ревью дизайн-системы, синхронизироваться с разработкой, дождаться следующего релиза библиотеки. В итоге дизайнеру проще обойти систему, чем изменить её.

Когда система важнее продукта

В ваших встречах и чатах все чаще встречаются такие фразы, как «так нельзя, этого нет в дизайн-системе» или «давайте сначала добавим компонент в систему». Хотя правильный порядок другой: сначала продукт, а уже потом система.

Когда скорость падает

Хорошая дизайн-система ускоряет 80% задач. Но если она начинает усложнять 20% новых сценариев, команда начинает тормозить. Иногда лучший способ развивать дизайн-систему — временно её игнорировать, тем самым развивая продукт.

Что помогает

Простой принцип: дизайн-система — это инструмент скорости, а не источник правил.

Если одна кнопка мешает решать продуктовую задачу — это можно временно обойти. А уже потом понять, как система должна эволюционировать.

Интересно, как у вас? Дизайн-система чаще ускоряет работу или создаёт ограничения?