Как я собрала UI-kit существующего B2B-продукта через Claude Design

01 / КОМПОНЕНТЫ ЕСТЬ, А ГДЕ ИХ ИСКАТЬ?

Полтора года я работала над B2B-платформой для строительной отрасли. За это время продукт заметно вырос: новые сценарии, заказы, отгрузки, финансы, web и mobile. И, естественно, всё это нужно было как-то проектировать.

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

Компоненты вроде есть, а UI-kit вроде нет. Хочешь найти нужный элемент? Иди по макетам и вспоминай, где ты его последний раз видела.

В какой-то момент интерфейсов стало так много, что такой подход перестал казаться особенно удобным. При этом визуальная логика уже сложилась. Не хватало одного — собрать её в понятную, доступную библиотеку.

02 / УВОЛИЛАСЬ, ВЕРНУЛАСЬ, НО НЕ НА РАБОТУ :)

После ухода из продукта мне захотелось поэкспериментировать с Claude Design. И вместо того, чтобы собирать очередной учебный UI-kit в красивой обертке, я решила взять реальный продукт, который уже прекрасно знала.

Почему бы и нет? У меня уже были готовые интерфейсы, повторяющиеся компоненты и понимание того, как всё это работает. Осталось выяснить одну вещь: а что, если отдать существующие макеты AI и попросить его собрать из них дизайн-систему?

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

Заодно хотелось понять, насколько это сложно и можно ли вообще делегировать такую задачу AI. Просто самостоятельный эксперимент из профессионального любопытства.

03 / КЛОД, ВОТ ТЕБЕ МАКЕТЫ, СОБЕРИ ИЗ НИХ СИСТЕМУ.

Я загрузила существующие макеты в Claude Design и попросила собрать на их основе дизайн-систему. Важный момент: исходные интерфейсы уже содержали повторяющиеся решения.

То есть задача была не в том, чтобы AI сгенерировал мне библиотеку кнопок, инпутов и карточек по своему вкусу. Мне нужна была система из того, что действительно использовалось в продукте.

Условно, весь материал можно было разделить на три уровня:

База. Типографика, кнопки и другие повторяющиеся элементы.

Компоненты. Самостоятельные части интерфейса, которые встречались на разных экранах.

Крупные блоки. Готовые интерфейсные решения, переиспользованные в нескольких функциональных сценариях.

Всё это уже было в макетах. Только не лежало аккуратно на отдельной странице с понятной структурой. Именно это я и хотела получить на выходе.

04 / КАЗАЛОСЬ БЫ, ЧТО ТУТ СЛОЖНОГО?

Найти одинаковые элементы. Разложить по группам. Назвать. Готово. Звучит как работа, которую можно спокойно отдать AI. Но есть нюанс: одинаково выглядит ≠ одинаково работает. Особенно в B2B, где за одной кнопкой может стоять целая цепочка бизнес-процессов.

Например, выбор строительного объекта. В одном сценарии он влияет на условия заказа и скидку. В другом помогает работать с отгрузками. В третьем — связывает документы и финансовую информацию с конкретной стройкой.

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

Поэтому для меня было важно не только то, как выглядит результат Claude, но и то, насколько он соответствует логике уже существующего продукта.

05 / НАЙТИ ПОВТОРЕНИЕ — ЕЩЁ НЕ ЗНАЧИТ НАЙТИ ПРАВИЛО.

Вот здесь начинается самая интересная часть систематизации.

Допустим, один и тот же интерфейсный блок встречается в пяти разделах. Это готовый компонент? Возможно. А возможно, в одном разделе у него другое поведение, в другом — дополнительные состояния, а в третьем его вообще не стоило делать таким. И теперь вопрос: что объединять, а что оставить разными решениями?

Потому что UI-kit — это не музей одинаковых кнопок.

Мне было важно смотреть на результат через несколько вопросов:

• Можно ли найти нужный элемент, не отправляясь на раскопки по макетам?
• Понятно ли, где и для чего он используется?
• Какие варианты действительно нужны, а какие только усложняют библиотеку?
• Можно ли переиспользовать компонент в разных сценариях?
• Сохраняется ли логика исходного продукта?

Именно по этим признакам имеет смысл оценивать систему, а не по количеству компонентов на одной странице.

06 / ТАК ЧТО В ИТОГЕ?

В результате эксперимента я собрала UI-kit на основе существующих интерфейсов с помощью Claude Design. То, что раньше было распределено между рабочими макетами, получило отдельную структурированную форму. Из уже готового дизайна — в библиотеку компонентов. Именно это я и хотела проверить.

Мой результат — UI-kit и практический опыт работы с AI на материале настоящего продукта.

07 / ДЛЯ ЧЕГО ВСЁ ЭТО?

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

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

AI можно поручить работу с исходным материалом, но вот оценивать, насколько получившаяся структура имеет смысл для продукта, всё равно нужно отдельно.