Почему ваш дизайн-система — не система

Что произошло

Многие команды сталкиваются с одной и той же проблемой: используя одинаковые компоненты и токены, они создают интерфейсы, которые выглядят несогласованно. Например, страницы настроек в одном продукте могут быть организованы по-разному: одни используют вкладки, другие — карточки, третьи — длинные формы. Это происходит потому, что компонентная библиотека предоставляет только «кирпичики», но не отвечает на важные вопросы: как организовать страницу, как сохранять изменения, где размещать опасные действия.

Детали

Эксперимент с использованием ИИ-агентов показал, что даже при одинаковых условиях они принимают разные решения. Например, три агента получили задачу создать страницу настроек для разных продуктов (управление проектами, трафик и биллинг). Все использовали одну и ту же библиотеку компонентов и токены, но результаты отличались: одни использовали вкладки, другие — карточки, третьи — длинные формы. Это произошло потому, что библиотека не предоставляла чётких правил организации страницы.

Интерфейсный дизайн — это распознавание паттернов: выбор подходящей формы и её применение.

Для решения проблемы нужно фиксировать повторяющиеся решения на уровне архитектуры. Например, как организовывать страницы настроек, как сохранять изменения, как размещать опасные действия. Эти решения должны быть частью дизайн-системы, чтобы команды могли их повторно использовать, а не принимать заново.

Почему это важно

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

Что дальше

Чтобы избежать разногласий, нужно превращать повторяющиеся решения в часть системы. Это можно сделать с помощью чётких правил и шаблонов, которые фиксируют архитектурные решения. Например, как организовывать страницы настроек, как сохранять изменения, как размещать опасные действия. Эти правила должны быть доступны всем участникам команды, чтобы они могли их использовать в своей работе.