🧱 Дизайн-система должна хранить решения, а не только компоненты
Автор проверил это на трёх ИИ-агентах. Всем дали одну библиотеку компонентов, токены и задания собрать страницу настроек для разных продуктов. В результате получились три вполне рабочие страницы, но с разной структурой: где-то вкладки, где-то карточки, разные способы сохранения и разные подходы к опасным действиям.
Компоненты задают кнопки, поля и переключатели, но не отвечают на вопросы более высокого уровня. Поэтому команда должна отдельно описывать повторяющиеся решения: как устроена страница настроек, где размещается опасная зона, когда изменения сохраняются и как подтверждается удаление. После этого такие правила можно закрепить в коде и понятных паттернах, чтобы следующий дизайнер или ИИ не решал ту же задачу заново.
Внутри: – Почему библиотеки компонентов сами по себе не создают единую систему; – Какие решения чаще всего остаются только в головах и старых макетах; – Как разложить страницу настроек на поведение, строки, группы и общий шаблон; – Что меняется, когда правила описаны рядом с компонентами; – Как использовать ИИ-агентов, чтобы находить места, где продукт начинает расходиться.
———
💻 Вакансии в IT и digital 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы
В этом посте были ссылки, но мы их удалили по правилам Сетки
