← Knowledge Notes
Indie Building / Knowledge note · English

AI-Driven Product Design / Vibe Coding Workflow (One-Sentence Requirement → Interrogation → PRD → DRD + Coding Prompt → Figma Make Demo → Launch → Visual Iteration)

Will’s complete pipeline for non-technical PMs to go from “idea to runnable prototype”, breaking vibe coding into 7 copyable steps: ① Use 3 tiers of templates to turn a one-sentence product idea into structured input; ② Have AI act as a “requirements interrogator” to ask follow-up questions in sequence and force out a Grill Summary; ③ Use a “top-tier product architect” role prompt to expand the 5 answers into an investment-grade PRD; ④ Extract feature points from the PRD to generate 3 non-overlapping interaction DRD options, then convert the chosen option into a coding prompt that can directly produce a product; ⑤ Feed it to Figma Make (to produce an interactive demo) or Claude (to produce a real launch-ready product) to generate a prototype; ⑥ Feed screenshots back in to let AI spot errors and iterate on its own; ⑦ Publish to mobile (Claude outputs HTML → Netlify Drop drag-and-drop hosting → add to home screen as an App) + one-click reskinning with ReferoStyle. Each step provides reusable prompt skeletons + Why + examples + pitfalls. Three parallel methods (Method 1 Document-driven mainline / Method 2 Document-driven HTML output / Method 3 GPT+Figma natural language UI building). The audience is non-technical product managers who care about “when to use which step, how to copy the prompts” rather than code. Division of labor with [[newtype-ai-coding]]: that article covers tool stack selection and mindset (how to choose Cursor/Claude Code/Codex), while this article covers the concrete action chain and prompt templates for non-technical PMs to run through a prototype from scratch.

Source collection:AI Products and Assisted Design · Published here:2026-09-26 · Note updated:2026-06-03

Vibe CodingProduct PrototypingAI Programming

One main pipeline:One-sentence requirement → AI interrogation → PRD → DRD + coding prompt → Figma Make / Claude produces demo → feedback iteration → publish to mobile → visual reskin. Every step follows “you speak in plain language, AI does the work”; your entire job is to copy and paste the output of the previous step as the input for the next step.

When to open this:

  • You have a product idea (even if it’s just one sentence) and want to build a tappable mobile prototype to show your boss/users without writing code
  • You don’t know “what the first prompt should be after getting a one-sentence requirement”
  • You want a set of directly copyable prompt templates (interrogator / PRD / DRD / product generation / review iteration)
  • You want to figure out at which step Figma Make and Claude should each be used in this chain

Division of labor:newtype · AI Coding Practice and Tool Stack Evolution covers “how to choose the tool stack, what the mindset is” (tradeoffs between Cursor / Claude Code / Codex); this article covers “concrete actions + prompts for non-technical PMs to run a prototype from scratch”. For visual/interaction details see UX Interaction Paradigms in the AI Era (Traditional UI with embedded AI / Agentive / Conversational / Human-AI Collaboration / Hyper-personalization / Multimodal / Trends — seven types), for the delivery phase see AI-Assisted UX · Delivery Phase (Using AI for layout design · layout-to-code Figma · solution review · demonstrating AI value + will’s homemade UX metric breakdown skill).


0. Big picture: why it’s split into two stages — “thinking layer + coding layer”

One-sentence main workflow (runs through the whole article):

描述想法 → AI 结构化 → PRD → AI 交互文档(DRD) → 氛围编程提示词 → Figma Make / Claude → 生成产品 → 反馈与迭代

Why split it this way: hand over the thinking layer work — “writing PRDs, building architecture, defining flows, generating code snippets, discussing interactions, producing initial design drafts” — to AIs that converse in natural language (ChatGPT / Claude / Figma Make); they are the best partners for PM + UX. But they are not real vibe coding — real vibe coding (such as Claude Code + Cursor) can read entire codebases, create files, run commands, run tests, and debug to fix bugs. Therefore:

  • If you only want a demoable, tappable prototype → thinking-layer tools (the mainline of this article) are enough, no code knowledge required.
  • If you want to build a real product that can launch and run as an MVP → you also need to bring in Claude Code, and pick up a bit of R&D knowledge.

Translation: don’t expect one tool to go from idea all the way to launch.Use “conversational AI” for early prototyping, then bring in “coding Agents” when you need to scale and launch. This is the same anti-pattern described in newtype · AI Coding Practice and Tool Stack Evolution §2 “v0 for design / Claude for architecture / Cursor for implementation, each handles one segment,” follows the same anti-pattern.

Life analogy: building a house. Method 1 is drawing up the “requirements specification + floor plan + decoration style manual” first, then having the construction team build accordingly (document-driven, most stable quality); the clearer you think upfront, the less rework during construction.

This article consolidates Will’s three parallel approaches into one main workflow + two variants:

Route Entry tool Output Best for
Method 1 (Mainline) ChatGPT/Claude conversation DRD + coding prompt → Figma Make demo Those who want the standard “think clearly before acting” pipeline
Method 2 Claude conversation Directly output runnable HTML → send to phone Those who want to skip Figma and get something runnable directly
Method 3 GPT + Figma connection Build UI in Figma with natural language UI-heavy work, wanting to use off-the-shelf design systems like iOS Liquid Glass

Below we walk through the main workflow step by step; variants are marked in the corresponding steps.


1. Step 1: Write the “one-sentence idea” into structured input

Why: AI output quality = the amount of information you give. A line like “I want to make a chat app” will make AI guess the direction entirely. This step is about first compressing the vague stuff in your head into text, choosing a template based on how clear your thinking is; not all fields are required.

Three tiers of templates (in order of increasing idea clarity):

Tier 1 — Idea is still very vague, use the simplest expression

Skeleton A (User + Need + Difficulty): “I want to make an App for [who] to use; they need [what] to [do what].” Example: For people who want to stay in frequent contact with family and colleagues; they need a simple, stable acquaintance social app to send messages, create groups, and share files.

Skeleton B (If / Then, centered on user behavior): “If the user [performs some action], then they can [get some result].” Example: If the user logs in and imports their contacts, then they can quickly find acquaintances and start a chat with one tap.

Tier 2 — Five-question template (most commonly used, recommended for starting out)

1 你想做的产品是干嘛的?         (像微信一样聊天 / 帮我整理视频内容)
2 谁会用?在什么情况下用?        (小团队远程协作 / 学生刷视频后整理笔记)
3 现在他们怎么解决?有什么不爽?   (用微信群 + Notion,很乱)
4 最核心的 1–3 个功能是什么?     (聊天、自动整理任务、提醒)
5 有没有「必须有」的特别点?(可选)(AI 自动帮我做 / 不用手动整理)

Tier 3 — Complex product framework (when thinking is already clear, highest information density)

Write in four blocks, fields are optional:

  • Business constraints (Why): Product goals / business goals (conversion · retention · revenue) / current problems / success metrics (must be quantified, e.g. 7-day retention ≥ 25%)
  • User structure (Who + When): Core users / usage scenarios (must be specific) / user tasks / current behavior paths
  • Problem definition (Problem): Specific problems (observable) / impact (metrics · behavior) / possible causes (hypotheses)
  • Solution strategy (Strategy): Design goals / core strategy (it is an approach, not a feature) / why it works
  • Product structure (What): Feature modules / page structure / user flows / state changes

Pitfall: Tier 3 has many fields, don’t force-fill them all. If you can fill Tier 2, fill Tier 2 first —the vague parts are exactly what the next step “AI interrogation” will help you force out, no need to strain to come up with them now.


2. Step 2: Let AI act as a “requirements interrogator” to force out a Grill Summary

Why: This is the only step where you “answer passively”. When product positioning is unclear, letting AI generate directly is equivalent to letting it make guesses for you. Instead, have it act as an interrogator asking follow-up questions in a chain(users / scenarios / scale / boundaries / goals), forcing out the things you haven’t even thought through one by one, and finally producing a “Grill Summary”.Without this step, everything after is guesswork.

Reusable prompt skeleton (Interrogator):

你现在不是生成产品,而是「需求拷问器」(requirements interrogator)。
目标:确保需求被完全澄清,不能有模糊。
行为:
- 连续追问直到问题清晰
- 使用决策树深入
- 覆盖:用户、场景、规模、边界、目标
输出:生成一份完整的需求总结(Grill Summary)。

Operation chain: Paste the prompt above → describe your product in a paragraph of natural language → answer each question it raises in order → it outputs the final Grill Summary.

Wrap-up: compress the summary into “input for the next handoff”. Grill Summaries are often long; generate a condensed version based on “who you will feed it to next”:

For Figma Make(producing interactive prototype): “Write this into a description that lets Figma Make code a demo, keep all features and content clear,compress to as few words as possible. ”

For Claude(producing real launch-ready product): “Write this into a description that lets Claude code a real, launch-ready product, keep all features and content clear, compress to as few words as possible.”

Key difference: Figma Make produces a “tappable demo”; Claude calls APIs and can run a truly usable program in a local browser. Whichever tool you feed next, generate that version of the condensed description here. Keep both the long (detailed) version and the condensed version; you can choose either for the PRD step.


3. Step 3: Expand the 5 answers into an investment-grade PRD

Why: The Grill Summary is still at the level of “what the user said”. The PRD step needs to perform product-level deduction + system-level completion on it — automatically filling in behaviors, scenarios, system structure, data structure, AI capabilities, and technical implementation that the user didn’t state clearly, reaching a granularity that is “directly developable”. The key is to give AI a high-spec role(product architect + UX + AI product designer + technical lead), so it outputs at the density of a professional PRD.

Reusable prompt skeleton (PRD generation, condensed version):

你是「顶级产品架构师 + UX 专家 + AI 产品设计师 + 技术负责人」。
基于我下面 5 个简要回答,生成一份完整、可直接开发的 PRD。

硬要求:
- 不许停在用户输入层 → 必须做产品级推演 + 系统级补全
- 自动补全:用户行为 / 使用场景 / 系统结构 / AI 能力 / 数据结构 / 技术实现
- 输出要达到:投资级 + 架构级 + 可开发级
- 不要解释推理过程,直接输出最终 PRD

输出结构(严格按序):
1 产品哲学(为什么存在 / 现有方案问题 / 范式改变 / 一句话 Slogan)
2 问题陈述(当前真实行为 / 为什么低效 / 典型失败场景,要有画面感)
3 目标用户(核心用户 + 使用动机 + 明确的「非目标用户」)
4 核心用户场景(用「时间线 + 对话 + 状态变化」写,≥3 个:正常 / 异常 / 协作断层)
5 产品定位(一句话 + Slogan + 竞品对比表)
6 核心概念模型(定义核心实体 + 实体关系)
7 数据模型(TypeScript 风格字段 + 状态流 + 依赖关系)
8 UX 架构(导航 / 核心页面 / 页面职责 / 视图逻辑)
9 AI 行为系统(若涉及 AI:触发机制 / 提取生成能力 / 主动行为)
10 协作与同步机制(信息怎么流 / 谁要知道 / 被动·主动·强制同步)
11 技术架构(前端 / 后端 / 数据库 / 实时通信 / AI 调用方式)
12 商业模式(收费 / 成本结构尤其 AI 成本 / 扩展路径)
13 开发路线图(MVP 拆解 + 每阶段交付)
14 设计原则(3–5 条,每条对应实现方式)

输出风格:必须是「已经想清楚的产品」,禁止出现「可能 / 建议 / 假设」,
专业 PRD 语气,信息密度高。

输入(5 个问题的回答):
{{在这里粘贴 §1 五问式的回答}}

Pitfall (emphasized by Will): The PRD produced by AI is only a first draft and structural reference, do not apply it directly. You must calibrate it item by item against your real product idea — otherwise requirement deviations will be amplified by every subsequent step, and the final output will be distorted. Treat “revising the PRD” as a mandatory step; iterate until it matches real scenarios before moving on.


4. Step 4: PRD → multi-option DRD → coding prompt

This step has two sub-steps: first grow multiple interaction options (DRD, Design Requirement Doc) from the PRD, then convert the chosen option into a coding prompt that can directly produce a product.

Why “multiple options”: The same PRD can have completely different interaction skeletons (e.g. chat-first vs content-feed-first). Having AI diverge into 3 non-overlapping options at once, then you compare horizontally and pick one, is far better than AI giving you one single option in a black box and you settling for it.

4.1 Produce three DRDs

从 PRD 中系统提取功能点、用户路径与页面内容,输出可直接执行的 DRD;
同时围绕产品目标,发散出 3 个思路完全不同、互不重叠的交互框架方案。
每个 DRD 都以完整的产品用户体验设计视角呈现。

→ Input: PRD; Output: 3 sets of DRDs. After reading, pick the one that best fits the goal (called “Option 1” below).

4.2 Convert the chosen option into a coding prompt

将方案 1 转为一个可直接生成产品的提示词。

→ Output: a segment of “vibe coding prompt”, which is the final ammunition fed to Figma Make / Claude.

Life analogy: DRD is “three floor plans for you to choose from”; the coding prompt is “translating the chosen floor plan into a work order the construction team can follow”.


5. Step 5: Produce demo — Figma Make (interactive demo) / Claude (real product)

Feed the coding prompt from §4.2 into the generation tool to get the first version of the prototype.Which tool to use depends on which condensed description you generated at the end of §2:

Tool Output When to use
Figma Make Multiple interactive demos (tappable, demo-oriented) Showing effects to boss/users, quickly comparing interaction options
Claude Real launch-ready product (calls APIs, runs in a local browser) When you want something truly usable and are heading toward an MVP

Operation:Drop in the prompt → it generates a prototype → take a screenshot, then proceed to §6 for iteration. Figma Make usually produces multiple demo options at once, so you can compare them side by side.

Pitfall:An interactive demo from Figma Make ≠ a launch-ready product. If you want real usability, generate a "Claude version" of the condensed description from §2, switch to Claude to produce the actual program (then proceed to §7 for launch).


6. Step 6: Feedback Iteration — Let AI Review Screenshots and Catch Its Own Mistakes

Why:The first generated version always has deviations.Don't pick out every flaw with your naked eye—feed the screenshots back to the AI, have it compare against the product documents and list out "problems + fixes" on its own; you only act as the judge. This step is extremely low-cost and highly recommended.

6.1 Have AI Produce Revision Suggestions

按照我们的产品文档,你觉得这个设计图需要怎么调整?
[附:PRD + 当前 UI 截图]

→ Output: A revision checklist.

6.2 Convert Revision Suggestions Back into Coding Prompts

将这些解决方案转换为一个可以直接生成产品的提示词。

6.3 Feedback Loop Iteration:Send this new prompt to Figma Make / Claude → generate again → take another screenshot → review again,loop until satisfied. You can also upload real data and SVG icons to have Claude replace placeholder assets.

Closed Loop:§5 produces the demo → §6 screenshot review and error spotting → return to §5 to regenerate; this is the "iteration flywheel" of the entire workflow. Each loop only requires you to do "screenshot + one sentence of feedback", while the coding AI makes the changes.


7. Step 7: Publish to Run on Phones/Computers

Why:A prototype sitting in the browser can't be experienced by anyone. This step turns it into something tappable on a phone that works like an App, so you can send it to your boss/users for real-device testing.

Running on Desktop:Simply tell Claude "Run this in a real environment, pull data from real scenarios" → AI generates a locally runnable package; if it fails to run,ask with a screenshot + natural language, and Claude will debug while giving you step-by-step run instructions.

Running on Mobile (Netlify Drop Zero-Config Hosting):

  1. Claude generates a runnable HTML file HTML
  2. Open Netlify Drop on your computer app.netlify.com/drop
  3. Drag the HTML file into the webpage
  4. A link is automatically generated in seconds, e.g. https://example.netlify.app https://random-name-123.netlify.app(If you set a password, remember to include it too, e.g. the example password)My-Drop-Site)
  5. Send the link to WeChat on your phone, tap to use immediately
  6. In mobile Safari/Chrome, use Share → Add to Home Screen, an icon appears on your desktop, and it opens and runs just like an App

Real-Life Analogy:Netlify Drop = "Drag your finished web files up there like you're dragging photos, and it instantly gives you a shareable web address". Non-technical PMs don't need to touch servers, domains, or deployment commands.


8. Visual Reskinning: ReferoStyle Renew UI (One-Click Style Change)

Why:After the product logic works, the default styling is often "functional but not good-looking". This step leaves functionality untouched and only changes the skin—take a ready-made design style library and have AI upgrade the overall UI visuals. It's an "icing on the cake" step, decoupled from the main workflow, and can be done at any time.

How to Do It:Grab a set of ReferoStyle extension code from a design style site (e.g. ReferoStyle)styles.refero.design, getdesign.md) → feed it to AI together with your vibe coding HTML:

运行代码,更新优化 UI。
(输入:Vibe Coding 的 HTML + ReferoStyle 扩展代码 + 这句 prompt)

→ Output: A restyled interface.

Real-Life Analogy:After the house is built, swap in a new soft-furnishing style manual and have the renovation team redo everything accordingly—the structure stays the same, but the look is refreshed.


9. Comparison of Variant Methods

The main workflow is Method 1 (Document-Driven → Figma Make). The other two variants share the core of "interrogate first, think clearly first", and differ only in the prototyping tool and level of granularity:

9.1 Method 2 — Document-Driven Direct HTML Output (5-Step Simplified Version)

Compress §1–§7 into 5 steps,3 steps where you converse, 2 steps fully automated by AI:

Step You do AI does
1 Requirement Clarification Be questioned, answer Output requirement summary
2 Information Architecture (IA) Just confirm (can skip for single-page products) Automatically output page list + navigation relationships + core modules for each page
3 Visual Decisions Drop in 1–2 reference images + requirement summary output a Design Brief + Design Tokens DESIGN_BRIEF.md + tokens.css(turn "vibe" into color/font/spacing rules)
4 Code Generation Feed in all documents from the first 3 steps Produce complete runnable code in one go according to the documents
5 Review and Revision Drop in screenshots Output a problem list; you have it fix item by item, then screenshot and review again

Key Prompt Skeleton:

Requirement Clarification:"You are now a requirement interrogator, not an executor. The product I want to build is: [one sentence]. Please ask me follow-up questions until these are clear: target users / core scenarios / functional boundaries (what's included · what's not) / success criteria. After finishing the questions, output a requirement summary."

Information Architecture:"This is the requirement summary: [paste]. Based on this, output an information architecture document: ① Page list (one-sentence purpose for each page) ② Page navigation relationships ③ Core modules for each page (module names only). Output in Markdown."

Visual Decisions (the only step that requires reference images):"[Upload reference image 1 for overall style / reference image 2 for component details (optional)] This is the requirement summary + information architecture: [paste]. ① Extract visual decisions from the reference images: what to borrow (color tone / sense of space / component style), what not to copy verbatim [you fill in], emotional tone [you fill in, e.g. professional · restrained · modern]; ② Based on this, generate Design Tokens: primary/secondary/background/text colors, font size hierarchy, spacing, border radius, shadows. Output a Design Brief + Design Tokens DESIGN_BRIEF.md + tokens.css. ”

Code Generation:"Generate frontend code based on all the following documents: Requirement Summary [paste]/ Information Architecture [paste]/ Design Brief [paste]/ Tokens [paste tokens.css]. Requirements: strictly follow the colors, fonts, and spacing in tokens; implement page structure per the IA;do not invent any modules not present in the documents; output complete runnable code."

Review and Revision:"[Upload screenshot of current UI] Design standards: [paste key sections of DESIGN_BRIEF.md]. Please review: whether visuals match the Brief / whether information hierarchy is clear / whether spacing and alignment are consistent / whether there are obvious accessibility issues. Output a problem list + specific fix for each item."

Why Method 2's "Design Tokens" Are the Essence:They solidify subjective phrases like "I want a professional, restrained feel" into a set of color/font size/spacing variables; every subsequent code generation references the same set of tokens, so visuals are automatically consistent, with no blue on one page and green on another. The finished phonics App deliverable phonics-app-v7.html(a finished phonics App in this section) was built via this exact pipeline.

9.2 Method 3 — GPT + Figma Natural Language UI Building (UI-Heavy Route)

Suitable for scenarios where "you want to directly use finished design systems like iOS 26 Liquid Glass, with a heavy focus on visuals".Prerequisite: Connect GPT to Figma first.

Step Prompt (plain language)
1 Project Brief "I'm building a mobile App that aggregates AI news. First ask me questions, then give me a concise project brief based on my answers."
2 Feature List "Give me a selectable list of features." (Check off the ones you want)
3 Flowchart "Based on these features, create a user flowchart for the complete App in Figma."
4 UI Components "Give me instructions to build the mobile App homepage, using Liquid Glass UI, including all required elements and components." → Remove the prompt header and footer, copy to Figma Make + select iOS26 UI Kit library
5 Page-by-Page Building "Continue making the search page / do the same for search page" (expand page by page)

What Are Method 3's "UI Components/Kit":Package your design system, component library, npm packages, and design specs into "AI-readable context", so Figma Make can automatically produce pages and code according to your company's design specifications. Figma's official Make kits are iterating; refer to the official website for specific configuration.

Pitfall (tested by Will):The Liquid Glass effect generated by Figma Make is often not up to par(the glass effect doesn't kick in), requiring manual re-tweaking back in Figma; details still have flaws you need to fix yourself.AI-generated UI ≠ pixel-perfect, so set expectations for manual final touches.


10. Anti-Pattern Summary

❌ ✅
Taking a one-sentence idea and directly telling AI to "generate the product" First have AI act as an interrogator to force out a Grill Summary, think clearly before you start building
Expecting one tool to go from idea all the way to launch Use the thinking layer (conversational AI) to produce prototypes, then bring in Claude Code when scaling for launch
Directly applying AI-generated PRD as-is Treat the PRD as a first draft,calibrate it item by item against the real product, otherwise deviations get amplified
Letting AI crank out a single interaction plan in a black box Request 3 non-overlapping DRDs and compare horizontally before choosing
Picking out UI issues one by one with the naked eye Feed back screenshots and let AI list "problems + fixes" itself, while you act as judge
Expecting visual consistency without providing reference images Method 2 outputs Design Tokens first Design Tokens, solidifying "vibe" into reusable variables
Thinking a demo from Figma Make is ready to launch demo = interactive demonstration; for real usability you need Claude to produce the program + publish it
Thinking AI-generated UI is pixel-perfect Complex visuals like Liquid Glass often require manual final touches back in Figma
Thinking publishing requires server/deployment knowledge Netlify Drop gives you a link just by dragging an HTML file; add it to the home screen to use as an App

References and Further Reading

Main Sources:sources/reference/will-ai-note/VibeCoding/(Parent intro + 12 step documents: 1 Describe Idea / 2 Requirement Interrogation / 3 PRD + Prompt CN·EN / 4 DRD + Coding Prompts / 5 Figma Make / 6 Feedback Iteration / AI-Driven Design Workflow (Method 2)/ Publish to Mobile / Project Background to UI (Method 3)/ ReferoStyle Reskinning). This section also contains phonics-app-v7.html phonics App finished product (Method 2 output).

Companion Wiki:

History

  • 2026-06-03 v1.0 Created — full_scan of 12 VibeCoding documents + parent intro. Reorganized into one main workflow (Requirement Interrogation→PRD→DRD+Coding Prompts→Figma Make/Claude→Feedback Iteration→Launch→Visual Reskinning) + two variants (Method 2 HTML output / Method 3 GPT+Figma). Each step provides reusable prompt skeletons + Why + Pitfalls. Targeted at non-technical PMs.

Sources and Related Materials