🧱 Дизайн-система должна хранить решения, а не только компоненты

Автор проверил это на трёх ИИ-агентах. Всем дали одну библиотеку компонентов, токены и задания собрать страницу настроек для разных продуктов. В результате получились три вполне рабочие страницы, но с разной структурой: где-то вкладки, где-то карточки, разные способы сохранения и разные подходы к опасным действиям.

Компоненты задают кнопки, поля и переключатели, но не отвечают на вопросы более высокого уровня. Поэтому команда должна отдельно описывать повторяющиеся решения: как устроена страница настроек, где размещается опасная зона, когда изменения сохраняются и как подтверждается удаление. После этого такие правила можно закрепить в коде и понятных паттернах, чтобы следующий дизайнер или ИИ не решал ту же задачу заново.

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

➡️ Читать статью

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы