Цельный прототип отлично показывает продукт таким, каким его увидит пользователь. Но чем больше в нем страниц и состояний, тем хуже он отвечает на другой вопрос: из каких повторяемых элементов вообще состоит интерфейс? В TRUE VISUAL мы столкнулись с этим, когда начали готовить прототип к передаче в разработку и работе с AI-агентами. Решением стал отдельный каталог компонентов.
Страница показывает композицию, а не устройство системы
На готовой странице кнопка находится внутри формы, форма внутри карточки, карточка внутри секции. Человеку этого достаточно, чтобы оценить результат. Но если нужно изменить саму кнопку, приходится искать все места, где она используется, и сравнивать их между собой.
Каталог компонентов убирает лишний контекст. В нем кнопка существует как отдельная сущность: базовое состояние, hover, disabled, варианты размеров и другие действительно нужные состояния. То же самое можно сделать с табами, карточками, панелями, полями, статусами и навигацией.
Изоляция быстро показывает случайные различия
Пока похожие элементы находятся на разных страницах, небольшие расхождения легко не заметить. Где-то радиус 10 пикселей, где-то 12. В одном табе текст выровнен чуть иначе. Одна кнопка имеет другой внутренний отступ просто потому, что ее создавали позже.
Когда компоненты стоят рядом в каталоге, такие отличия становятся очевидными. Можно решить, где это реальный вариант, а где случайность, которую нужно убрать.
Каталог становится договором между дизайном и разработкой
Разработчик получает не только скриншоты страниц, но и набор сущностей, из которых эти страницы собраны. Это сильно упрощает вопрос компонентности: не нужно самостоятельно решать, являются ли две похожие карточки одной сущностью или разными.
При этом каталог не диктует конкретный технологический стек. Он описывает интерфейсную модель продукта. Команда может реализовать ее любым подходящим способом.
AI-агентам такой формат особенно полезен
Модель гораздо стабильнее работает с небольшим законченно описанным элементом, чем с огромной страницей, где она должна сначала сама выделить компонент. Если нужно изменить поведение таба, агенту можно дать эталон таба и правило, а не просить восстановить систему по всему приложению.
Это уменьшает количество догадок и делает массовые изменения предсказуемее.
Каталог не заменяет реальный прототип
Изолированные компоненты не показывают, как интерфейс работает в композиции. Они не отвечают на вопросы плотности, визуальной иерархии и соседства элементов. Поэтому мы не выбираем между страницами и каталогом.
Цельный прототип отвечает на вопрос "как выглядит и работает продукт", а Component HTML Catalog - "из чего он построен". Только вместе они дают достаточно полную картину.
Для нас Component HTML Catalog стал не отдельной документацией ради документации, а промежуточным слоем между дизайном и разработкой. Он делает скрытую структуру интерфейса явной и позволяет развивать продукт без постоянного восстановления правил по готовым страницам.