Rapid Prototyping с Claude Code: от Axure и Figma к живым прототипам

Годами мы показывали клиентам картинки и кликабельные мокапы в Axure или Figma. С появлением Claude Code мы перешли на новый уровень: от идеи до рабочего приложения — за часы, не за недели. Теперь вместо мокапов показываем работающий прототип.

Зачем вообще прототипы

У любого продукта есть фаза, когда идеи нужно «пощупать». В нашей компании мы называем её Discovery фазой. Клиент читает ТЗ и кивает — а потом видит результат и говорит: «Я имел в виду совсем другое». Это нормально. Люди плохо представляют интерфейсы по текстовому описанию. Даже опытные продакт-менеджеры.

Поэтому мы уже давно работали так:

• Рисовали экраны с UI и UX в Axure
• Показывали на созвонах
• Делали заметки прямо во время обсуждения
• Готовили несколько вариантов для спорных решений
• Итерировали до тех пор, пока все не сходилось
• На основе прототипов делали документацию и отдавали в разработку

Вероятность ошибки падала в разы. Клиент генерировал свои идеи, оценивал наши. Для многих вещей мы готовили несколько вариантов — выбирай, что больше нравится. Это работало. Но всё-таки это были картинки.

Что изменилось с Claude Code

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

С Claude Code всё иначе. Ты описываешь, что хочешь, и получаешь рабочее приложение на React или Next.js. От идеи до рабочего прототипа — час-два вместо недели в Axure. По сути, это AI-альтернатива Axure и подобным инструментам прототипирования.

По сути, разработка прототипа — это вайб-кодинг на минималках. Просто начинаешь строить приложение с нуля, делаешь основные функциональные части, но не думаешь о том, чтобы сделать всё идеально. Какие-то вещи можно не прорабатывать и опустить. Какие-то вообще не нужны: бэкенд для хранения данных, оптимизация производительности, адаптивная вёрстка для всех экранов. Не думаешь о качестве кода, о код-ревью, о правильной архитектуре. Цель — показать поведение, а не написать production-ready код. (Про то, как эффективно работать с Claude Code в таком режиме, я подробнее писал в предыдущем посте.)

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

Что можно делать в живом прототипе

Data store с реалистичным поведением. Вместо статичных экранов — приложение с хранилищем данных. Система реагирует на действия пользователя: применённые фильтры, изменённые настройки, введённые данные. Клиент видит не «как будет выглядеть», а «как будет работать».

Моделирование сценариев. Нужно показать, что происходит при разных условиях? Добавляешь переключатель сценариев прямо в интерфейс. Кнопка «Сценарий: пользователь впервые» — и приложение переходит в нужное состояние. «Сценарий: просроченная подписка» — и все элементы перестраиваются.

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

Быстрые итерации. Клиент после созвона пишет: «А что если эту таблицу разбить на две вкладки?» Раньше это означало новый цикл работы в Axure. Теперь — пара промптов, и обновлённый вариант готов к следующему обсуждению.

Что это даёт на практике

Разница не только в скорости. Меняется качество обратной связи.

Когда клиент смотрит на картинку, он оценивает визуал. Когда клиент пользуется работающим приложением — он думает о процессах. «А что если пользователь сделает вот так?» — и тут же проверяет. Разговор уходит от «сделайте кнопку побольше» к «нам нужно обрабатывать вот этот edge case». Это напрямую снижает количество ошибок в готовом продукте — проблемы находятся на этапе прототипа, а не после релиза.

Ещё один эффект — доверие. Клиент видит, что через две недели уже есть что-то рабочее, пусть и прототип. Это снимает типичную тревогу «мы платим деньги, а результатов не видно».

И ещё один важный эффект, который легко упустить: прототип помогает не только клиенту, но и разработчикам. Вместо того чтобы разбираться в текстовой спецификации, разработчик может прокликать всё поведение, посмотреть своими глазами и имплементировать точно так же в реальном приложении. В тексте всегда можно что-то упустить или понять неоднозначно — а тут всё наглядно. К тому же какие-то куски кода можно взять прямо из прототипа: анимации, сложное поведение форм, нестандартные UI-паттерны.

Прототип и документация в одной сессии

На практике работа с прототипом идёт кусками. Не бывает так, что ты один раз обсудил всё и ушёл разрабатывать. Новая фича, изменение в логике, пересмотр приоритетов — каждый такой кусок работы начинается с нового контекстного окна в Claude Code.

И вот что удобно: в этом же контексте, в этой же сессии, можно сгенерировать не только прототип, но и документацию для разработчиков. Claude Code видит весь прототип, понимает логику, знает, какие решения были приняты — и может сразу оформить это в спецификацию или user story.

После обсуждения с клиентом или командой вносишь правки в прототип — и тут же обновляешь документацию. Всё идёт в одной пачке: прототип, описание поведения, acceptance criteria. Нет расхождений между тем, что показали, и тем, что записали. Нет ситуации, когда прототип уже поменялся, а документация осталась от прошлой версии.

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

Ограничения и честность

Важно не обмануть ожидания. Прототип — это прототип. Нужно чётко проговаривать:

• Это не финальный дизайн
• Под капотом нет настоящего бэкенда
• Данные захардкожены
• Цель — обсудить поведение, а не утвердить пиксели

Если клиент начинает воспринимать прототип как готовый продукт — это проблема. Особенно когда прототип выглядит слишком хорошо. Парадоксально, но иногда сырой вид даже полезен — он напоминает, что это черновик.

Как это вписывается в процесс

Прототипирование с Claude Code не заменяет остальные этапы. Это один из инструментов в цепочке:

1. Discovery — понимаем задачу, собираем требования
2. Прототип — генерируем рабочее приложение, показываем клиенту, итерируем
3. Спецификация — фиксируем утверждённое поведение
4. Дизайн — работа в Figma с учётом утверждённого функционала
5. Разработка — реализация уже с ясным пониманием, что строим

Прототип ускоряет шаги 1-3 и сильно снижает риск дорогих переделок на шаге 5.

От прототипа к high fidelity — и дальше без дизайнера

Следующий этап ещё интереснее. Когда функционал утверждён и дизайнер подготовил high fidelity макеты в Figma, прототип можно довести до соответствия этим макетам. Claude Code через MCP-плагины для Figma превращает макеты в код — подтягивает токены, стили, компоненты — и применяет их к уже работающему приложению. По сути, это Figma-to-code, но не в вакууме, а поверх прототипа с реальной логикой.

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

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

Зато вот что уже работает: после того как прототип доведён до high fidelity на основе Figma, необходимость постоянно поддерживать макеты в Figma в актуальном состоянии отпадает. Новые экраны, новые страницы, новые состояния — всё это можно добавлять прямо в прототип, выдерживая тот же визуальный стиль, без участия дизайнера.

Дизайнер становится нужен только для по-настоящему уникальных вещей: нестандартные визуализации, сложная анимация, принципиально новый паттерн взаимодействия. Рутинные экраны — формы, таблицы, дашборды, настройки — Claude Code делает сам, в рамках уже заданной дизайн-системы.

Итого

Раньше прототипирование было отдельным навыком, требующим отдельных инструментов. Теперь это побочный продукт общения с AI. Описал — получил — показал — обсудил — поправил. От идеи до рабочего приложения — часы, не недели. А клиент вместо картинок видит работающую систему, с которой можно взаимодействовать.

И что важнее — прототип не выбрасывается. Он эволюционирует: от черновика к утверждённому поведению, от поведения к high fidelity, от high fidelity к живому справочнику для новых экранов. Каждый этап добавляет ценность, ничего не теряется.

Axure стоит на полке. Не потому что плохой инструмент, а потому что задачу теперь можно решить быстрее и убедительнее.