--- title: "Prototyping with AI Tools | Utkarsh Panwar" description: "Prototyping with AI tools as a product designer: which tools suit which question, how to get a testable prototype instead of a demo, and when to switch." url: https://www.utkarshdesign.com/guides/ai-prototyping author: Utkarsh Dhairya Panwar updated: 2026-10-08 --- # Prototyping with AI tools Guide · 6 min read · By [Utkarsh Dhairya Panwar](https://www.utkarshdesign.com/about) · Updated 8 Oct 2026 **AI prototyping tools turn a description into a working interface in minutes, so you can test interactions mockups can't show. Answer one question per prototype, with realistic data and a failure state, and test it with a user. Use Figma for visual polish and engineers for scale.** ## Why I build working prototypes now Most of my prototypes used to be Figma frames joined by arrows. They were fine for flows and useless for anything that depended on real input: a gesture, typing, a slider that changes a result live. You couldn't learn how those felt until an engineer built them. AI coding tools changed that. I don't write code myself, but by directing these tools I've built small working things on the side: Mitti, where you shape a clay pot on a wheel with hand gestures through a webcam; Type Piano, a keyboard that composes type onto a poster; Gesture Particles, where hand gestures reshape a 3D particle cloud; a Chrome extension; and a Figma plugin for print exports. None of them would have worked as Figma prototypes, because the point of each was how it felt to use. Type Piano: the idea only made sense once you could type on it. ## A demo and a prototype are different things AI tools are very good at producing demos: a polished screen that works on the path the person who made it already knows. A prototype is something you can learn from, which means someone else can use it, on their own, and get stuck. | Demo | Testable prototype | | --- | --- | | Works on the one path you prompted | Works on the paths a tester might try, including wrong ones | | Lorem ipsum or perfect sample data | Realistic data, with long names, empty lists and odd values | | Only a success state | At least one failure, loading and empty state | | You drive it during the meeting | A stranger uses it while you watch and stay quiet | | Looks finished, so feedback is about colours | Looks rough enough that feedback is about the idea | People skip over that last row. AI tools produce interfaces that look done, and people give polish feedback to anything that looks done. If you want feedback on the flow, say so up front, or strip the styling back. ## Which kind of tool for which question | Question you're answering | Kind of tool | Examples | | --- | --- | --- | | Does this interaction feel right? | Prompt-to-app builders or a coding assistant in an editor | v0, Lovable, Bolt, Cursor, Claude Code | | Does this flow make sense on top of the existing designs? | AI inside the design tool | Figma Make | | Will this landing page explain the product? | AI-assisted site builders | Framer | | Can this automation save the team time? | Workflow tools | n8n, Zapier | | Does this look like your product? | Not AI-first. Your design tool and design system | Figma | Tools in this space change every few months, so read the examples as a snapshot rather than a ranking. The categories last longer than the names do. I'd pick by the question first, then by which tool your team can open and edit without asking you. ## How I run an AI prototype 1. **Write the question in one line**: "Can a first-time user connect a repo without help?" not "build the onboarding". The question decides what to build and what to fake. 2. **Build only the path the question needs**: Fake everything else with a static screen or a "not in this prototype" note. 3. **Load realistic data**: Ask the AI for sample data that includes long values, empty states and an error. Perfect data hides the problems you're testing for. 4. **Break it on purpose**: Click in the wrong order, refresh mid-flow, paste nonsense. Fix what a tester would hit in the first minute. 5. **Test with someone who hasn't seen it**: Five people tell you more than one long internal review. Watch and don't explain. 6. **Throw it away or hand it over**: Write down what you learned. The code is usually not the deliverable. The best tested prototype I can point to predates these tools: the FamPay payment error states, usability-tested before they shipped (the story is in my guide to payment failure UX). The method is the same with an AI prototype. Only the build gets faster. ## When to go back to Figma, and when to hand it to engineers - Back to Figma when the question becomes visual: hierarchy, brand, consistency with a design system. AI tools default to a generic look, and fighting that in prompts is slower than designing it. - Back to Figma when several people need to comment on many screens side by side. - To engineers and production code when the question is performance, real data, permissions or anything security-related. A prototype that "works" on mock data proves nothing about those. - Stay in the AI tool while you're still learning something new from each test round. The mistake I see most is the prototype that slowly becomes the product. It ships with fake error handling and no one remembers which parts were faked. Decide on day one whether this code is disposable. ## For product managers AI prototyping tools have been very good for PM and design collaboration. A PM can now bring a clickable version of an idea to a design review instead of a doc. That's a better starting point for the conversation, as long as everyone treats it as a question rather than a spec. You can try the playground builds yourself on this site. If you'd rather have a designer turn an idea into something testable and put it in front of users, that's what my prototyping service is for. ## Questions people ask ### What is vibe coding? Building software by describing what you want to an AI and iterating on the result, rather than writing every line yourself. For designers it's a fast way to make prototypes that work. ### Can AI prototyping tools replace Figma? Not for visual design, design systems or reviewing many screens together. They're better for testing how something feels to use. I use both, for different questions. ### Which AI prototyping tool is best for product managers? Whichever your team can open and edit without help. Prompt-to-app builders are the easiest start; Figma Make suits teams who already work in Figma. ### Is code from an AI prototype ready to ship? Usually not. Prototype code fakes data, errors and permissions. Treat it as a way to learn, then build the real thing with engineers. ## Sources 1. [Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/), Nielsen Norman Group 2. [UX Prototypes: Low Fidelity vs. High Fidelity](https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/), Nielsen Norman Group 3. [Explore Figma Make](https://help.figma.com/hc/en-us/articles/31304412302231-Explore-Figma-Make), Figma Help Center ## Working on this? Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact). ## Related - [Interactive prototypes for startups](https://www.utkarshdesign.com/services/prototyping) - [Payment failure UX for timeouts, declines and retries](https://www.utkarshdesign.com/guides/payment-failure-ux) - [Designing AI features users trust](https://www.utkarshdesign.com/guides/designing-ai-features) - [Playground](https://www.utkarshdesign.com/playground) --- Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt