Привет! Меня зовут Богдан Алексеев – я дизайн-менеджер в ВТБ. Мы построили и развиваем омниканальную экосистему для бизнеса, в которой сотрудники по всей России обслуживают более 1 млн клиентов.

Вчера мы презентовали вице-президенту результаты работы над новой стратегией. Он ожидал увидеть прототипы для оценки UX-решений на макетах в Figma. Мы показали 4 полностью рабочих react-приложения с реальным скроллом, интерактивными элементами и переходами. 

Раньше такие задачи занимали 1–1,5 недели на одно приложение. Мы сделали 4 за 2 дня. 2 дня, КАРЛ! Реакция на такой показ и на выгоды в будущем была соответствующая.

Проблема: почему концептуальные прототипы съедают время и бюджет

Классический процесс выглядит так: дизайнер и бизнес-аналитик делают исследование проблемы, после чего дизайнер проектирует концептуальное решение.

Любой руководитель хочет видеть финальную картину. Но на этапе концепта все с пониманием принимают не финально проработанный вариант – "рисунок ключа". Это нормально, потому что тратить время на мелочи не имеет смысла – в процессе может всё поменяться.

Дальше начинается итерационная работа: на основании исследований и обратной связи получается предфинальный прототип, который дорабатывается до ready-to-production состояния.

Здесь возникают две критические проблемы.

Проблема №1: Концепт требует много итераций

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

Проблема №2: Разность вёрстки между дизайнерами и разработчиками

Сравнение padding и gap на макетах и в коде
Сравнение padding и gap на макетах и в коде

Дизайнеры в макетах верстают не так, как разработчики. Похоже, но не так.

Пример: на макете дизайнер создал фрейм, внутри сделал автолейаут с паддингом и гэпом, где разместил все основные блоки. На реализации мы видим другую картину – все блоки независимы друг от друга, и всё строится на внутренних паддингах и гэпах у блоков.

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

Час фронта по рынку – примерно 2000–2500 рублей. Мы научились делать это за 2300 рублей в неделю руками дизайнера.

Решение: дизайнер контролирует весь цикл

Мы кардинально меняем процесс создания дизайна. Теперь вёрстка и UI полностью переходят на уровень дизайнера, который сам контролирует качество и исправляет визуальные дефекты.

После того как всё идеально, он передаёт фронту код, который и визуально, и технически видит, как нужно сделать. При этом фронт видит это не на макете, а в 100% нативной среде пользователя – в браузере + Cursor/VS Code

Как мы это сделали: три способа

Способ 1: Claude + Figma API / Claude MCP + Figma

Работа в Figma с подключенным MCP Claude в браузере Chrome
Работа в Figma с подключенным MCP Claude в браузере Chrome

Мы использовали модель Claude Opus 4.5.

Вариант A: Figma Personal Access Token Генерируем в Figma Personal Access Token и даём доступ Claude. Таким образом он подключается к Figma API и на бэкенде читает фреймы и их стили.

Для настройки:

  1. Зайдите в Figma → Settings → Personal Access Tokens

  2. Создайте новый токен с правами на чтение файлов

  3. Скопируйте токен и добавьте в настройки Claude через интеграцию с Figma

  4. Укажите ID нужного файла в промпте

Вариант B: Claude MCP + FigmaClaude без прямой интеграции забирает с фронта информацию и даже может работать в браузере за вас по промпту через MCP (Model Context Protocol).

Для настройки:

  1. Установите Claude Desktop или используйте веб-версию с поддержкой MCP

  2. Подключите Figma через MCP-сервер

  3. Авторизуйтесь через OAuth

  4. Claude получает доступ к просмотру и анализу макетов в реальном времени

Минус обоих способов: на это тратится много токенов и ресурсов. Инфраструктура Figma не очень готова к таким объёмам запросов и часто выдаёт ошибки лимитов. Несмотря на точность передачи контекста, объём задач и макетов слишком большой, и инфраструктура пока на это не рассчитана.

Способ 2: Figma + Figma Make

Сравнение макета и кода, который сделал Figma Make
Сравнение макета и кода, который сделал Figma Make

Хороший вариант – не надо вообще заморачиваться с настройкой сервера. Но быстро упираетесь в лимиты, и он не очень подходит для итерационной работы.

Если нужно сгенерировать 1 экран – отлично. Если нужно сделать полноценное приложение целиком, выходит дорого и неудобно.

Способ 3: Cursor + UI-kit на GitHub + скриншот

У нас работает идеально.

Вот как это работает:

  1. Создаём локальную папку

  2. Открываем её через Cursor

  3. Описываем задачу и настраиваем окружение

  4. Кидаем ссылку на GitHub с UI-китом и просим установить библиотеку

  5. Скриним макет и отправляем в Cursor

  6. Описываем поведение элементов и что тянуть из библиотеки

  7. Получаем на 90% точный результат

  8. 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)


  1. pravosleva
    02.02.2026 07:50

    Не завидую тем фронтам, кто будет поддерживать код, структура которого задана нейронкой (ох, я бы ей не доверял строить базовый код )), когда придется вносить правки. Дизайнер будет разводить руками, мол, "зато мы сэкономили на тебе две недели"


    1. elina_komarova
      02.02.2026 07:50

      Как раз-таки нейронки хороши при написании базового кода, на старте проекта, но они пока ещё забывают контекст, так что их проблемы начинаются при масштабировании старых проектов, особенно, если в проекте используется устаревший или специфический стек, хотя как по мне сейчас это практически равносильно


      1. kovdmm
        02.02.2026 07:50

        Нейронки хороши в базовом коде, когда его потом не нужно поддерживать и не нужно, чтобы его человек читал. POC, стартап-проекты, MVP. На этапах почти любого проекта, когда код в осноном пишут, а не читают – да, нейронки экономят время. А дальше эта экономия времени выливается в то, что никто кроме нейронки (что тоже сомнительно, потому что у неё нет долгосрочной памяти) кодом не владеет. На долгоживущих проектах время можно экономить только на дописывании тестов к коду и для каких-нибудь супер тривиальных задач, для которых код писать на 15 минут дольше, чем нагенерить.


      1. pravosleva
        02.02.2026 07:50

        А что значит "устаревший"? У нейронки нет такого понятия - она просто генерит код с массой контекстов по принципу "просто чтобы работало" (про масштабируемость речь не идёт вовсе). Я думаю, проблемы будут у всех кодеров, которые начнут поддерживать проект после нее (как после джуна в этом случае)


  1. xSVPx
    02.02.2026 07:50

    Пора валить из ВТБ что-ли?


  1. udinhtml
    02.02.2026 07:50

    Кидаем ссылку на GitHub с UI-китом и просим установить библиотеку

    Всего-то нужен ui-кит на гитхабе, делов-то


  1. sovaz1997
    02.02.2026 07:50

    Зачем смешивать слой дизайна и слой разбиения проекта на компоненты?

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


  1. Igorgmail
    02.02.2026 07:50

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


  1. ammadis
    02.02.2026 07:50

    А этот production-ready код с нами в одной комнате?


    1. vorant
      02.02.2026 07:50

      Главное, чтобы было как в том посте о внедрении ии в крупной компании - «График идет вправо и вверх»))


  1. adminNiochen
    02.02.2026 07:50

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


  1. lear
    02.02.2026 07:50

    Я дважды встречал дизайнеров, которые допом вёрстку делали =)

    Первый раз лет 8 назад, там html + css допом отдали, второй раз около 5 лет назад отдали вместе с вёрсткой на реакте в сторибуке.

    Да, это не было полностью прод реди, во втором случае не было страниц, но всё равно было приятно)

    PS. Вообще это должно было быть ответом на коммент, но из-за мисклика и неудобного интерфейса мобильного хабра отправилось отдельно.


  1. vs39
    02.02.2026 07:50

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


  1. redigen
    02.02.2026 07:50

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

    Открою вам небольшой секрет: дизайн в Figma описан в понятном JSON-формате. Можно выгрузить документ по API или, даже удобнее, через самописный плагин. Этот JSON уже содержит всю необходимую информацию о токенах, автолейаутах и так далее. Остается только пара недель frontend‑разработчика, который напишет парсер этого JSON в HTML/CSS или сразу React/Vue/Svelte компоненты.

    Можно пойти ещё дальше и обогащать JSON данные frontend‑логикой через тот же плагин прямо в дизайне: когда и какую кнопку показывать, запросы к бэку, обработку ответа.
    И тогда вам не то что не придется писать промты для LLM, не придется даже ждать от неё ответа, приложение соберется за пару секунд.

    Я это могу утверждать по собственному опыту, у меня сейчас так собирается весь фронт.


    1. cmyser
      02.02.2026 07:50

      Добрый день, а есть ли такие плагины в открытом доступе ? Мне очень актуально


      1. redigen
        02.02.2026 07:50

        Добрый день! В качестве вдохновения можете посмотреть плагин Buzzy, он позволяет собрать React из дизайна в Figma, предварительно разметив сам макет через плагин, но это не открытое решение и завязано на бэк Buzzy.
        Каких-то более открытых решений я не встречал


        1. cmyser
          02.02.2026 07:50

          Спасибо


    1. acsent1
      02.02.2026 07:50

      Фигма сама умеет хтмл генерить. Правда в платной версии


      1. redigen
        02.02.2026 07:50

        HTML/CSS — это базовый минимум. Можно сразу собирать прототипы или даже готовые приложения.

        У меня есть старая демка, правда, не для Figma, но смысл тот же


    1. ncix
      02.02.2026 07:50

      Таких готовых плагинов для фигмы - множество. Однажды перепробовал несколько самых популярных, но все они генерят очень очень плохой html+css.


      1. 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, а о инструменте, который может собрать прототип или приложение из дизайна. Можете посмотреть демонстрацию из моего предыдущего комментария выше


  1. Savek
    02.02.2026 07:50

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


  1. winkyBrain
    02.02.2026 07:50

    Любой не разраб на высокой должности в крупной компании


  1. wanamen
    02.02.2026 07:50

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