На старте цифрового проекта у клиента далеко не всегда есть готовое техническое задание и точное понимание будущего продукта. Иногда есть только бизнес-задача и идея, которую сначала нужно проверить, прежде чем инвестировать в полноценную разработку.
Именно с такой ситуацией мы столкнулись в одном из проектов. К нам обратился крупный итальянский производитель кофеварок и кофемашин. Компания рассматривала возможность запуска мобильного приложения, но на тот момент еще не было однозначного понимания, каким должен быть сайт, какие функции действительно нужны пользователям и стоит ли в принципе переходить к полноценной разработке.
Вместо того чтобы начинать с длительного проектирования, мы решили сначала сделать идею осязаемой: проанализировать возможные сценарии использования и за один день собрать кликабельный прототип с помощью Claude Code.
Именно с такой ситуацией мы столкнулись в одном из проектов. К нам обратился крупный итальянский производитель кофеварок и кофемашин. Компания рассматривала возможность запуска мобильного приложения, но на тот момент еще не было однозначного понимания, каким должен быть сайт, какие функции действительно нужны пользователям и стоит ли в принципе переходить к полноценной разработке.
Вместо того чтобы начинать с длительного проектирования, мы решили сначала сделать идею осязаемой: проанализировать возможные сценарии использования и за один день собрать кликабельный прототип с помощью Claude Code.
В этой статье разберем весь процесс: что было на входе, как мы подготовили контекст для ИИ, почему большую роль сыграл первый промпт и что удалось понять о будущем продукте после появления работающего интерфейса.
На старте была не концепция приложения, а бизнес-задача.
У клиента уже существовал сильный бренд и большая продуктовая линейка. При этом была потребность усилить взаимодействие с владельцами после покупки и понять, может ли мобильное приложение стать для этого отдельным каналом.
Но оставалось много вопросов. Что должно находиться внутри приложения? Почему пользователь будет возвращаться в него после покупки кофеварки или кофемашины? Какую ценность сервис сможет приносить бизнесу? И главное — оправдана ли полноценная разработка?
Фактически на старте у нас было несколько вводных:
Поэтому первой задачей стало не написание кода, а формирование самой гипотезы.
Что получил Claude Code вместо классического ТЗ
Claude Code не начинал работу «из воздуха». Перед прототипированием мы провели экспресс-анализ бизнеса и контекста: изучили доступную информацию о бренде, ассортименте, особенностях и задачах, с которыми потенциально сталкиваются владельцы кофеварок и кофемашин.
Мы исходили из того, что приложение не должно ограничиваться еще одной точкой продаж. Оно должно было стать дополнительным контактом между брендом и покупателем на протяжении всего срока использования устройства.
В центре концепции оказались сценарии, которые продолжают взаимодействие с покупателем уже после приобретения устройства. Например, владельцу кофеварки или кофемашины может понадобиться найти совместимую запчасть или сменный элемент, понять, когда его пора заменить, подобрать аксессуар для конкретной модели, получить помощь при приготовлении кофе или повторно заказать расходные материалы. Дополнительно рассматривались механики повторных продаж и программы лояльности, которые могли бы стимулировать пользователя возвращаться в приложение.
У клиента уже существовал сильный бренд и большая продуктовая линейка. При этом была потребность усилить взаимодействие с владельцами после покупки и понять, может ли мобильное приложение стать для этого отдельным каналом.
Но оставалось много вопросов. Что должно находиться внутри приложения? Почему пользователь будет возвращаться в него после покупки кофеварки или кофемашины? Какую ценность сервис сможет приносить бизнесу? И главное — оправдана ли полноценная разработка?
Фактически на старте у нас было несколько вводных:
- общее понимание позиционирования бренда, его истории и продуктового направления;
- озвученная клиентом потребность в мобильном приложении;
- неопределенность относительно функциональности, масштаба и сложности будущего проекта.
Поэтому первой задачей стало не написание кода, а формирование самой гипотезы.
Что получил Claude Code вместо классического ТЗ
Claude Code не начинал работу «из воздуха». Перед прототипированием мы провели экспресс-анализ бизнеса и контекста: изучили доступную информацию о бренде, ассортименте, особенностях и задачах, с которыми потенциально сталкиваются владельцы кофеварок и кофемашин.
Мы исходили из того, что приложение не должно ограничиваться еще одной точкой продаж. Оно должно было стать дополнительным контактом между брендом и покупателем на протяжении всего срока использования устройства.
В центре концепции оказались сценарии, которые продолжают взаимодействие с покупателем уже после приобретения устройства. Например, владельцу кофеварки или кофемашины может понадобиться найти совместимую запчасть или сменный элемент, понять, когда его пора заменить, подобрать аксессуар для конкретной модели, получить помощь при приготовлении кофе или повторно заказать расходные материалы. Дополнительно рассматривались механики повторных продаж и программы лояльности, которые могли бы стимулировать пользователя возвращаться в приложение.
Для бизнеса за этими сценариями стояли уже другие задачи: увеличение повторных покупок, развитие прямого канала продаж, повышение лояльности и рост LTV за счет продолжения взаимодействия с покупателем после первой продажи.
Отдельно подготовили дизайн-ДНК бренда. Проанализировали фирменные цвета, типографику, фотографии продукции и общую визуальную стилистику. Задача заключалась не в том, чтобы перенести существующий сайт в приложение, а в том, чтобы сохранить узнаваемость бренда и адаптировать ее к современному мобильному интерфейсу.
Отдельно подготовили дизайн-ДНК бренда. Проанализировали фирменные цвета, типографику, фотографии продукции и общую визуальную стилистику. Задача заключалась не в том, чтобы перенести существующий сайт в приложение, а в том, чтобы сохранить узнаваемость бренда и адаптировать ее к современному мобильному интерфейсу.
После проработки концепции собрали подробный промпт для Claude Code. По сути, он заменил первичное техническое задание: мы описали не только то, какие экраны хотим увидеть, но и логику, пользовательские сценарии, визуальный язык и требования к интерактивности.
Чтобы Claude не просто собрал набор интерфейсов, задачу разбили на несколько смысловых блоков.
1. Сначала задали роль и общую концепцию продукта.
Например: мобильный web-app, который должен ощущаться как полноценное приложение бренда, а не как адаптированный интернет-магазин. Отдельно зафиксировали задачу соединить e-commerce, программу лояльности, сервис после покупки и кофейный ритуал.
2. Затем подробно описали пользовательские сценарии.
Вместо формулировки «сделать каталог и личный кабинет» перечислили конкретные действия пользователя: выбрать кофеварку, подобрать к ней запчасть, повторно заказать расходные материалы, пройти сценарий приготовления кофе, получить баллы, использовать программу лояльности или оформить заказ.
3. Для ключевых функций прописали поведение интерфейса.
Например, для Smart Brew Companion задали пошаговый процесс приготовления кофе с таймером и прогрессом, а для подбора запчастей — выбор модели и объема кофеварки с отображением совместимых деталей.
4. Отдельным блоком сформулировали требования к визуальному стилю.
Важно было не просто написать «сделать красиво в стиле бренда», а сразу обозначить, чего быть не должно: шаблонных AI-карточек, случайных градиентов, типового SaaS-интерфейса. Вместо этого задали конкретные ориентиры — итальянская кофейная эстетика, металл, эмаль, винтажная графика, фирменный красный цвет и более премиальная типографика.
5. В конце зафиксировали технические ограничения и критерии готовности.
Все основные действия должны были работать уже в прототипе: авторизация, навигация между экранами, корзина, избранное, начисление баллов, таймер, подбор запчастей и оформление заказа. Состояние пользователя сохранялось локально, а структура данных закладывалась так, чтобы в дальнейшем ее можно было подключить к реальному backend.
Такой уровень детализации оказался важнее самой длины промпта. Claude Code получил не команду «собери мобильное приложение», а систему ограничений и сценариев, внутри которой уже мог самостоятельно предлагать конкретную реализацию.
Для самого прототипа использовали React: это позволяло быстро перестраивать компоненты, менять логику экранов и проверять новые варианты интерфейса прямо по ходу работы.
Чтобы Claude не просто собрал набор интерфейсов, задачу разбили на несколько смысловых блоков.
1. Сначала задали роль и общую концепцию продукта.
Например: мобильный web-app, который должен ощущаться как полноценное приложение бренда, а не как адаптированный интернет-магазин. Отдельно зафиксировали задачу соединить e-commerce, программу лояльности, сервис после покупки и кофейный ритуал.
2. Затем подробно описали пользовательские сценарии.
Вместо формулировки «сделать каталог и личный кабинет» перечислили конкретные действия пользователя: выбрать кофеварку, подобрать к ней запчасть, повторно заказать расходные материалы, пройти сценарий приготовления кофе, получить баллы, использовать программу лояльности или оформить заказ.
3. Для ключевых функций прописали поведение интерфейса.
Например, для Smart Brew Companion задали пошаговый процесс приготовления кофе с таймером и прогрессом, а для подбора запчастей — выбор модели и объема кофеварки с отображением совместимых деталей.
4. Отдельным блоком сформулировали требования к визуальному стилю.
Важно было не просто написать «сделать красиво в стиле бренда», а сразу обозначить, чего быть не должно: шаблонных AI-карточек, случайных градиентов, типового SaaS-интерфейса. Вместо этого задали конкретные ориентиры — итальянская кофейная эстетика, металл, эмаль, винтажная графика, фирменный красный цвет и более премиальная типографика.
5. В конце зафиксировали технические ограничения и критерии готовности.
Все основные действия должны были работать уже в прототипе: авторизация, навигация между экранами, корзина, избранное, начисление баллов, таймер, подбор запчастей и оформление заказа. Состояние пользователя сохранялось локально, а структура данных закладывалась так, чтобы в дальнейшем ее можно было подключить к реальному backend.
Такой уровень детализации оказался важнее самой длины промпта. Claude Code получил не команду «собери мобильное приложение», а систему ограничений и сценариев, внутри которой уже мог самостоятельно предлагать конкретную реализацию.
Для самого прототипа использовали React: это позволяло быстро перестраивать компоненты, менять логику экранов и проверять новые варианты интерфейса прямо по ходу работы.
Первый запрос определяет почти весь результат
Один из главных выводов появился практически сразу: при таком способе работы особенно важен первый запрос.
Мы использовали подход one-shot: старались уже в первом промпте максимально подробно описать структуру, сценарии, визуальное направление и требования к интерфейсу.
Это принципиально, потому что первый результат задает примерно 80–85% будущего каркаса. Если базовая структура получилась удачной, дальше достаточно нескольких точечных итераций. Если же пытаться исправить неудачную основу отдельными командами, на это может уйти значительно больше времени.
Все основные страницы, которые были заложены в первоначальный запрос, Claude Code на Opus 4.8 смог собрать сразу.
Один из главных выводов появился практически сразу: при таком способе работы особенно важен первый запрос.
Мы использовали подход one-shot: старались уже в первом промпте максимально подробно описать структуру, сценарии, визуальное направление и требования к интерфейсу.
Это принципиально, потому что первый результат задает примерно 80–85% будущего каркаса. Если базовая структура получилась удачной, дальше достаточно нескольких точечных итераций. Если же пытаться исправить неудачную основу отдельными командами, на это может уйти значительно больше времени.
Все основные страницы, которые были заложены в первоначальный запрос, Claude Code на Opus 4.8 смог собрать сразу.
При этом ожидать финального результата после одного технического задания для ИИ не стоит. В первой версии не хватало части деталей мобильной верстки, анимаций и индивидуальной стилизации отдельных элементов. На типовых компонентах интерфейс местами становился слишком шаблонным.
Но базовая структура уже существовала и далее, за 2-3 промпта, нам удалось доработать визуал, отдельные состояния и детали взаимодействия.
На этом этапе мы использовали и другой ИИ-инструмент параллельно с Claude Code — для подготовки более подробных и точных задач. Такая связка оказалась удобной: один инструмент помогает сформулировать требования, второй сразу превращает их в работающий интерфейс.
Что получилось за один день
К концу дня у нас был уже не набор статичных экранов, а кликабельный веб-прототип, адаптированный под формат мобильного приложения.
В нем пользователь мог авторизоваться с тестовыми данными, перейти в каталог, просмотреть категории и карточки товаров, познакомиться с программой лояльности и ее уровнями, воспользоваться помощником по приготовлению кофе, запустить сценарий с таймером, выбрать модель своего устройства и найти подходящую сменную деталь.
То есть уже на этом этапе можно было пройти несколько ключевых пользовательских сценариев и понять, как отдельные функции складываются в единый продукт.
Появились основные экраны:
Но базовая структура уже существовала и далее, за 2-3 промпта, нам удалось доработать визуал, отдельные состояния и детали взаимодействия.
На этом этапе мы использовали и другой ИИ-инструмент параллельно с Claude Code — для подготовки более подробных и точных задач. Такая связка оказалась удобной: один инструмент помогает сформулировать требования, второй сразу превращает их в работающий интерфейс.
Что получилось за один день
К концу дня у нас был уже не набор статичных экранов, а кликабельный веб-прототип, адаптированный под формат мобильного приложения.
В нем пользователь мог авторизоваться с тестовыми данными, перейти в каталог, просмотреть категории и карточки товаров, познакомиться с программой лояльности и ее уровнями, воспользоваться помощником по приготовлению кофе, запустить сценарий с таймером, выбрать модель своего устройства и найти подходящую сменную деталь.
То есть уже на этом этапе можно было пройти несколько ключевых пользовательских сценариев и понять, как отдельные функции складываются в единый продукт.
Появились основные экраны:
- главная;
- программа лояльности;
- каталог и карточки товаров;
- подбор запчастей;
- помощник по приготовлению кофе.
При этом важно понимать ограничение такого подхода. Это был именно демонстрационный прототип, а не готовое приложение. В нем не было реальной серверной логики, интеграций с учетными системами, платежных механизмов и производственной базы данных.
Его задача была другой — показать, каким вообще может стать будущий продукт.
Где Claude Code все равно нужен человек
Claude Code хорошо справлялся с созданием основы и быстро реагировал на точечные изменения. Но решение о том, что именно нужно создавать, по-прежнему оставалось за командой.
ИИ может собрать экран каталога или программу лояльности. Но он не знает бизнес клиента настолько, чтобы самостоятельно определить, нужен ли пользователю этот экран, какую задачу он должен решать и почему человек будет возвращаться в приложение через неделю после покупки устройства.
То же касается визуальной части. Claude Code способен быстро создать качественную базу, но без подробного контекста отдельные элементы начинают выглядеть шаблонно. Поэтому после первого one-shot-промпта мы отдельно корректировали стили, мобильную верстку, анимации и некоторые элементы интерфейса.
Живой прототип изменил саму концепцию продукта
Самое интересное началось после того, как мы показали прототип клиенту и смогли обсуждать уже не абстрактную идею приложения, а конкретные пользовательские сценарии.
Стало заметно то, что гораздо сложнее увидеть в описании или на отдельных статичных макетах: если сделать приложение преимущественно мобильной версией интернет-магазина, у пользователя практически не будет причин регулярно в него возвращаться.
Его задача была другой — показать, каким вообще может стать будущий продукт.
Где Claude Code все равно нужен человек
Claude Code хорошо справлялся с созданием основы и быстро реагировал на точечные изменения. Но решение о том, что именно нужно создавать, по-прежнему оставалось за командой.
ИИ может собрать экран каталога или программу лояльности. Но он не знает бизнес клиента настолько, чтобы самостоятельно определить, нужен ли пользователю этот экран, какую задачу он должен решать и почему человек будет возвращаться в приложение через неделю после покупки устройства.
То же касается визуальной части. Claude Code способен быстро создать качественную базу, но без подробного контекста отдельные элементы начинают выглядеть шаблонно. Поэтому после первого one-shot-промпта мы отдельно корректировали стили, мобильную верстку, анимации и некоторые элементы интерфейса.
Живой прототип изменил саму концепцию продукта
Самое интересное началось после того, как мы показали прототип клиенту и смогли обсуждать уже не абстрактную идею приложения, а конкретные пользовательские сценарии.
Стало заметно то, что гораздо сложнее увидеть в описании или на отдельных статичных макетах: если сделать приложение преимущественно мобильной версией интернет-магазина, у пользователя практически не будет причин регулярно в него возвращаться.
Каталог оставался важной частью концепции, но сам по себе не создавал достаточной ценности.
Поэтому акцент постепенно сместился на сервисные и удерживающие сценарии. Именно здесь прототипирование дало больше, чем просто экономию времени. Работающий интерфейс помог скорректировать саму гипотезу еще до начала полноценной разработки.
Можно ли использовать этот код в реальном приложении
Код, созданный во время быстрого прототипирования, не стоит автоматически воспринимать как основу промышленного продукта.
В нашем случае это особенно важно: прототип мобильного приложения фактически был реализован как веб-приложение и работал в браузере. Такой подход выбрали намеренно.
Если бы мы сразу делали нативный прототип, потребовалось бы больше времени на сборку, отладку и передачу версии клиенту для установки на устройства. Веб-формат позволил избежать этого этапа: достаточно отправить ссылку, которую можно открыть с компьютера, iOS- или Android-устройства.
Обратная сторона такого решения — полученный код нельзя просто взять и перенести в нативное мобильное приложение.
Но это и не было основной целью.
Ценность кода на этом этапе заключалась в возможности проверить структуру, продемонстрировать сценарии, согласовать направление, выявить спорные решения и получить более конкретную основу для оценки будущей разработки.
Часть компонентов, структуры экранов и интерфейсных решений потенциально можно использовать повторно. Но перед полноценной разработкой в любом случае необходимо отдельно оценить архитектуру, безопасность, масштабируемость и требования целевой платформы.
Вместо вывода: что в итоге дал один день прототипирования
За один день вместо идеи «возможно, нам нужно мобильное приложение» появился интерфейс, который можно было открыть, пройти как пользователь, показать руководству и обсудить. Для клиента это стало возможностью увидеть потенциальный масштаб проекта, оценить сценарии и получить более предметное представление о том, во что в дальнейшем предстоит инвестировать.
Claude Code в этом случае заметно сократил путь от гипотезы до ее проверки. То, что раньше потребовало бы отдельного этапа проектирования, удалось довести до кликабельного интерфейса за один день.
Поэтому акцент постепенно сместился на сервисные и удерживающие сценарии. Именно здесь прототипирование дало больше, чем просто экономию времени. Работающий интерфейс помог скорректировать саму гипотезу еще до начала полноценной разработки.
Можно ли использовать этот код в реальном приложении
Код, созданный во время быстрого прототипирования, не стоит автоматически воспринимать как основу промышленного продукта.
В нашем случае это особенно важно: прототип мобильного приложения фактически был реализован как веб-приложение и работал в браузере. Такой подход выбрали намеренно.
Если бы мы сразу делали нативный прототип, потребовалось бы больше времени на сборку, отладку и передачу версии клиенту для установки на устройства. Веб-формат позволил избежать этого этапа: достаточно отправить ссылку, которую можно открыть с компьютера, iOS- или Android-устройства.
Обратная сторона такого решения — полученный код нельзя просто взять и перенести в нативное мобильное приложение.
Но это и не было основной целью.
Ценность кода на этом этапе заключалась в возможности проверить структуру, продемонстрировать сценарии, согласовать направление, выявить спорные решения и получить более конкретную основу для оценки будущей разработки.
Часть компонентов, структуры экранов и интерфейсных решений потенциально можно использовать повторно. Но перед полноценной разработкой в любом случае необходимо отдельно оценить архитектуру, безопасность, масштабируемость и требования целевой платформы.
Вместо вывода: что в итоге дал один день прототипирования
За один день вместо идеи «возможно, нам нужно мобильное приложение» появился интерфейс, который можно было открыть, пройти как пользователь, показать руководству и обсудить. Для клиента это стало возможностью увидеть потенциальный масштаб проекта, оценить сценарии и получить более предметное представление о том, во что в дальнейшем предстоит инвестировать.
Claude Code в этом случае заметно сократил путь от гипотезы до ее проверки. То, что раньше потребовало бы отдельного этапа проектирования, удалось довести до кликабельного интерфейса за один день.
При этом главным результатом стал даже не сам прототип. Работающий интерфейс позволил еще до начала полноценной разработки проверить концепцию, увидеть ее слабые места и скорректировать направление будущего продукта. Клиенту не пришлось представлять его по описанию — он смог сразу открыть его и попробовать.
В целом подобный подход мы все чаще предлагаем клиентам уже на этапе верхнеуровневого сбора требований. Прототип позволяет не только обсудить будущий продукт, но и сразу увидеть его в работе, проверить основные сценарии и точнее оценить объем проекта. В итоге многие спорные решения можно скорректировать еще до разработки — и не тратить время и бюджет на их переделку позже.
В целом подобный подход мы все чаще предлагаем клиентам уже на этапе верхнеуровневого сбора требований. Прототип позволяет не только обсудить будущий продукт, но и сразу увидеть его в работе, проверить основные сценарии и точнее оценить объем проекта. В итоге многие спорные решения можно скорректировать еще до разработки — и не тратить время и бюджет на их переделку позже.