Тендеры и лиды
Информация
Это история о создании системы дизайна на основе искусственного интеллекта — фронтенд-платформы, разработанной с использованием Claude Code и Figma, призванной служить единым источником достоверной информации для всего B2B SaaS-приложения Prerender.
Уже довольно давно я преследую одну и ту же цель. Создать что-то в Figma, выложить на фронтенд, итерировать, выложить обратно. Чистый цикл. Никакой потери контекста при переводе. Никаких разговоров типа «в Figma это выглядело по-другому».
В теории все довольно просто, но на практике это превращается в настоящий кошмар.
Главная сложность заключалась в следующем: мне нужен был единый источник достоверной информации для фронтенда. Одно место, где будут храниться цвета, типографика, отступы, компоненты и логика компоновки, и каждый запущенный проект будет использовать эту же основу.
Позвольте мне честно рассказать о том, что не сработало, потому что, на мой взгляд, это экономит людям время.
UXPilot отлично подходит для быстрых презентаций и создания макетов на ранних этапах. Вы можете получить что-то презентабельное за считанные минуты. Но если вы попросите его соответствовать настоящей дизайн-системе, он этого не сделает. Результат попадает в Figma, но обычно далек от задуманного внешнего вида.
Figma Make удерживает меня внутри Figma, что является одновременно и её главным преимуществом, и её главным недостатком. Она всегда генерирует React по умолчанию, независимо от используемого стека технологий. И… всё остаётся внутри мира Figma. Как только вы попытаетесь перенести эти компоненты в реальное пространство, вы останетесь один на один со своими проблемами.
Я еще не до конца изучил Lovable , но со стороны ясно, что экосистема построена таким образом, чтобы удерживать вас внутри. Это не критика, это законная бизнес-модель. Просто она несовместима с наличием портативного, независимого от проекта интерфейса.
Больше всего я надеялся на Builder.io . Я провел несколько тестов. Стандартная лицензия не включает интеграцию с системами проектирования. Для этого нужен корпоративный уровень. Если эта функция так глубоко запрятана в ценовом диапазоне, мне трудно поверить, что она действительно существует. Поэтому я перешел на другой вариант.
Ни один из этих инструментов не подвел меня из-за того, что они плохие. Они подвели меня потому, что моя задача была сложнее, чем «сгенерировать экран, который выглядит вот так». Я уже прошел этот этап.
Мне нужна была инфраструктура. Взять библиотеку компонентов Figma, извлечь из неё дизайн-токены и визуальные шаблоны и превратить это в настоящую фронтенд-систему дизайна, устанавливаемую как зависимость. А затем использовать её в качестве основы для каждого продукта, который мы создаём.
После всех этих тестов я в итоге получил работающую комбинацию: Claude Code + плагин Figma MCP + Figma . Основной цикл: получение контекста дизайна из Figma с помощью get_design_context, создание пользовательского интерфейса в Claude Code, отправка в Git, развертывание.
Отличие этого подхода от всего остального заключается в том, чего он не делает. Он не привязывает вас к какой-либо платформе. Он не скрывает вашу собственную систему дизайна за платным корпоративным доступом. Он работает локально. Результатом является просто код, обычные компоненты TypeScript React, которые полностью принадлежат вам.
Компромисс заключается в том, что вам приходится больше думать. В работе над дизайн-системами именно этим и должно заниматься мышление.
Для системы Prerender Design System рабочий процесс был следующим: сначала сгенерировать DS из библиотеки компонентов Figma, а затем использовать этот DS в качестве основы при создании реальных экранов продукта. Клод не изобретает новые шаблоны (хотя иногда и изобретает, но можно вернуться к исходной библиотеке), он использует то, что уже предоставляет система.
В результате получается продукт, а не набор сгенерированных похожих экранов. Это различие имеет большее значение, чем кажется на первый взгляд.
Инструменты, которые я тестировал, были неплохи; они решали другую проблему. Большинство инструментов для генерации пользовательского интерфейса останавливаются на визуальном преобразовании: результат, который выглядит как дизайн. Мне же нужна была общая основа, от которой могли бы отталкиваться как дизайн, так и фронтенд. Это другое требование, и оно исключает большую часть рынка. Оно также исключает все, что предполагает серьезную привязку к конкретной платформе: самые быстрые инструменты для запуска, как правило, имеют самый высокий потенциал для быстрого выхода, а локальная работа с сохранением результата оправдывает дополнительные затраты на настройку. А когда дело дошло до самой разработки, начало с Ant Design v5 и наложение токенов Prerender оказалось стабильно быстрее и чище, чем просьба к Клоду создать собственную систему с нуля. Существующая основа лучше, чем чистый лист.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13735 тендеров
проведено за восемь лет работы нашего сайта.
После того, как рабочий процесс был налажен, следующим вопросом стало, как структурировать сам процесс сборки. Вы можете просто указать Клоду на файл Figma и сказать: «Собери это». Но вам не понравится то, что получится в итоге.
Сработало то, что мы подошли ко всему как к строительному проекту. Сначала фундамент, затем конструкция, потом отделка. Каждый этап мы называли волной.
Прежде чем писать хоть один компонент, мы извлекли дизайн-токены из библиотеки Figma. Цвета, отступы, типографический масштаб, радиусы границ, тени, контрольные точки. Все они были закодированы в двух файлах: tokens.cssдля пользовательских свойств CSS и antdTheme.tsдля сопоставления этих значений с ConfigProvider из Ant Design. Построение всего на основе Ant Design обеспечило правильную структуру (от простых элементов до сложных визуальных структур).
Это было самое важное решение за весь процесс строительства.
После того, как токены были установлены, каждый компонент получил общий словарь. Когда нужно было изменить цвет, изменение происходило в одном месте и распространялось повсюду. Без этого шага вы получаете сотни жестко закодированных шестнадцатеричных значений, разбросанных по десяткам файлов, и обновление чего-либо превращается в археологию (Клод очень эффективно исправляет подобные вещи, но это пустая трата токенов).
Это также значительно упростило сотрудничество с Клодом. Вместо того чтобы описывать цвета по значению в каждом задании, мы могли просто сказать «используйте основной токен», и Клод сразу же выбирал нужный вариант.
Мы разделили процесс сборки на восемь этапов:
Этап 1 — оболочка приложения (AppLayout, AppHeader, AppSider) + примитивы (Button, Badge, Tag, Spin, Progress, Statistic, Empty)
Этап 2 — Формы (Ввод, Выбор, Переключатель, Флажок, Переключатель, Загрузка, Форма)
Этап 3 — Навигация (хлебные крошки, выпадающее меню, пагинация, шаги, вкладки)
Этап 4 — Обратная связь (предупреждение, модальное окно, всплывающая подсказка, всплывающее подтверждение, сообщение, уведомление)
Этап 5 — Карточки для отображения данных (StatCard, ChartCard, CustomCard)
Этап 6 — Стол с адаптивным мобильным вариантом
Этап 7 — Диаграммы (линейные, столбчатые, столбчатые с накоплением, круговые/кольцевые — все на основе Chart.js )
Этап 8 — Расширенные компоненты (DatePicker, Slider, Skeleton, Result, Drawer)
Для каждого этапа был заранее составлен письменный план: какие компоненты нужно создать, какие свойства им понадобятся, к каким узлам Figma они будут привязаны. Я поделился этим планом с Клодом и попросил его написать свою собственную версию перед началом работы. Этот дополнительный шаг важнее, чем кажется.
Вот чего вам никто не расскажет о работе с Клодом над проектом такого масштаба: контекст может нарушиться. Сессия заканчивается. Вы возвращаетесь на следующий день. Клод не помнит, на чем вы остановились.
Без проектной документации вам каждый раз придётся начинать с нуля.
Мы использовали один файл Markdown: план этапа разработки (wave plan), который отслеживал полное состояние сборки. На каждом этапе были перечислены компоненты с четким статусом: pending, in progress, или done. Для каждого компонента был указан узел Figma, из которого он был создан. Все решения, принятые в середине этапа, обнаруженные проблемы, незавершенная работа — все отмечалось в одном месте.
Вход волны в атмосферу выглядел примерно так:
# # Этап 5 - Карты отображения данных [СТАТУС: в процессе]- [x] StatCard - узел Figma 1045:2310 - выполнено
- [x] ChartCard - узел Figma 1604:735 - выполнено
- [ ] CustomCard - узел Figma 1045:3190 - в ожидании### Примечания
- StatCard: индикатор выполнения использует strokeColor #2da01d, trailColor rgba(0,0,0,0.06)
- ChartCard: три варианта - default, sub-metric, additional-numbersКогда я возобновлял работу после перерыва, первым делом я указывал Клоду на этот файл: «Прочитай план волн, найди первый незавершенный пункт и продолжай с этого момента». Клод сориентировался, подхватил нить рассуждений и продолжил работу.
Эта единственная привычка: постоянное обновление документа с планом и его использование в качестве передачи информации перед началом сессии, — придала всему процессу целостность. Без нее каждая сессия представляла бы собой повторное объяснение контекста, который Клод уже усвоил накануне.
Когда Клоду сразу поручают большую задачу, качество падает. Не из-за каких-либо эмоциональных переживаний (я думал, он просто нервничает из-за огромного объема работы), а из-за нехватки ресурсов. Клод распределяет внимание по всему объему задачи, и чем больше объем, тем меньше внимания уделяется каждому отдельному компоненту. Начинается приблизительный подход. Неопределенность превращается в разрешение гадать. А этого не нужно в идеально проработанной дизайн-системе.
Привычка сначала планировать занимает пять минут, но регулярно экономит часы. Она создает момент согласованности еще до написания кода. Что еще важнее, именно в этот момент выявляются недоразумения, прежде чем они будут заложены в двенадцать компонентов.
Практически любой дизайн в Figma, превышающий примерно 1000 пикселей, слишком велик для корректного восприятия (иногда даже 500 пикселей). Клод делает скриншот, работает с изображением, полученным в результате, и от этого страдает результат.
get_design_contextЭто почти всегда лучший выбор. Он возвращает структурированные данные: названия компонентов, состояния вариантов, свойства макета, а не пиксельное отображение. Но он хорошо работает только тогда, когда вы указываете на конкретный узел, а не на всю страницу.
Оказалось, что работает следующий подход: определить отдельные разделы экрана (заголовок, карточки с метриками, таблица, нижний колонтитул), указать Клоду на каждый узел по отдельности, создавать компонент за компонентом (иногда я размещал фреймы за пределами исходного родительского фрейма, чтобы Клод мог сосредоточиться на этом, не отвлекаясь на лишние элементы родительского узла). Настройка занимает больше времени, но результат неизменно точнее, и ошибки легче исправить.
Что касается иконок и визуальных элементов, скриншоты иногда оказывались полезными для сравнения. Но всегда в качестве дополнения, никогда не в качестве основного источника.
Всегда просите Клода загружать ресурсы локально. В противном случае он будет напрямую ссылаться на URL-адреса CDN Figma в коде. Срок действия этих URL-адресов истекает через семь дней. Вы этого не заметите, пока не будете создавать демонстрацию и половина изображений не станет пустой.
То же самое относится ко всем внешним ресурсам: логотипам, иллюстрациям, файлам иконок. Если это важно для проекта, то это находится в репозитории.
Мелкие несоответствия: цвет, который должен ссылаться на токен, но не ссылается, значение отступа, немного выходящее за рамки масштаба, — оставьте всё как есть; они копируются в следующий компонент. К пятой волне вы уже пытаетесь исправить одну и ту же ошибку в десятке файлов.
Вносить исправления немедленно эффективнее, чем кажется. Клод замечает ошибку и применяет её в дальнейшем. Если же откладывать это на потом, исправление превратится в рефакторинг.
Я не планировал проводить отдельный аудит по WCAG 2.2 AA . Мы провели его как отдельную проверку после основной сборки, и он выявил удивительно много проблем.
Нарушения цветового контраста во вторичном тексте. Разница между rgba(0,0,0,0.45)и rgba(0,0,0,0.62)кажется тривиальной, но это разница между провалом и прохождением теста AA. Отсутствие колец фокусировки на некоторых кнопках. Холсты диаграмм без доступного описания. Сенсорные цели меньше минимального размера в 24 пикселя (Как я это пропустил?).
Проведение аудита в виде запланированной волны с документом, отслеживающим каждое исправление, дало гораздо более чистые результаты, чем попытка внедрить доступность в каждый компонент по отдельности. Клод мог сосредоточиться на одном классе проблем за раз, что позволяло вносить исправления в рамках заданной темы.
Делайте это как минимум дважды за проект, а не только один раз в конце.
Существует версия этого поста, где я утверждаю, что Клод Код решил все проблемы, и конвейеры проектирования и разработки кода — это уже свершившийся факт. Эта версия была бы короче, её было бы приятнее опубликовать, но она не совсем честная.
Реальная версия гораздо интереснее.
После совместной разработки системы предварительного рендеринга: токенов, компонентов, аудита доступности, адаптивного поведения, библиотеки диаграмм, всего комплекса мер, у меня сформировалось совершенно иное представление о том, что такое сотрудничество с использованием ИИ. И чего оно от вас требует.
Вот что я на самом деле узнал.
Если вы что-то не укажете, этого не произойдёт. Мне потребовалось несколько попыток, чтобы это как следует осознать.
Вначале я забыл упомянуть адаптивность. Компоненты были созданы, отлично выглядели на разрешении 1440 пикселей, и Клод не выдал никаких ошибок. Он просто создал то, что я описал. Когда я наконец спросил о поведении на мобильных устройствах, он справился хорошо, но некоторые компоненты нуждались в доработке.
Урок не в том, что Клод небрежен. А в том, что он не дизайнер. Дизайнер заметил бы пробел и указал на него. Клод же выполнил задание. Вывод: ваше техническое задание должно быть более полным, чем кажется необходимым, особенно в тех моментах, которые кажутся вам очевидными.
Та же логика применима и к непрерывности сессий. У Клода нет памяти между сессиями. Если вы не предоставите ему что-нибудь для ознакомления в начале: документ с планом волн, файл состояния, сводку текущего положения дел, он начнет работу с нуля. А «начинать с нуля» в течение нескольких дней сборки обходится дорого. План волн, который мы сохраняли, был не просто инструментом управления проектом. Он был средством передачи сессии. Первое сообщение каждой возобновленной сессии всегда было: «Прочитайте план, найдите первый незавершенный пункт, продолжайте с этого момента». Все остальное вытекало из этого.
Если переменная находится глубоко внутри вариантов состояния компонента Figma, или цветовой токен вложен на три уровня в дерево компонентов, существует реальная вероятность, что Claude её не распознает (и это очень раздражает).
Стоит уточнить: дело не в невнимательности. Дело в доступе к информации.
Клод тщательно работает с тем, что находится в контексте. Если get_design_contextкакая-либо деталь не проявляется, потому что она находится внутри варианта, на который не было ссылки, или в подкомпоненте, на который не было конкретно указано, то с точки зрения Клода она просто не существует.
Практическое применение этого подхода имеет два направления. Во-первых, структурируйте компоненты Figma так, чтобы важные для вас детали были видны на том уровне, на который вы указываете Клоду, а не были скрыты внутри фрейма уровня 6848393939. Во-вторых, проверяйте вывод в любом случае. Жестко закодированные шестнадцатеричные значения там, где должны быть ссылки на токены, значения интервалов, которые близки, но не совсем соответствуют масштабу. Они проскальзывают, и стоит выявлять их по одной. Повторяйте проверки, не предполагайте, что Клод помнит все ваши команды.
Когда Клоду поручают слишком масштабную или слишком расплывчатую задачу, что-то меняется в результате. Появляются предположения, которые не отмечаются. Завершение работы становится приоритетом над качеством.
Метод Клода распределяет внимание по всему объему задачи. Чем шире объем задачи, тем меньше внимания уделяется каждому отдельному компоненту. Сфокусированная, ограниченная задача обрабатывается концентрированно.
Решение заключается в том, чтобы разбивать задачи на более мелкие части, чем это кажется необходимым. Не «создать страницу панели мониторинга», а «создать строку с метриками, используя эти три экземпляра StatCard с этими конкретными свойствами». Чем более ограничена задача, тем более продуманным будет результат.
Пожалуй, это было самое значимое изменение в моих привычках за весь проект.
Ближе к концу проекта я начал тестировать то, что, как мне кажется, имеет реальный потенциал: запуск нескольких агентов параллельно. Например: один в качестве разработчика, а другой в качестве UX-аудитора, единственная задача которого — проверять работу разработчика и указывать на несоответствия дизайну или нарушения принципов проектирования.
Перед началом строительства обе стороны согласовывают план, подход и уровень уверенности. Затем аудитор проверяет результаты. После этого строитель приступает к работе.
Обратная связь гораздо надежнее, чем самокритика со стороны одного агента. Роль аудитора выявляет то, что обычно пропускает этап сборки: несоответствия в визуальной иерархии, отсутствие состояний при наведении курсора, компоненты, которые технически работают, но ощущаются неправильно.
Я еще не полностью внедрил этот подход на практике, но он достаточно многообещающий, чтобы о нем упомянуть.
Меня по-настоящему удивило одно обстоятельство: просьба к Клоду постепенно заполнять условные данные многое говорит о том, понимает ли он на самом деле бизнес-логику или только визуальный слой.
В начале одного из проектов на панели мониторинга были условные числа. Я попросил Клода дополнить эти условные данные, чтобы они отражали реальную учетную запись клиента. В результате получилась правдоподобная структура, но поверхностная по деталям.
Каждый последующий запрос на обогащение данных давал более качественные результаты, поскольку Клод накапливал больше контекста о значении чисел и их взаимосвязи. К третьему или четвертому проходу фиктивные данные уже рассказывали связную историю, а не просто заполняли ячейки. В этот момент становится ясно, что Клод понимает продукт, а не просто пользовательский интерфейс.
Один из приемов, который работает на удивление хорошо: внесение изменений в систему проектирования и просьба к Клоду применить их к зависимым проектам.
Когда я обновлял цветовые токены, добавлял новые пользовательские свойства CSS или корректировал оформление компонентов, Клод мог отслеживать цепочку зависимостей и применять изменения чисто и согласованно. Архитектура токенов сделала это возможным, но возможность отслеживать эту цепочку за пределами проекта и применять изменения в нужных местах была впечатляющей.
Обычно при работе с системами проектирования опасаются, что они превратятся в устаревший артефакт сразу после выпуска. С Claude в качестве уровня распространения эта опасность значительно снижается.
Чем лучше вы разбираетесь в своей области, тем лучше будут ваши вопросы. Я знаю, это звучит очевидно. Разница в уровне подготовки действительно существует.
Это наводит меня на мысль, что в частности, при работе над дизайн-системами наилучшие результаты достигаются при совместной работе UX-дизайнера и фронтенд-разработчика с самого начала. UX-дизайнер, понимающий лучшие практики дизайна и архитектуру компонентов, в паре с фронтенд-разработчиком, — такое сочетание позволяет извлечь из инструментария гораздо больше пользы, чем работа каждого из них по отдельности.
Искусственный интеллект не снижает ценность экспертных знаний, а, наоборот, усиливает её. Прочный фундамент обеспечивает лучшие результаты. Неустойчивый же порождает всё больший хаос.
Claude Code — это самый полезный инструмент, который я нашел для преодоления разрыва между проектированием и кодом на архитектурном уровне. Не потому, что это волшебство, а потому, что он работает локально, не навязывает какой-либо фреймворк или платформу и хорошо выполняет четко определенный план.
Однако загвоздка в том, что слово «четко определенный» выполняет в этом предложении очень важную функцию.
Качество результата напрямую зависит от качества исходных данных. Человеческий фактор в этом сотрудничестве никуда не денется. Он становится всё интереснее.
Общий принцип здесь — краткое качество: указывайте, что важно, ограничивайте задачи и используйте свои знания в предметной области при формулировании подсказок. Звучит просто. На практике это означает, что нужно продумать всё заранее, что кажется неестественным, когда у вас есть готовый инструмент. Структурируйте компоненты Figma так, чтобы важные для вас детали отображались на том уровне, на который вы указываете Клоду, а затем проверяйте результат независимо от этого. Используйте обогащение фиктивных данных в качестве диагностического инструмента: оно покажет, усвоил ли Клод бизнес-логику или только визуальный слой. И если вы ещё не пробовали двухъагентную модель на чём-то сложном, стоит её настроить: обратная связь между разработчиком и аудитором более тесная, чем самокритика с помощью одного агента. Всё это происходило не быстро. Потребовалось больше итераций, чем я ожидал, прежде чем система и проекты достигли желаемого результата.
Если вы работаете в цифровом агентстве , вам нужно быстро создать единообразный пользовательский интерфейс , но у вас нет доступа к фирменным рекомендациям . Как упростить себе жизнь?
Claude Code может вам помочь, и для создания целостного прототипа не потребуется Figma.
