Привет! Меня зовут Богдан Алексеев – я дизайн-менеджер в ВТБ. Мы построили и развиваем омниканальную экосистему для бизнеса, в которой сотрудники по всей России обслуживают более 1 млн клиентов.
Вчера мы презентовали вице-президенту результаты работы над новой стратегией. Он ожидал увидеть прототипы для оценки UX-решений на макетах в Figma. Мы показали 4 полностью рабочих react-приложения с реальным скроллом, интерактивными элементами и переходами.
Раньше такие задачи занимали 1–1,5 недели на одно приложение. Мы сделали 4 за 2 дня. 2 дня, КАРЛ! Реакция на такой показ и на выгоды в будущем была соответствующая.
Проблема: почему концептуальные прототипы съедают время и бюджет
Классический процесс выглядит так: дизайнер и бизнес-аналитик делают исследование проблемы, после чего дизайнер проектирует концептуальное решение.
Любой руководитель хочет видеть финальную картину. Но на этапе концепта все с пониманием принимают не финально проработанный вариант – "рисунок ключа". Это нормально, потому что тратить время на мелочи не имеет смысла – в процессе может всё поменяться.
Дальше начинается итерационная работа: на основании исследований и обратной связи получается предфинальный прототип, который дорабатывается до ready-to-production состояния.
Здесь возникают две критические проблемы.
Проблема №1: Концепт требует много итераций

Мы как в игре открываем тёмную неизведанную область постепенно. На это нужно потратить много времени. Но результат нужен уже сейчас. А когда результат нужен быстро, приходится выбирать между скоростью и качеством проработки.
Проблема №2: Разность вёрстки между дизайнерами и разработчиками

Дизайнеры в макетах верстают не так, как разработчики. Похоже, но не так.
Пример: на макете дизайнер создал фрейм, внутри сделал автолейаут с паддингом и гэпом, где разместил все основные блоки. На реализации мы видим другую картину – все блоки независимы друг от друга, и всё строится на внутренних паддингах и гэпах у блоков.
Из-за этой разности часто возникают визуальные дефекты, за которыми нужно отдельно следить и внедрять ревью в процесс. Это всё время, деньги, система управления.
Час фронта по рынку – примерно 2000–2500 рублей. Мы научились делать это за 2300 рублей в неделю руками дизайнера.
Решение: дизайнер контролирует весь цикл
Мы кардинально меняем процесс создания дизайна. Теперь вёрстка и UI полностью переходят на уровень дизайнера, который сам контролирует качество и исправляет визуальные дефекты.
После того как всё идеально, он передаёт фронту код, который и визуально, и технически видит, как нужно сделать. При этом фронт видит это не на макете, а в 100% нативной среде пользователя – в браузере + Cursor/VS Code
Как мы это сделали: три способа
Способ 1: Claude + Figma API / Claude MCP + Figma

Мы использовали модель Claude Opus 4.5.
Вариант A: Figma Personal Access Token Генерируем в Figma Personal Access Token и даём доступ Claude. Таким образом он подключается к Figma API и на бэкенде читает фреймы и их стили.
Для настройки:
Зайдите в Figma → Settings → Personal Access Tokens
Создайте новый токен с правами на чтение файлов
Скопируйте токен и добавьте в настройки Claude через интеграцию с Figma
Укажите ID нужного файла в промпте
Вариант B: Claude MCP + FigmaClaude без прямой интеграции забирает с фронта информацию и даже может работать в браузере за вас по промпту через MCP (Model Context Protocol).
Для настройки:
Установите Claude Desktop или используйте веб-версию с поддержкой MCP
Подключите Figma через MCP-сервер
Авторизуйтесь через OAuth
Claude получает доступ к просмотру и анализу макетов в реальном времени
Минус обоих способов: на это тратится много токенов и ресурсов. Инфраструктура Figma не очень готова к таким объёмам запросов и часто выдаёт ошибки лимитов. Несмотря на точность передачи контекста, объём задач и макетов слишком большой, и инфраструктура пока на это не рассчитана.
Способ 2: Figma + Figma Make

Хороший вариант – не надо вообще заморачиваться с настройкой сервера. Но быстро упираетесь в лимиты, и он не очень подходит для итерационной работы.
Если нужно сгенерировать 1 экран – отлично. Если нужно сделать полноценное приложение целиком, выходит дорого и неудобно.
Способ 3: Cursor + UI-kit на GitHub + скриншот
У нас работает идеально.
Вот как это работает:
Создаём локальную папку
Открываем её через Cursor
Описываем задачу и настраиваем окружение
Кидаем ссылку на GitHub с UI-китом и просим установить библиотеку
Скриним макет и отправляем в Cursor
Описываем поведение элементов и что тянуть из библиотеки
Получаем на 90% точный результат
10% делаем отладку вёрстки или логики
Так выходит дешевле в разы относительно первого варианта.
Примерно за неделю мы упёрлись в лимиты подписки стоимостью 2300 рублей. Это цена одного часа работы фронтенд-разработчика.
Критически важно: качество промпта
Формула эффективного мастер-промпта:
Проблема → Контекст → Действия → Ожидаемый результат → Примеры → Ограничения
Объём первого промпта должен быть сопоставим с листом А4.
Два правила написания промптов
Правило 1: Разбивайте всё на отдельные задачи
Не пытайтесь сразу описать сложную логику и ожидать решения. Всё как в жизни – ставим одну выполнимую задачу и описываем её через результат.
Правило 2: Для решения проблем отправляйте контекст
Отправляйте логи, коды ошибок и, самое главное, сами прогуглите ошибку. Например, мы нашли ответ поддержки про ошибку лимитов Figma API на их форуме. Часто в официальных технических доках тоже всё описано. Кидаем ссылку на эти доки и ответы при формировании задачи.
Как научить дизайнеров настраивать окружение
Базово разберитесь сами (можно вместе с GPT) и научите команду работе с:
Терминал: команды cd, npm install, git remote, docker run
Я объяснял так: представь, что это твоя macOS, только без всей оболочки и дизайна. Всё взаимодействие с ней происходит с помощью команд.
Docker – помогает из твоего компа сделать сервер и ловить коды ошибок фронта и бэка.
GitHub – Figma для разработчиков, где вы храните код и работаете совместно над ним с контролем версий.
Node.js – просто установите по инструкции с официального сайта.
Это один день обучения, который окупается с первого проекта.
Результаты
×5 ускорение прототипирования
100% точность UX/UI на выходе
Дизайнер контролирует весь цикл создания интерфейса
Разработчик получает production-ready код
Что дальше?
Мы продолжаем развивать этот подход. Следующий шаг – интеграция с нашей дизайн-системой и автоматизация тестирования компонентов прямо на этапе прототипирования.
Если вы дизайнер или дизайн-менеджер и сталкиваетесь с похожими проблемами – начните с малого. Выберите один небольшой проект, попробуйте любой из описанных способов и посмотрите на результат.
Я веду Telegram-канал Design Fintech, где буду делиться:
Готовыми промптами для генерации интерфейсов
Реальными кейсами настройки окружения для дизайнеров
Лайфхаками работы с Claude, Cursor и Figma API
Ошибками, с которыми мы столкнулись, и как их решили
Подписывайтесь, если хотите внедрить AI в свой процесс и не потратить месяц на то, что мы уже прошли.
Напишите в комментариях, с какими сложностями вы сталкиваетесь при передаче макетов в разработку. Я с удовольствием отвечу на вопросы и поделюсь деталями настройки.
Помните: если ничего не изменится, процесс передачи дизайна в разработку продолжит быть хаотичным, команда будет тратить время на исправление визуальных дефектов, а качество конечного продукта будет страдать.
Но если вы начнёте уже сейчас, через неделю команда начнёт работать слаженнее, руководители увидят реальную ценность ваших решений, и задачи будут закрываться в разы быстрее.
Комментарии (37)

udinhtml
02.02.2026 07:50Кидаем ссылку на GitHub с UI-китом и просим установить библиотеку
Всего-то нужен ui-кит на гитхабе, делов-то

sovaz1997
02.02.2026 07:50Зачем смешивать слой дизайна и слой разбиения проекта на компоненты?
Выгоду как посчитали, вы точно уверены что это ускорение? А то может оказаться, что это быстрый старт сейчас с замедлением потом. Но ему интересно замедление потом, действительно...

Igorgmail
02.02.2026 07:50Что я только что прочитал )) а главное зачем. Богдан, мне кажется ты топишь себя ещё дальше ))) Не, если цель что б тебя "выгнали" с хабра, то все Ок, ты на верном пути ))

adminNiochen
02.02.2026 07:50Дизайнер пишет реакт код с помощью нейронки и отдаёт его разрабу - Пейн, я тега Панорама не чувствую! А его тут и нет!

lear
02.02.2026 07:50Я дважды встречал дизайнеров, которые допом вёрстку делали =)
Первый раз лет 8 назад, там html + css допом отдали, второй раз около 5 лет назад отдали вместе с вёрсткой на реакте в сторибуке.
Да, это не было полностью прод реди, во втором случае не было страниц, но всё равно было приятно)
PS. Вообще это должно было быть ответом на коммент, но из-за мисклика и неудобного интерфейса мобильного хабра отправилось отдельно.

vs39
02.02.2026 07:50Вопрос, как в периметре втб разрешили использование не селф-хостед ии? С безопасностью не очень, да?

redigen
02.02.2026 07:50Понятно, какую проблему вы пытаетесь решить и, на мой взгляд, выбрали не самое удачное решение. К сожалению, LLM, какой бы умной она ни была, не обеспечивает стабильных результатов, особенно при последующих изменениях дизайна.
Открою вам небольшой секрет: дизайн в Figma описан в понятном JSON-формате. Можно выгрузить документ по API или, даже удобнее, через самописный плагин. Этот JSON уже содержит всю необходимую информацию о токенах, автолейаутах и так далее. Остается только пара недель frontend‑разработчика, который напишет парсер этого JSON в HTML/CSS или сразу React/Vue/Svelte компоненты.
Можно пойти ещё дальше и обогащать JSON данные frontend‑логикой через тот же плагин прямо в дизайне: когда и какую кнопку показывать, запросы к бэку, обработку ответа.
И тогда вам не то что не придется писать промты для LLM, не придется даже ждать от неё ответа, приложение соберется за пару секунд.
Я это могу утверждать по собственному опыту, у меня сейчас так собирается весь фронт.
ncix
02.02.2026 07:50Таких готовых плагинов для фигмы - множество. Однажды перепробовал несколько самых популярных, но все они генерят очень очень плохой html+css.

redigen
02.02.2026 07:50Вы слишком обобщаете. Было время, когда низкокачественные плагины генерации HTML/CSS появлялись пачками, и это было ещё до Dev Mod в Figma. Ситуация давно изменилась, посмотрите хотя бы AutoHTML.
В парсинге JSON Figma нет ничего сверхъестественного, пример:... "strokeWeight": 1, "strokeAlign": "INSIDE", "styles": { "stroke": "2960:51461" }, "cornerRadius": 6, ... "layoutMode": "VERTICAL", "counterAxisSizingMode": "FIXED", "itemSpacing": 4, "layoutWrap": "NO_WRAP", "layoutAlign": "STRETCH", "layoutGrow": 0, "layoutSizingHorizontal": "FILL", "layoutSizingVertical": "HUG", ...
Этот фрагмент JSON легко интерпретировать в CSS обычной логикой. Для этого не нужна LLM, которая ломается при чуть более сложном дизайне с каким-нибудь наложением слоёв.
И я пишу не о очередном плагине-генераторе HTML/CSS, а о инструменте, который может собрать прототип или приложение из дизайна. Можете посмотреть демонстрацию из моего предыдущего комментария выше

Savek
02.02.2026 07:50Большая беда, что часть внутренней кухни механизма взаимодействия между фронтом и бэком ушла на сторону. Вроде и мелочь, а вот из таких мелочей будет строится стратегия атаки на систему. Лучше было обезличить организацию.

wanamen
02.02.2026 07:50Что-то не понял. В итоге ИИ делает верстку по скриншоту? Неужели это помогает решить "проблему №2" из статьи, что разработчики верстают ни как дизайнеры? Типа ИИ по скриншоту верстает как надо, а фронтенд разработчик по фигме нет?

pravosleva
Не завидую тем фронтам, кто будет поддерживать код, структура которого задана нейронкой (ох, я бы ей не доверял строить базовый код )), когда придется вносить правки. Дизайнер будет разводить руками, мол, "зато мы сэкономили на тебе две недели"
elina_komarova
Как раз-таки нейронки хороши при написании базового кода, на старте проекта, но они пока ещё забывают контекст, так что их проблемы начинаются при масштабировании старых проектов, особенно, если в проекте используется устаревший или специфический стек, хотя как по мне сейчас это практически равносильно
kovdmm
Нейронки хороши в базовом коде, когда его потом не нужно поддерживать и не нужно, чтобы его человек читал. POC, стартап-проекты, MVP. На этапах почти любого проекта, когда код в осноном пишут, а не читают – да, нейронки экономят время. А дальше эта экономия времени выливается в то, что никто кроме нейронки (что тоже сомнительно, потому что у неё нет долгосрочной памяти) кодом не владеет. На долгоживущих проектах время можно экономить только на дописывании тестов к коду и для каких-нибудь супер тривиальных задач, для которых код писать на 15 минут дольше, чем нагенерить.
pravosleva
А что значит "устаревший"? У нейронки нет такого понятия - она просто генерит код с массой контекстов по принципу "просто чтобы работало" (про масштабируемость речь не идёт вовсе). Я думаю, проблемы будут у всех кодеров, которые начнут поддерживать проект после нее (как после джуна в этом случае)