Design and AI
From Product Recording to Interactive Experience
A design experiment that turned a passive product recording into an interactive product experience built with Claude, HTML, and realistic product scenarios.
How I Built an Interactive Product Demo with Claude
Product videos are useful. They can quickly show how a feature looks and works.
But they are still something people watch.
For one of our product experiences at GTM Buddy, I wanted visitors to do more than watch a recording. I wanted them to explore the interface, select a use case, ask a question, and experience how the product might respond.
Instead of creating another animated screen recording, I rebuilt the experience as an interactive HTML demo using Claude.
The result looked and behaved like the product, but it worked independently inside the website using carefully prepared dummy data.
Why I wanted something more interactive
We were already using animated product recordings on the website. They were helpful for introducing features and showing basic workflows.
But recordings have a few natural limitations:
The experience is always linear
Visitors cannot choose what they want to explore
Every viewer sees the same scenario
Updating the video means recording and editing it again
The user cannot experience the product interaction directly
There are tools such as Supademo, Arcade, Walnut, and Storylane for creating interactive product demonstrations.
For this particular feature, however, I wanted more control over the interface, animation, content, and overall brand experience. I also wanted to explore whether we could build the complete experience ourselves with AI-assisted development.
The feature I recreated
The experience was built for Nucleus, GTM Buddy’s Revenue Activation Engine.
Nucleus works inside the tools revenue teams already use and helps them access relevant intelligence, content, coaching, and deal context through conversational interactions. GTM Buddy describes Nucleus as the infrastructure that makes Revenue Activation operational.
For the website experience, I focused on its chat interface.
The idea was to let a visitor select a realistic use case and watch Nucleus respond with relevant information. After the automatic introduction, the visitor could interact with the experience and explore other scenarios.
It was not connected to the actual product or live customer information. Everything was created using structured dummy data.
Starting with the real interface
I began by collecting the context Claude would need to understand the product.
This included:
GTM Buddy’s visual branding
The existing feature interface from a test environment
A saved web HTML version of the interface
Product screenshots
Sample questions and responses
A list of realistic product use cases
I gave the HTML and visual references to Claude and asked it to recreate the experience as a working, self-contained web interface.
The first output gave me the basic structure. The chat window worked, the content appeared, and the overall product flow was visible.
But it did not immediately feel like GTM Buddy.
That was where the real design work started.
Fixing the brand and interface details
The first version had several visual differences from the actual product.
Some colors were incorrect. The typography did not feel consistent. Spacing, button styles, icons, and smaller interface details needed more refinement.
Text instructions alone were not enough to fix everything accurately.
I added Figma designs and screenshots as stronger visual references. I also gave Claude more specific instructions about:
Color usage
Typography hierarchy
Container dimensions
Spacing
Corner radiuses
Chat message styles
Buttons and interactive states
Loading and response animations
After several rounds of comparison and correction, the HTML experience started to feel much closer to the actual product.
This process reminded me that AI needs more than a broad prompt. The quality of the result depends heavily on the context, references, and feedback we provide.
Creating realistic product scenarios
A working interface was not enough. The experience also needed realistic content.
I created a collection of predefined scenarios based on how someone might use Nucleus. Each scenario included:
A clear use case
A sample question
A realistic response
Supporting information
A suitable next action
The questions and responses used dummy data, but the structure reflected how the real product experience worked.
Each scenario needed a unique answer. Repeating the same response with a few changed words would make the demo feel artificial.
A useful interactive demo is not only about recreating the interface. The content also needs to show the value of the product.
Combining animation with interaction
I wanted the experience to work even if the visitor did not click anything immediately.
When the demo loads, it automatically presents an initial scenario. The chat begins, the question appears, and the response is generated through a sequence of animations.
This creates a guided introduction similar to a product video.
But as soon as the visitor selects another feature or use case, the experience becomes interactive. They can move between scenarios and explore different outcomes.
This gave us both formats in one experience:
An automatic product story for passive visitors
An interactive demo for people who wanted to explore
The animation helped introduce the feature, while the interactions gave the visitor control.
Handling unexpected questions
The predefined scenarios worked because every question had a carefully written response.
But a chat interface naturally invites people to type their own questions.
Since this was a product simulation and not the live Nucleus engine, it could not answer every possible request.
I added a fallback response for unsupported questions. Instead of showing an error or generating an unrelated answer, the demo explained that this was an interactive preview and invited the visitor to experience the full product.
The response worked as both an error state and a call to action.
This small detail was important because the demo needed to remain honest about what it could and could not do.
Working around the Webflow limit
The experience was intended for a website built in Webflow.
As the interface grew, the combined HTML, CSS, JavaScript, animations, scenarios, and responses became much larger. The code embed I was using had a 50,000-character limit.
That created another design and development challenge.
I had to reduce unnecessary code, simplify repeated styles, reuse components, and keep the scenario data structured. The goal was to reduce the file size without changing the appearance or breaking the interactions.
This made the final experience more efficient and helped me better understand how to structure self-contained interactive components for marketing websites.
How the final experience worked
The completed demo followed a simple flow:
The experience loaded inside the website.
An automatic conversation introduced the product feature.
The visitor could select from multiple use cases.
Each use case displayed its own question and response.
Animations made the conversation feel active.
Visitors could enter their own question.
Unsupported questions received a helpful demo message and CTA.
The complete experience worked without requiring access to the actual product.
The demo looked like a functioning product window, but it remained safe, controlled, and based entirely on dummy information.
It became useful beyond the website
The experience was originally created for the GTM Buddy website, but other teams also found it useful.
They could share it with prospects or customers who did not yet have access to the feature. Instead of only explaining the experience through slides or recordings, they could let someone interact with a focused simulation.
That was when I realised the experiment had become more than a website section.
It was a reusable sales and marketing asset.
What I learned from the project
The most valuable outcome was not only the final demo. It was discovering a workflow we could reuse.
The process became:
Start with an actual product workflow
Collect visual and structural references
Remove private or customer information
Recreate the interface with dummy data
Build realistic use cases
Add animation and interaction
Test the experience against the real product
Prepare it for the website or other customer-facing channels
This workflow allows us to build focused product experiences internally when we need complete control over the design and interaction.
Dedicated demo platforms are still valuable, especially when teams need analytics, personalization, collaboration, and demo management.
But for a focused feature experience, building it ourselves gave us more control over the story, interface, branding, and behaviour.
The designer’s role in an AI-built experience
Claude helped me move from an idea to working HTML much faster.
But creating the experience still required product understanding, interaction design, visual judgment, content writing, testing, and many rounds of correction.
AI could generate the interface, but it could not independently decide:
Which product story mattered
What a prospect needed to understand
Which interactions felt natural
Whether the brand looked accurate
Whether the responses felt believable
Where the demo needed to stop and guide users toward the real product
Those decisions remained part of the design process.
For me, this project was another example of how designers can use AI to move beyond mockups. We can now build and test the experience itself, learn from how it works, and ship something people can actually use.
The output is not only a design.
It becomes a working product story.
