Ideate is the third stage of the UX workflow: after research yields insights and Define locks in the problem, this stage turns insights into "deliverable solutions + defensible decisions". The characteristic of Will’s set of notes is treating AI as an acceleration engine for the ideation phase— not letting AI think for you, but using structured prompts to let AI help you take your existing design judgments and restore them into a complete decision chain + a document you can present to your boss/interviewer.
Significance for PMs: What you can directly take away from this article is seven sets of reusable prompts(three types of decision reports + two parts of competitive analysis + innovative product + user flows + wireframes) and a universal formula for talking about design decisions. It does not solve "how to draw", but "how to use AI to clearly explain 'why I designed it this way', write it into a report, and even turn it into interview talking points". For drawing symbols and hand-drawing methods, see Google UX Certificate / Ideation · Wireframes · Low-Fidelity Prototypes; this article is its "AI acceleration + decision expression" version.
Life analogy: The research phase is like "collecting evidence at a crime scene", the define phase is like "locking in a suspect", and the ideation phase is "writing the case closure report + defending in court" — you already know the answer, but you have to prove you reasoned it out, not guessed it. The soul of all prompts in this article is to force you and AI to complete the "reasoning process" together.
Standard action chain for the ideation phase (original workflow): Define design strategy based on insights → Output information architecture & user flows → Break down features and interaction logic → Produce deliverable design revision documents (DRD) → Build interactive prototypes to validate critical paths.
1. First, understand: Design strategy vs. design solution (why you cannot skip strategy)
Many people (especially PMs) will ask: Once you have insights, why not just generate several solutions and run A/B tests live? Why must you define a "strategy" first?
Three-layer relationship(memorize this; it is the cognitive foundation of the ideation phase):
| Layer | What it answers | Example |
|---|---|---|
| Insight | What the problem is + why it happens | Users do not convert because they do not trust the product |
| Strategy | Which solution path to choose, which to abandon | Among "add reviews/add certifications/reduce risk/strengthen brand/optimize information structure", select only one primary path |
| Solution | Specific UI/interaction/feature implementation | Under the selected "social proof" path, build three versions of the reviews module |
Why strategy is mandatory: For the same insight, different business goals lead to completely opposite solutions.
- Insight: Users are uncertain about purchase outcomes → hesitate/abandon.
- Business goal =increase conversion rate → Strategy "reduce decision uncertainty so users dare to place orders" → strengthen reviews, before/after comparisons, and 7-day refunds.
- Business goal =increase average order value → Strategy "build perceived value so users feel the higher price is worth it" → emphasize differentiation, premium scenarios, package upgrades.
- Business goal =increase repurchase/brand trust → Strategy "build long-term trusted relationships" → reduce marketing copy, real user stories, transparent information.
Without strategy, solutions will "diverge and pile up": pages become more and more complex (trying to add everything), each point looks correct on its own but the whole does not work, and the team gets stuck in arguments (everyone can make a point that sounds right).
Three functions of strategy:Convergence (select one primary path from multiple solutions),Trade-off (clarify what to do + what not to do),Alignment (get the team aligned across the three dimensions of "insights, business goals, solution paths").
Professional expression formula for strategy(used when writing strategy statements / explaining direction to your boss):
通过【手段/机制】,改变【用户的某种状态/行为】,从而达到【某种效果】。Example: By strengthening social proof, reduce user uncertainty, thereby driving decision conversion. Example: By restructuring information hierarchy, reduce user comprehension cost, thereby improving decision efficiency.
When strategy can be de-emphasized: Small projects/simple problems (such as optimizing a single button’s click rate) can go straight to solutions.Complex problems, growth problems, and multi-solution problems must have a strategy. Judgment signal: When you have "multiple solutions that all look correct", what you lack is not solutions, but strategy.
2. Three types of project decision reports (highest reuse value in this article)
This is the core asset of the entire set of notes.The work problem it solves: When you finish a design and need to report / write a retrospective / talk about the project in an interview, how to use AI to take the outcome "I built B"and reverse-engineer it into a complete decision chain— so people see you are making judgments, not executing others’ decisions.
2.0 Why it is needed: The "four-step formula" for judgment ability
When an interviewer asks "where are the design details", they are essentially asking:Are you executing others’ decisions, or making your own judgments? Missing any step makes you sound like you are talking about features rather than design:
我面对的选择 → 我的判断标准 → 我选了什么、放弃了什么 → 结果验证
Why this set of reports is valuable: 90% of people talk about projects by jumping straight to "I changed A to B, and the metric went up by X%". After listening, people only know the result, not your judgment ability. The common skeleton of these three templates forces you to complete "attribution → lock direction → candidate solution comparison (including rejected ones) → decision table → expression", making implicit judgments explicit.This is precisely the value design leaders exist to provide on a team.
Three types of projects correspond to three "decision starting points"; choosing the wrong template will skew your narrative:
| Type | Typical scenario | Decision chain starting point |
|---|---|---|
| ① Multi-version optimization type | Low conversion/high churn, data-driven revision | Attribution (find the real cause among several hypotheses) |
| ② MVP type (0→1) | Product has defined features; the designer decides how to present them | Design contradiction (where first-time users get stuck) |
| ③ Exploratory innovation type | AI features/new paradigms with no precedent | Challenge common industry assumptions |
2.1 Case 1: Multi-version optimization type decision report (data-driven)
Complete four-step chain(a set of 4-segment prompts, fed in step by step):
Step 1 — Generate the main body of the decision report. Input: Before/After screenshots + custom text; Output: attribution analysis + solution comparison + decision table + PPT content.
Reusable prompt skeleton (Step 1): My input materials: business goal (one sentence) / old version solution description (what it was like before, what problems it had) / optimized final solution description (what I did) / supplementary information (data or user feedback, competitor references). Please output strictly in the following order, do not rearrange: ① Attribution stage — List 2–3 attribution hypotheses (A/B/C); use reasoning to explain which is most likely the real cause and why the others do not hold;ultimately retain only one hypothesis as the premise for all subsequent solutions. ② Solution comparison stage — Premise: Based on the only hypothesis locked in the previous step, the direction is set, and the following solutions all solve the same problem in the same direction. Based on my final solution,reverse-engineer 2 other candidate solutions of the same category(differences can be in interaction method/information architecture/visual weight/layout), but all three must solve the same problem. Format: Solution A/B (description/pros/cons), Solution C final choice (description/core reason for choosing it). ③ Decision reconstruction table — Output a table:
成立的归因假设 | 验证方式 | 锁定的设计方向 | 候选 A 及淘汰原因 | 候选 B 及淘汰原因 | 最终 C 的选择依据. ④ PPT written expression — Divide into 5 pages, each page with "page title / core point (one sentence) / page content (3–5 bullets)", five pages = problem definition / attribution and validation / candidate solution comparison / final solution explanation / results and reflection.
Why "reverse-engineering rejected solutions" is the essence: You ultimately only built one solution, but judgment is precisely reflected in what you "gave up, and why you gave it up". Letting AI help you fill in the candidate solutions (even those you did not seriously think about at the time) and write clear rejection reasons turns your decision from "a result" into "a trade-off".
Step 2 — Convert to interview talking points. Input: Step 1 text + prompt; Output: 800–1000 Chinese characters of colloquial interview talking points.
Reusable prompt skeleton (Step 2): The above is my design decision content, please generate interview talking points. Output in five parts in order, and do not significantly compress any part: ① Background and challenge (must embed a small subplot of "external pressure/others’ opinions"— for example, the product directly tells you how to do it, or a stakeholder has a seemingly reasonable judgment that you think is inaccurate; show that you did not accept it directly, but made your own judgment first) ② Attribution process (several hypotheses, how you validated them, which ones you ruled out, what the real cause was — cannot be omitted) ③ Solution trade-offs (length no less than 1/3 of the full text, each rejected solution must be specific to user behavior or design logic, cannot just say "the effect was not good") ④ Result validation (launch results;proactively mention where your judgment was wrong + how you corrected it; if there is no precise data, talk about qualitative feedback) ⑤ One-sentence closing (point out the inspiration this project gave you for design judgment, be specific). Tone should be colloquial, like a real person talking, not reciting a script; show judgment, made choices, explain why clearly; neither arrogant nor overly modest.
Why embed the "external pressure subplot" + "proactively admit mistakes": The former creates conflict, proving you make independent judgments rather than following the crowd; the latter (proactively talking about where your judgment was wrong) instead makes you seem authentic and reflective, more credible than being perfect the whole time. These two points are the key to turning talking points from "scripted" to "real-person".
Step 3 — Refine a single solution:将这个方案在交互和视觉层面更加细化 / Refine this solution further in terms of interaction and visual design.(Note: Select only one optimization solution to refine each time; do not copy all the text).
Step 4 — Generate multi-version designs: Input Step 3 content + screenshot of the interface being optimized, output multi-version design solutions (expand the single new solution to include versions discarded during the process, to express the decision-making power behind it).
Complete example (Case 1 empirical evidence · Food delivery app scheduled pickup): Business goal = increase scheduled order success rate; phenomenon = conversion for selecting "Later" is 18% lower than "ASAP". Three attribution hypotheses: A Unclear pickup time → hesitation / B Unclear understanding of pickup method / C Distrust of order or price. Used event tracking (32% longer dwell after selecting Later, repeated switching between ASAP↔Later without paying) + interviews ("I don’t know exactly what time I can pick it up when I select a time") to lock in A. Three solutions: A Popup confirmation (strong but interrupts high-frequency flow, too heavy) / B Auxiliary copy (light but weak, does not solve "exactly what time") / C Result as state (after selecting Later, the button directly displays
Today · 09:00 PM, CTA changes toPlace Scheduled Order, module highlighted)— core judgment: "Users don’t need to be explained, they need to see the result", turning implicit states into explicit results with zero operation cost. After launch, Later conversion +12%, post-time-selection churn -20%; where judgment was wrong: initially some users thought the time was automatically assigned by the system, later fixed by adding a highlighted selected state. One-sentence closing: "Many conversion problems are essentially not about insufficient information, but about results not being sufficiently 'seen'."
2.2 Case 2: MVP type decision report (0→1)
Key difference: In MVP projects,product managers decide what to build, UX designers decide how to present it. Therefore, the prompt’s important premise is "I am a designer, not a PM; this does not involve feature trade-offs/requirement prioritization/business decisions", all judgments focus on four design domains: ① First-use onboarding ② Interaction and information architecture of core task flows ③ Handling of empty states/error states/boundary states ④ Visual hierarchy/navigation model/presentation approach.
Reusable Prompt Skeleton (Case 2): I have an MVP project from a UX designer's perspective. Please help me reconstruct the design decision-making process.Prerequisite: I am a UX designer, not a PM; do not cover feature trade-offs, requirement prioritization, or business decisions, all comparisons focus on the four areas above. Input materials: What the product is (one sentence) / Confirmed feature scope (set by the product side, I do not judge this) / The core design problem I face (at which critical moment users get stuck or churn) / My final solution / Supplements (test feedback, competitors). Output in order:① Design contradiction definition(focus on the user experience layer, cannot be at the feature or business layer) → ② Solution comparison(reverse-engineer 2 similar candidates based on the final solution; differences can only be in onboarding method/information presentation/interaction path/visual hierarchy; format: A/B description + advantages + elimination reason, C description + core rationale) → ③ Decision reconstruction table(
核心设计矛盾 | 设计方向 | 候选 A 及淘汰原因 | 候选 B 及淘汰原因 | 最终 C 的选择依据 | 上线后判断验证)→ ④ 5-page PPT(design contradiction definition / direction establishment / candidate comparison / final solution / launch validation and iteration).(Steps 2-4 convert to scripts/refine/generate multiple versions, reuse the prompts from Case 1.)
Why MVP must first lock in "I am a designer": 0→1 projects most easily cause designers to unconsciously frame the story as "which features we cut" — that is the PM's job; talking about it instead exposes that you are overstepping and lack design depth. After locking the boundary, your judgment will focus on "where users get stuck during cold start, and how to keep them from churning" such pure experience problems.
Example Key Points (Case 2 Empirical Evidence · Cold Start Tool): The product has finalized search/category/detail pages; the designer's core contradiction = "When users open it for the first time and see nothing, why should they believe it is worth using" (cold-start trust problem, not a feature problem). Three solutions: A Trending search terms (no data at cold start → displaying fake data undermines trust) / B Recommended content cards (users treat it as a homepage to browse, deviating from the behavior path) / C Search box placeholder text with real examples(such as "Try searching: quarterly reimbursement process") — core judgment: what users want is not content recommendations, but cognitive calibration of "oh, this is how you use it", with the lowest cost and most accurate information. Post-launch misjudgment: assumed users read the result list from top to bottom, but in reality they only stared at the first result; if the first result was wrong they searched again → version 2 added keyword correction guidance below the first result.
2.3 Case 3: Exploratory Innovation Decision Report
Key difference: The most common mistake in innovation projects is talking about technical implementation/feature innovation,ignoring user mental models. Interviewers want to know: On what basis do you believe users will accept this innovation? Therefore the starting point of the decision chain is challenging the industry's shared assumptions.
Reusable Prompt Skeleton (Case 3): I have a UX exploratory innovation project. Please help me reconstruct the design decision-making process. Input materials: What problem this feature solves (one sentence) / How existing industry solutions do it (competitors or conventional practice) / My final solution (how it differs from existing solutions) / Supplements (user research/testing, data validation). Output in order:① Assumption challenge phase(What is the shared assumption behind existing industry solutions → For which types of users/in which scenarios does this assumption not hold → State my different judgment in one sentence) → ② Solution comparison(reverse-engineer 2 similar candidates based on the final solution, A/B description + advantages + elimination reason, C description + core rationale) → ③ Decision reconstruction table(
行业共同假设 | 我的不同判断 | 与竞品的本质差异 | 候选 A 及淘汰原因 | 候选 B 及淘汰原因 | 最终 C 的选择依据)→ ④ 5-page PPT(limitations of existing industry solutions / my different judgment and basis / candidate comparison / final solution / validation results and reflection).
Why focus on "industry shared assumptions": Innovation is not "competitors don't have this feature so I'll add it", but "the industry all defaults to X, but I found X is wrong for a certain group of users". That is an innovation narrative that demonstrates judgment.
Example Key Points (Case 3 Empirical Evidence · AI Calendar): Industry shared assumption = "Users' biggest pain point is the hassle of filling in" → everyone builds "AI automatically fills it in for you". Counterintuitive data: After seeing the AI-filled calendar, 62% of users' first action is not to confirm but to check word by word ("I don't trust what it filled in; I absolutely can't let it schedule the wrong meeting"). Different judgment:The real pain point is not "filling is a hassle" but "no one is responsible if it's filled wrong"; efficiency and sense of control conflict, and users would rather be slow to be the person in charge. Essential difference: Competitors position AI as "the person who makes decisions for you", while I position it as "the person who helps prepare options for you" — AI lists all available attendees/meeting rooms and marks conflict risks, and the user makes the final judgment. Validation: Two rounds of usability testing, the version with "conflict risk marking" had a +23% calendar creation completion rate.
2.4 Universal Structure (Applicable to Any Project Type)
Find the decision in your project that is most different from competitors/conventional practice, and ask yourself three questions: Why didn't I do the same as everyone else? On what basis do I think my direction is right? What did the results validate? When talking about any design decision, you can apply these five steps:
① 我面对的是什么选择(描述决策处境,不是描述功能)
② 我有哪些选项(至少两个)
③ 我用什么标准做判断(这是你设计价值观的体现)
④ 我选了哪个、否掉了哪个、为什么
⑤ 结果证明了什么(哪怕只是定性的用户反馈)
III. AI Competitive Research Analysis Report (Variable Validation Method)
The work it solves: When doing competitive analysis, you can never get your competitors' real conversion data, so how do you make a judgment that is "close to objective"? Will's answer:Do not judge "whether the result is good", only judge "variables".
3.1 Cognition: How to Screen Competitors + How to Judge Even Without Data
Two hard criteria for screening competitors: Competitors are not "anyone you can look at"; they must simultaneously satisfy "same decision problem + observable signals”.
- Lock the decision problem first: What decision is the user making? (Whether to pay? Whether to upload an avatar? Whether to start using?) Only the same decision problem has reference value.
- Only select competitors with external signals(5 approaches): ① Market signals(App Store rankings/downloads, funding/user scale, industry Top 3-5 — those that survived and grew large are at least not wrong) ② Behavior signals(default selection of a certain plan, highlighting a certain CTA, repeatedly reinforcing certain information — what they push hard must be a key variable affecting conversion) ③ Consistency signals(3+ products using the same structure = repeatedly validated) ④ Feedback signals(App Store reviews, Reddit/community complaints = real experience) ⑤ Pseudo-iteration inference(find the two competitors with the largest differences → judge which is more mature → infer the industry evolution direction; for example, "small products are simple, large products are complex" indicates the industry is moving from "simple display" to "enhancing persuasiveness").
Variable validation method(core, three steps): ① Decompose variables(do not look at the page as a whole; decompose the payment page into: presence/absence of plan comparison/recommended option/free trial/social proof… each is a variable) ② Count frequency(look at 10 competitors, plan comparison 9/10, recommended option 8/10…) ③ Draw probability-level conclusions(do not say it is "good", but say "this variable is highly likely to be effective”).
How to judge "whether it fits us"(do not guess competitors' users/prices; use structure matching method, only look at 3 judgeable variables): ① Decision cost(high price = rational decision / low price = impulsive decision) ② Information density(high for SaaS = users need to understand / low for entertainment = users need to feel) ③ Risk level(refundable or not / long-term binding or not → whether users will hesitate). Conclusion: You don't need to know their data, you only need to judge "whether they are solving the same type of decision structure”.
Why the variable method works: You cannot know competitors' A/B test results, but the fact that "9/10 top products all include plan comparison" is a frequency fact that is objective — it is equivalent to "the entire industry has run A/B tests for you with real money". This is the closest-to-objective evidence you can get in a data-free environment. Tools for finding competitor pages: Mobbin (mobbin.com), PageFlows (pageflows.com) archive a large number of real product screenshots/flows.
3.2 Two-Stage Prompts (Practical Operation)
First Stage — Let AI Recommend Competitors + Give Screenshot Guidance:
You are a senior product design researcher, skilled in competitive analysis. My product background is as follows: [paste product name/target users/what users use it for/what effect they can achieve + the page for this analysis/the core task of that page/core business metrics]. Please recommend 3-5 competitors worth referencing; the screening criteria must simultaneously satisfy: ① They face the same type of decision problem (same page, same decision scenario) ② They have observable external signals (App Store rankings/downloads, funding/user scale, industry leaders, or obvious industry consistency). For each competitor output: product name + one-sentence introduction / reason for selection(cite specific objective data or signals, do not just say "good user reputation") / decision structure match / screenshot guidance(tell me which specific page to find on it, and which key information must appear in the screenshot). Finally, uniformly inform: Combine all competitor page screenshots into one image, annotate the product name next to each, and send it to me.
Second Stage — Feed the Collage to AI for In-Depth Analysis:
This is the competitor screenshot collage I organized, containing [5] products, and the corresponding page is [subscription page]. Conduct an in-depth analysis combined with the following framework:① Decompose variables(decompose all observable design variables for this page type, such as: presence/absence of plan comparison/recommended option/free trial/social proof/price anchor/CTA copy type/information density…)② Variable frequency statistics(number of occurrences + frequency of each variable across [X] competitors, give "probability-level conclusions"; output a table
设计变量 | 出现次数 | 出现频率 | 概率级结论)③ Per-competitor evaluation(combined with my core metrics, for each competitor state 2-3 points done well + 1-2 points done poorly, all with reasons tied to variables)④ Design decision basis table(设计点 | 竞品证据 | 变量频率 | 结论 | 是否建议采用)⑤ Comprehensive conclusion(3-5 sentences: which product is best overall and why / 2-3 core decisions most worth referencing / whether there are points worth differentiated breakthroughs — areas competitors generally did not do well).
The only standard output for competitive analysis = design decision basis table. One-line example:
套餐对比 | 9 个产品都有 | 90% | 高概率降低决策成本 | 是.
Professional phrasing for talking about competitive analysis(for interviews/presentations, frame the variable method as a piece of logic):
The core of this module is to solve [user decision problem]. Therefore when selecting competitors I prioritized products with [same decision scenario + market validation signals], specifically selecting [Competitor A/B], because they are consistent with us in [subscription revenue as core / DAU scale / industry leadership]. Before analysis I first decomposed the page into three structures: [explanation/decision/action], because our problem occurs at [a certain stage, e.g., users hesitate at the "decision" stage], so I focused analysis on [the corresponding structure]. Within this structure I only focused on one variable: [variable name]. I counted [N] similar competitors, among which [X] used this variable and structurally reinforced it through [reinforcement method]. Based on this proportion, I judge it is a highly likely effective design variable, essentially solving [core user resistance]. Therefore in our solution I chose [whether to adopt it], using [specific design action] to influence [business result].
Example (empirical evidence): Solve "hesitation at the last step before payment" → screen Duolingo/Headspace/Calm which are "high-frequency + low payment threshold + strongly conversion-dependent" → decompose into three structures "information presentation/decision reinforcement/action trigger" → focus on one variable in "action trigger": "risk buffer zone before CTA" → 5 out of 7 products inserted a "low-risk commitment" (free trial/cancel anytime/refund explanation) before the CTA and placed it tightly adjacent to the CTA → judge "risk buffer zone" is highly likely effective, essentially solving loss aversion → the solution does not add information, but inserts a clear risk commitment before the CTA and binds it to the main action.
IV. Generate Innovative Products Based on Requirement Scenarios (Vibe Coding Entry Point)
The work it solves: You only have a "one-sentence requirement" (who/where/what pain point), and want to quickly generate a founder-level product description document, then feed it to tools like Figma Make to directly generate clickable interfaces.
Four-step workflow: ① Use prompts to turn the one sentence into a product description document → ② AI generates product design → ③ Add detailed explanations of 3 industry-differentiated features and interactions → ④ Select one of the results and feed it to Figma Make to generate the interface.
Reusable Prompt Skeleton (Step 1 · Peter Thiel-style PRD): You are a Peter Thiel-style product thinker + AI Native system architect, skilled at designing products that counteract system entropy starting from contrarian positions. The goal is not to produce a feature list, but to define a new product paradigm (Category Design). I will provide only one sentence (including usage scenario Who/Where + core pain point Why). Please output a PRD-level document usable for fundraising, team alignment, and product design,strictly following 8 sections with no deletions allowed: ① Core Vision (one sharp Contrarian Truth + identification of where mainstream solutions are wrong / why the problem has remained unsolved at the system level + one core metaphor "not X but Y") ② Target Users (initial entry group The Wedge + work style/tool preferences/emotional aversions + why the need is urgent now) ③ Product Philosophy (3–4 principles, not features, that can constrain product form long-term and clarify what role AI plays rather than just "adding AI") ④ Evolution Roadmap (Phase 1 Structure/Order → Phase 2 Capability Fill-in → Phase 3 Autopilot/Decision-making; each phase includes core tasks / root pain points / representative capabilities) ⑤ Feature and Interaction Details (overall UI/interaction paradigm rather than component stacking; how users naturally use the product + how the AI backend takes over complexity; at least 1 usage flow example Input→AI Judgment→System Behavior) ⑥ Technical Architecture (system-level perspective: local vs. cloud responsibilities / AI's fast-brain and slow-brain mechanisms / why this architecture is a moat) ⑦ Commercialization and Moats (at least 3 irreplicable moats + why users will find it hard to leave once they start using it + one Pitch-level value proposition) ⑧ Immediate Next Step (what the MVP should NOT do + the single core hypothesis to validate immediately + a realistic Dogfooding path). Style: restrained, rational, ambitious, like a founder writing to top-tier investors; avoid marketing jargon, empty visions, and feature lists;all content must be deduced from that single sentence, with no scenario-detached speculation. One-sentence input: [College students studying in an unfamiliar city, looking for local alumni who share the same interests].
Step 3 Additional Prompt: Based on the above understanding of the product, please additionally output 3 detailed feature and interaction items that are industry-differentiated and aligned with the product's core goals.
Why Use "Peter Thiel Style + 8-Section Structure": Ordinary prompts cause AI to spit out a pile of mediocre feature lists. This role setting forces AI to start from "contrarian judgment + paradigm definition," producing a document with a strategic skeleton and moat reasoning rather than a feature hodgepodge. For PMs, it is a shortcut to quickly compress vague inspiration into a first draft that "can align the team / can be pitched to investors"—but you must review the contrarian judgment and moat yourself; AI tends to overstate claims.
V. Optimizing Solutions Through Usability Testing (5-Step Chain)
Work It Solves: Takes "an old interface" all the way through an AI-powered chain of "usability test report → quantitative data table → interaction dashboard → redesign prompt → new version interface”.
5 steps:
- Generate Usability Test Report: Input a screenshot of the old single page + prompt, output a complete test plan covering 9 links: "research objectives → tool selection → task script → recruitment → observation mechanism → formal testing → retrospective → data synthesis → conclusion and recommendations," with each link marked with deliverable outputs(such as research objective list, test script, evidence library, priority roadmap).
- Quantitative Data Table:
create a data table to present the quantitative results of this test(completion rate, time spent, error type distribution, etc.). - Interaction Dashboard:
based on the data table above, generate an interactive data interface dashboard. - Redesign Prompt:
根据本次用户测试的结果,为每个问题提炼核心 UX 洞察,结合原始 UI 给出详细改版方案说明,无需拆解分析,直接给用于指导修改行为的结果. - Generate New Version Interface: Feed the redesign description from Step 4 into the generation tool to obtain the optimized interface.
Reusable Prompt Skeleton (Step 1): As a professional UX designer and user researcher, conduct in-depth analysis based on product screenshots, and from a professional perspective for usability testing plan three core tasks for usability testing, recruit target users for testing and interviews to identify root problems and extract UX insights. Please develop a complete usability test plan, and output specific results for each step in this format:Provide a directly reusable implementation process, and explain what deliverables will be produced in the end——① Clarify research objectives and key questions (e.g., "Can users complete a transfer within 5 minutes?") ② Select remote tools and device strategy (Zoom/Lookback, etc., verify compatibility) ③ Design task scenarios and test scripts (close to daily situations + starting page/success criteria/duration + moderator scripts and follow-up questions) ④ Recruit participants + technical practice ⑤ Set up observation mechanisms and communication channels (auditing rules + internal observer channel) ⑥ Formal testing (consent forms/screen sharing/issue tasks one by one/record time, errors, and stalls) ⑦ End each session + immediate retrospective ⑧ Organize data and synthesize insights (classify by fatal/severe/moderate/minor issues + mark evidence: who/timestamp/screenshot) ⑨ Form conclusions and design recommendations (pair each problem with actionable suggestions + priority).
Why Let AI Write a "Process with Deliverable Outputs": Usability testing most easily devolves into "watching recordings and making gut calls." Forcing each step to specify "what deliverables are produced (evidence library/data table/roadmap)" is equivalent to forcing AI to help you turn testing into traceable, reviewable assets rather than a pile of scattered observations. Related Note: Usability testing methodology itself (5±2 users, guided questioning, severity grading) is the work of UX research; this section only covers the part of "using AI to run it as a report chain."
VI. Generate New Version Interaction Document (DRD Redesign)
Work It Solves: Given a screenshot of an old interface/old flow + problem description, have AI produce in one go at least 3 clearly differentiated interaction redesign schemes, and organize them into a reviewable DRD (Design Requirement Document) redesign document.
Reusable Prompt Skeleton: You are a senior product manager + interaction design expert + UX strategy consultant, skilled at proposing redesign schemes starting from "problem—cause—business impact" and organizing them into implementable DRDs. I provide two types of input: interface (single page or flow screenshot) + problem (description/specific manifestations/affected business metrics/cause explanation). For each problem, output at least 3 specific, executable, clearly differentiated interaction redesign schemes.Judgment Framework(used as underlying criteria, not as output headings): Usable / Equitable / Enjoyable / Useful. Output structure:1. Problem Definition(location/how it occurs/why it affects business goals/which metric it currently impacts)2. Redesign Schemes (≥3 per problem)——each scheme includes scheme name + one-sentence core direction + core rationale + specific redesign design (cover as much as possible: information architecture adjustments/interaction paths/operation order/visual weight/information hierarchy/proportion and scale/consistency and diversity/key button module state feedback; supplement copy guidance, default values, confirmation mechanisms, and risk warnings where necessary); clearly state the most obvious differences before and after the redesign(what was seen before the change/what change is perceived first after the change/which paths are shortened, strengthened, or weakened); why this scheme is better (both experience and business layers); impact on business metrics (conversion rate/click-through rate/completion rate/bounce rate/return visit rate, etc. + through what mechanism it affects them).3. Comparative Summary of the Three Schemes(applicable scenarios/scope of change/risk level/benefit direction/suitable for quick launch or medium-to-long term).4. DRD Document(redesign background/redesign objectives/design strategy/detailed redesign instructions written node by node as "what to change + why change it + user perception change + effect on business"/risks and validation suggestions including A/B testing or funnel comparison). Requirements:Must combine screenshots and problem analysis and cannot talk in the abstract detached from the interface; speak in plain language; do not just say "the experience is better"—explain clearly why it is better; do not just give "optimization suggestions"—present them as executable design schemes; schemes must have obvious differences and cannot be minor variants of the same idea. For multi-page flows, analyze from a flow perspective; for single pages, focus on analyzing in-page information structure/visual priority/operation logic/key behavior guidance.
Why Mandate "≥3 Schemes with Clear Differences" + "Usable/Equitable/Enjoyable/Useful as Underlying Criteria": To prevent AI from giving three variants that are the same thing with different labels; setting the four "good experience" standards as a measuring stick rather than output headings gives AI's schemes a quality anchor without degenerating into template-filling. The output is directly a DRD, saving you the step of translating "AI suggestions" into "documents developers can read."
VII. Using AI to Generate User Flow Diagrams & Wireframes
The symbol systems, hand-drawing methods, and IA principles for this section have already been detailed in Google UX Certificate / Ideation · Wireframes · Low-Fidelity Prototypes (circle = action/rectangle = page/diamond = decision/arrow = flow direction; industry wireframing methods; Dan Brown's 8 principles; Gestalt principles). Here we only supplement the prompts and workflows for "automatic generation using AI + PRD", as well as the understanding of "the respective value of flow diagrams/wireframes" in the ideation phase.
7.1 Flow Diagrams vs. Wireframes: What Each Covers
| Type | Problem It Solves | Essence |
|---|---|---|
| User Flow Diagram (Flow) | How does the user proceed? Is the path correct? | Behavioral Logic |
| Wireframe | How does the page carry it? Is the structure correct? | Information Structure |
Value of User Flow Diagrams:① Prevent wrong order/breakpoints/dead ends——for example, in an order flow, if you do the UI first and then discover "login is required only after the address is filled in," users who have already invested effort are interrupted and likely to abandon; drawing the Flow first lets you see at a glance that "login placed later = wrong order" (correct: homepage → product page → login → fill address → payment). ② Prevent missing states——what if it fails? What if there is no permission? What if data is empty? A flow diagram forces you to think through all situations.
Value of Wireframes:① Diverge on multiple page schemes at the lowest cost——for the same booking page, you can quickly draw and compare three structures: "information-first/button-first/step-by-step guidance," and overturn them; if you go straight to UI, you will almost always make only one version and find it hard to overturn. ② Discover "unclear priorities" early——without visual distraction, looking only at structure makes it easy to spot that "the most important booking button is buried far below." ③ Discover "chaotic page structure" early——doing UI directly for a data dashboard tends to pile everything into a mess; the wireframe stage forces you to do information grouping and module division, turning "piled content" into "structured information."
7.2 Prompt: PRD → User Flow Diagram (Figma-Convertible)
Workflow: ① Connect GPT to Figma → ② Feed PRD + prompt to generate flow text → ③ Copy the path text, generate the diagram in the Figma App, then manually edit it a second time.
Reusable Prompt Skeleton: You are a senior UX designer, and your task is to generate a professional user flow diagram based on a PRD that can be directly reproduced in Figma. I will provide a PRD. Based on it, generate a complete user flow (from entering the product to completing the task). Requirements:① Flow Structure——Cover the core Happy Path; if mentioned in the PRD, include boundary/error paths; logic must be complete and coherent.② Node Types (strictly follow, only 4 types allowed):
(圆形)= user action (e.g., "click upload button"),[矩形]= page/interface (e.g., "profile page"),<菱形>= decision node (e.g., "Is the file valid?"),→= flow direction.③ Output Format (Figma-usable structure): Use structured text for direct conversion to nodes, for example(圆形)打开应用 → [矩形]首页 → (圆形)点击上传头像 → [矩形]上传弹窗 → (圆形)选择图片 → <菱形>文件是否有效? 是→(圆形)确认上传→[矩形]上传中→<菱形>上传是否成功? 是→[矩形]更新后的个人资料页→(End) 否→[矩形]错误提示→(圆形)重新上传. ④ Quality Standards: Clear (unambiguous)/Concise (no redundancy)/Complete (no broken paths)/User-behavior-centered (focus on user actions rather than system logic).⑤ Supplements: Group when necessary; keep copy to 3–6 words; prioritize clarity of decision nodes; if the PRD is incomplete, make reasonable inferences according to best practices. Now process the following PRD: [Paste PRD].
Why Fix Node Syntax to 4 Types + Structured Text Output: This way, what AI outputs is not a piece of prose, but a structure machine-parseable and directly feedable into Figma nodes. Constraining it to be "user-behavior-centered rather than system-logic-centered" prevents AI from drawing engineering sequence diagrams (which are for developers, not user flows).
7.3 Professional Phrasing for Discussing Flow Diagrams/Wireframes
Discussing flow diagram rearrangement:I first fully mapped out the entire critical path and all main branches, and found that the problem does not lie on any single page, but in [issues at specific user decision nodes / system state transitions]. The original flow placed [a certain judgment / feedback / permission / state transition / confirmation action] at [an inappropriate position], which prevented users from continuing to make judgments, caused repeated operations, or led to misunderstanding of the system state during [a certain stage]. Therefore, I rearranged [the order of key nodes / decision branches / state feedback mechanisms], moved [certain conditions / restrictions / result feedback] earlier or made them explicit, so that users know what state they are in at every node and what to do next. (Empirical example: Corporate reimbursement process — the original flow only displayed "Submitted" after submission, but in reality there were three subsequent stages: budget verification, supervisor approval, and finance review; failure at any stage would result in a return. Users mistakenly thought "successful submission = process completed", and felt the system was inconsistent when their submission was returned. Revision: Fully supplemented the approval chain, return reasons, and status feedback for each stage, and changed "Submission successful" to "Entered approval process".)
Discussing wireframe divergence:I created [N] different information organization approaches using wireframes, and compared user comprehension and decision paths under different structures. After comparison, I found that the problems with the current solution are [unclear information priority / missing key judgment information / conflicting module relationships / users having to compare back and forth across multiple areas]. Therefore, I adjusted [information grouping / judgment order / action entry positions / content splitting or merging], so that users [complete judgments first after entering, then perform operations, without needing to switch back and forth]. (Empirical example: Risk dashboard — comparing three structures: "by timeline", "by risk level", and "by handling action", it was found that when judging "whether to handle immediately", users had to switch back and forth between trends, causes, and impact scope, resulting in high judgment cost; the revision consolidated the key information required for judgment to the same layer and reordered it, allowing users to complete risk judgment first before viewing details.)
VIII. Reference Asset Library: Infographics / Diagrams / Graphics
There is a pure image asset area in the source materials (90+ sample infographics/diagrams/graphics, no text descriptions), which is not a methodology, but a visual inspiration reference library (moodboard)— it collects layout styles of various infographics, diagrams, and data graphics, for you to find layout references when you need to visualize decision reports / competitive analyses / usability test results visualize.
Why a separate section:The outputs from earlier sections of this article are all "text + table" reports, but during actual presentations they often need to be turned into visually impactful infographics. The purpose of this asset area is "when you need to draw conclusions into graphics, come here to browse styles." The images are gitignored per KB rules and are not embedded in the main text; when needed, go to the source directory
sources/reference/will-ai-note/C - Ideate/Info,Diagram, Graphic/to browse, or use Google UX Certificate / Ideation · Wireframes · Low-Fidelity Prototypes wireframe/IA knowledge to build the structure yourself.
Key Prompt Cheat Sheet
| Work Task | Prompt Trigger Key | Output | Section |
|---|---|---|---|
| Multi-version optimized decision report | Attribution (keep 1 out of 2–3 hypotheses) → reverse-derive 2 candidates → decision table → 5-page PPT | Decision report + interview talking points | §2.1 |
| MVP decision report | "I am a designer, not a PM" + design contradiction → candidate comparison → decision table | Decision report | §2.2 |
| Exploratory innovation decision report | Challenge common industry assumptions → my different judgment → essential difference | Decision report | §2.3 |
| Competitive analysis (select competitors) | Same decision problem + observable signals, cite objective data, provide screenshot guidance | Competitor list | §3.2 |
| Competitive analysis (examine the puzzle) | Decompose variables → frequency statistics → probability-level conclusions → decision basis table | Analysis report | §3.2 |
| Generate innovative product | Peter Thiel style + 8-section PRD, derived from one sentence | Founder-level PRD | §IV |
| Usability testing chain | Test plan (with outcome documentation) → data table → dashboard → revision prompt | Report chain | §V |
| Interaction document revision | ≥3 distinct schemes + use Usable/Equitable/Enjoyable/Useful as criteria → DRD | DRD | §VI |
| PRD → User flow diagram | 4 node types (circle/rectangle/diamond/arrow) + structured text convertible to Figma | Flow text | §7.2 |
EN prompts:Each set of prompt source materials includes an English version, with logic fully corresponding to the Chinese version (consistent node syntax and output structure); when working on English projects or English interviews, directly retrieve the English version from the source directory
Prompt EN.
and Google UX Certificate / Ideation · Wireframes · Low-Fidelity Prototypes division of labor (to avoid duplication)
| Dimension | This article (ai-ux-ideate) | google-ux-wireframe-prototype |
|---|---|---|
| Perspective | AI acceleration + decision expression | Manual design language + course fundamentals |
| Flow diagrams | AI prompts for PRD→flow diagram + value recognition | 4 shape symbols + hand-drawing method |
| Wireframes | Value of "diverging multiple structures" + revised DRD | Fidelity + industry drawing methods + reverse-derivation exercises |
| Competitors | Variable validation method + AI two-stage prompt | 5-step basics of competitor research |
| Unique content | Three types of decision reports / judgment formula / design strategy / innovative product PRD / interview talking points | 8 IA principles / storyboards / Gestalt / Figma basics / low-fidelity prototype connections |
<!-- The Info, Diagram, Graphic area contains 90+ pure image assets (no text), which is described as a visual reference library per §VIII, with no hardcoded content. The Prompt EN and Prompt CN for each Case correspond logically one-to-one, as noted in the cheat sheet; sentence-by-sentence translation is omitted to avoid duplicating the original text. -->