Present the first phase of Will’s "AI-Assisted UX Workflow" Discover & Research into a "prompts + workflow" handbook. This phase answers four questions: What are the business context and user scenarios (Context & Scenario), what are the business goals and user tasks (Business Goal & User Task), what problems exist with the interface from the user’s perspective (UI Symptoms), and what design challenge needs to be solved (Design Challenge).
This article vs. Google UX Certificate / UX Research and Empathy-Define Division of Responsibilities:The Google UX Certificate / UX Research and Empathy-Define materials cover the research methods themselves — how to conduct interviews, how to draw empathy maps, how to run usability tests, how to turn sticky notes into insights.This article explains how to use AI to "quickly turn these research outputs into deliverables that can be reported to stakeholders or placed in a portfolio". The two complement each other: you use the google-ux-research methods to do real research, and use the prompts in this article to distill the results into professional documents. Overlapping areas (problem statements, hypotheses, user research report structure) are cross-referenced rather than repeated.
Significance for PMs: The implicit audience for this set of prompts is people "building a UX portfolio / preparing for interviews / needing to report to their boss". Its core value is not "doing research for you", but rather forcing the scattered project background in your head into an argument chain of "audience → scenario → task → evidence → design decision", and expressing it in objective, quantifiable, non-exaggerated language. Even if you do not work in UX, these mental models — "define audience and scenario before asking about needs", "business outcome = traffic × conversion × cost", and "four-dimensional demand scoring" — are universal scaffolding for PMs making demand judgments.
0. First, build 4 mental models (the thinking behind the prompts)
AI prompts are just the shell; what really determines output quality is the thinking framework you give them. Will’s set of techniques repeatedly uses 4 underlying models. Establish these first, so the prompts that follow are not black boxes.
1. Business outcome = Traffic × Behavioral conversion × Cost structure
Enterprises profit from business outcomes, and experience design only acts on the single variable of the "user behavior layer", not the entire business system. This is the most important sentence in the entire article — it keeps you honest and prevents you from overstating the role of design.
| Layer | Determined by | Role of experience design |
|---|---|---|
| Traffic | Advertising / Channels / Brand | Basically does not play a decisive role |
| Behavior | Product capability + Experience design | Primary area of impact (conversion rate, retention rate) |
| Cost | Technology / Organization / Process | Only intervenes in the "user self-service" link |
Four major categories of business goals = Growth / Profit / Cost reduction / Efficiency improvement, and the boundary of experience’s role differs in each category:
- Growth = Traffic × Conversion × Retention. Experience mainly affects conversion rate and retention rate, and does not affect traffic acquisition.
- Profit = User scale × Paid conversion rate × Average order value. Experience affects paid conversion + part of perceived value, and does not determine pricing or business model.
- Cost reduction = Reducing per-unit service cost. Experience only intervenes in "whether users can self-serve, whether operations fail, whether they need to contact customer service", and does not determine technical architecture costs.
- Efficiency improvement = Reducing time + Increasing output.Experience has the greatest role here — it directly affects operation paths and cognitive cost.
Why (why PMs should memorize this first): Interviewers / bosses most resent empty claims like "improving experience will drive growth". When you can say "experience only acts on conversion and retention; traffic depends on ad spend" — you immediately appear to understand business boundaries. The repeated requirement in all subsequent prompts to "not exaggerate the role of experience and objectively express the boundary of its role" is rooted here.
2. Experience goals ≠ Business goals (do not mix up these four terms)
- Business goal = The outcome to be achieved (company perspective, e.g., "mobile DAU +20%")
- Metric = Data that proves whether the outcome occurred
- Experience/design goal = The user behavior that needs to change to achieve the business goal (e.g., "reduce the operation cost of retrieving files")
- Experience/design metric = Data that verifies whether the behavior has changed (completion rate / time spent / click-through rate)
The chain is always: Experience optimization → User behavior change → Business outcome change. The requirement in prompts that "causal relationships must be reflected" refers to this chain.
3. The dual hypotheses of MVP (Value vs. Solution)
MVP (Minimum Viable Product, from *The Lean Startup*) = The simplest version of a product/feature, but it must be sufficient to let you judge "whether users can get value from it". It sequentially answers two questions, corresponding to two types of hypotheses:
- Value-Proposition Hypothesis: "A certain value is valuable to a certain group of people" — verifies whether users think this thing is useful.
Skeleton:
我们相信 [某价值] 对 [某类人] 有价值。如果测试中看到 [某种行为信号],就说明这个假设成立。 - Solution Hypothesis: "Whether this specific approach can deliver the value."
Key reminder: If an MVP is hard to use and causes users to abandon it, it is not necessarily that the idea has no value; it may just be that bad design is blocking the value. Therefore, when an MVP fails, distinguish whether the "value hypothesis is invalid" or the "solution hypothesis is invalid".
When to use MVP (Risk-Reward Matrix): High risk + high reward → First test with a low-cost prototype MVP; Low risk + high reward → Can launch a code MVP into the real market; Low risk + low reward → Do not build it specifically for now; High risk + low reward → Lower priority or redefine the problem.
External wording: Unless it is truly officially released, do not call it "launch/release"; call it a pilot/experiment pilot / experiment / learning test, emphasizing "this is for validation, not the final version" — this makes it easier to get stakeholder support.
Common MVP metrics (6 categories): Engagement, Retention, Macro-conversion (key behaviors that directly affect revenue), Micro-conversion (small behaviors close to conversion, such as clicking "learn more"), System performance, AI performance (the proportion of AI outputs considered relevant/accurate).
4. Four-dimensional demand intensity scoring (judging "whether it is worth doing")
To judge whether a demand is a real pain point, score 1–5 on each of 4 dimensions: Frequency / Intensity (what happens if it is not solved) / Existing alternative cost (how bad the current solution is) / Willingness to pay and migrate. As long as two of these are low, it is usually not worth prioritizing investment. This table appears repeatedly later in "user research reports" and "demand judgment".
Golden criterion:"Has happened" > "Thinks it might". During interviews, if the other party cannot give "a real example that happened recently", this demand is most likely not strong. See the behavioral recall method in §1 for details.
1. Judge whether users really have the demand (Market Need)
This is the starting point of research; it is not an AI technique but an interview mindset, but it determines the input quality of all subsequent AI prompts — if the audience and scenario are not clearly defined, all the "goals" produced by AI will be empty talk.
Why: Most people validate demand by "asking users if they like the concept", and get only polite "it’s pretty good" responses, which end up as "everyone says it’s somewhat useful, but no one is willing to switch".
4-step reusable process:
- Do not ask "do you need it" first; first locate "who + in what scenario + wants to complete what task (JTBD)". If these three items are not defined, answers will be highly scattered.
- Use "behavioral recall" in interviews, not "attitude questions" — ask the other party to tell a real story that happened recently, rather than stating an opinion on a concept:
- Most recent time (force specificity): "When was the last time you encountered this problem? What were you doing at the time? What was your goal?"
- Existing solution (see if it is really painful): "How do you solve it now? What is the most troublesome part of this method? How troublesome is it?"
- Cost quantification (turn pain points into costs): "How long does this usually take you? How many times a week? What is the worst thing you can lose (money/time/risk/emotion/opportunity cost)?"
- Priority comparison: "What are the top 3 annoyances in your work? Where does this one rank? If you could only fix one, which would you fix?"
- Use a "hypothetical solution" for lightweight validation to see if they are willing to pay the cost — People will say yes to a good idea, but will not pay a price for it. Fake door / waitlist (look at click conversion rather than verbal support); Pre-mortem commitment questions: "If you could use it tomorrow, what task would you use it for? Are you willing to change your existing process? What costs are you willing to pay: importing data / 30 minutes of training / paying monthly / letting IT review it?"
- Demand triangulation (do not rely only on interviews): Customer service tickets/sales recordings (the most real demand signals), in-site search terms (users looking for solutions), behavior funnels (at which step users drop off), competitors/manual alternatives (Excel/Notion/WeChat groups/screenshots are real demand signals), community complaints.Market Need is not a single piece of evidence, but whether these pieces of evidence point to the same "pain point/audience/scenario".
Counterexample: The other party only says "it’s pretty good", but hesitates when migration/payment/learning is mentioned → This is a nice-to-have, not a must-have.
This section is the "business validation version" of §3 "User Interview SOP" in the Google UX Certificate / UX Research and Empathy-Define materials — UX interviews lean toward "where to put this button", while this section leans toward "whether this business/feature is worth doing", and shares the same origin as Yitang OSCAR research.
2. AI Technique 1: Distill scattered background into a "Project Background (PB) statement"
Task solved: You have a pile of scattered project information (screenshots, chat records, old PPTs, fragments in your head), and you need to turn it into a paragraph of project background that is "professional and can be spoken directly in interviews/reports". This is the first deliverable of the entire AI pipeline; subsequent "business goals" and "experience problems" all consume its output.
Input: Scattered project background information (images/text) → Output: Professional project background statement (text).
Reusable prompt skeleton
你是资深产品经理与 UX 研究员,擅长将碎片化信息或截图转化为专业结论表达。
我将提供输入信息,请你:
- 必须完整吸收所有信息(不可忽略任何关键点)
- 基于理解重建逻辑(禁止改写或沿用原结构)
- 输出必须极度精简、直击本质(每条都是结论,不解释过程)
1. 业务背景(Why):从输入提炼 趋势 / 核心问题(覆盖所有关键点)/ 机会
2. 用户场景(When):用结构「当用户在【具体场景】下,由于【现实限制】,需要【任务】」,
覆盖所有关键信息,禁止抽象表达
3. 用户洞察(Insight):1 句话,必须揭示"真正缺什么",不是表面需求
4. 口述表达(面试/汇报):一句话版本(≤200 字),结构 背景→问题→机会,能直接说出口
强约束:不遗漏关键信息 / 不复述不解释不铺垫 / 不超字数 / 每句话都是"结论" / 优先"少但准"不是"多但全"
Fill-in-the-blank template for business background (can be used independently, no AI required)
Business background = Business problem + Trend + Opportunity. Fill-in-the-blank skeleton for professional expression:
This project is a [product type/industry] product, primarily serving [target users]. A typical scenario is: when [user role] is in [specific scenario], due to [strong constraint/unexpected situation], they must immediately [key task], but the current approach is [original inefficient/failing method], which leads to [specific consequence: delay/error/loss/embarrassment]. Our product provides [core function]; users only need [1–2 key steps] to [direct result], turning a previously stuck scenario into a quickly completable flow. The product is currently at [specific stage + objective data: user scale/DAU/frequency], and internally serves [one-sentence business role: growth/conversion/efficiency]. I am responsible for [module scope, clearly stating start point → end point in one sentence]; this segment is [key path positioning], but the current core problem is [one-sentence problem conclusion]. From the data, [metric 1] is [current value], lower than [benchmark/target], and [metric 2] shows obvious drop-off at [key node]……
Why: The essence of this template is the causal chain of "scenario → constraint → task → consequence" + "which segment I am responsible for + the data problem in that segment". Interviewers do not want to hear "I built an App"; they want to hear "When a user suddenly needs to send a file on the subway, they can only wait until they get back to their computer, which delays the client, and the click-through rate of the mobile entry I am responsible for is only 18%." The latter anchors the abstract project to a specific, data-backed pain point.
Pitfall: Do not let AI "reuse the original input structure" — it will take the lazy route and copy your PPT layout. The strong constraint "rebuild logic, every sentence is a conclusion" is exactly what fixes this.
III. AI Technique 2: User Stories (System View → User Behavior View)
Work it solves: Translate a "system-perspective" feature description into a one-sentence story from the "user behavior perspective". In essence, this is already implicit in the business background expression in §II.
Fixed template (WHO + WHAT + WHY):
作为一个 [用户身份],他希望 [用户想做的事],以便 [用户希望的结果]。Example: A salesperson meets a client on the road who suddenly asks for materials; he hopes to immediately control his computer via his phone to send the file, so he does not need to return to the computer or ask a colleague to send it for him, and can also improve his professional impression in the client's mind.
Why: User stories force you to switch from "what feature I built" to "what behavior the user performs for what purpose". It and Google UX Certificate / UX Research & Empathy - Define problem statements (
[用户]需要[需求]因为[痛点]) are two phrasings of the same action — stories lean toward "what the user wants to do", while problem statements lean toward "what is missing".
IV. AI Technique 3: Derive "Business Goals × Experience Goals × Driving Logic" from Background
Work it solves: Takes the output of the "project background expression" from §II, and automatically derives 3–5 complete chains of "business goal → experience goal → plain-language causality". This automates mental model 2 from §0.
Input: Project background expression (text) → Output: Experience goals + clear value of experience to the business.
Reusable prompt skeleton
你是资深产品经理,具备业务分析与指标体系搭建能力。
根据上面的业务背景与用户场景,输出 3–5 组完整链路,每组严格控制结构:
① 业务目标与指标(两句话)
第1句:业务要实现的结果 + 核心指标(必须量化,如 DAU/转化率/成本/时长 + 变化方向或区间)
第2句:属于 增长/盈利/降本/增效 哪一类,点出核心驱动路径
② 体验目标与指标(两句话)
第1句:要优化的"用户行为" + 体验指标(必须量化,如完成率/时长/点击率/流失率)
第2句:具体作用在哪个环节(转化/留存/付费/成功率)
③ 体验 → 业务的驱动逻辑(必须大白话)
1–2 句,不讲术语,解释为什么这些体验优化会影响业务目标,
必须体现"用户行为变化 → 业务结果变化"的因果,可说明作用边界(不是唯一因素)
总原则:完整吸收不遗漏 / 重建逻辑禁止复述 / 客观不夸大体验作用 / 禁止空话(如"提升体验""增强粘性")/
每句都是结论不写推导 / 第③部分必须"讲人话"让非产品的人也懂
What the output looks like (text description)
Three-paragraph structure, with the number of sentences per paragraph strictly fixed:
- ① Business goal: "Increase the usage scale of light tasks on mobile, driving related DAU up by 20%~30%. This goal belongs to growth, expanding overall activity by increasing usage frequency in fragmented scenarios."
- ② Experience goal: "Reduce the operation cost for users to complete light tasks, cutting task completion time by 30% and increasing completion rate by 20%. This optimization mainly acts on retention and usage frequency."
- ③ Driving logic (plain language): "Users originally wouldn't use it because they found it troublesome; now that it's faster and simpler, they are more likely to use it a few more times; when more people use it and use it more frequently, DAU naturally goes up."
Why: The killer feature of this prompt is that paragraph ③ forces "speaking in plain human language". Many people can write goals in a very professional way, but when pressed with "why does experience optimization drive DAU growth", they get stuck or hide behind jargon. Forcing plain-language causality both tests whether you truly understand it, and lets reporting targets (non-product bosses) understand immediately.
Pitfall: "No empty talk" is the constraint most easily violated in this prompt — "improve stickiness" and "enhance experience" are the default nonsense AI spits out; you must explicitly ban them in the skeleton, forcing it to express things with "behavior + quantified metrics".
V. AI Technique 4: For Old Interfaces, "Locate Experience Problems + Quantify Metric Impact"
Work it solves: Give AI a screenshot of an old interface (or multiple images of a flow), and have it first identify core operations from a business perspective, then pick out 3–5 experience problems from a user perspective, and anchor each problem firmly to a specific business metric. This is the argumentation engine for the "why we redesigned" page in a UX portfolio.
Input: Old version single interface or flow (image) → Output: Core experience problems + impact on business/experience metrics.
Reusable prompt skeleton (two parts, order cannot be reversed)
你是资深产品经理与 UX 设计专家,具备从商业目标到用户体验的全链路分析能力。
我将提供一个界面(或多个界面组成的流程)。
【第一部分:业务视角分析(必须优先完成)】
1 核心操作识别:用户最核心的一步操作是什么(只能有一个,必须是"对业务最关键"的行为
而非表层点击,一句话 = 动作 + 结果)
2 为什么它是业务核心:2–3 句,说明它在业务链路的位置(转化/留存/变现/激活)
3 关键业务指标:3–5 个,含 指标名 + 变化方向(↑/↓) + 可选影响范围(新/老用户)
4 商业逻辑成立条件:大白话解释这些指标提升意味着什么逻辑成立(需求被验证/转化有效/付费意愿成立)
5 总结业务目标(一句话):「通过提升【核心操作】的完成效率与转化,驱动【关键指标】提升,
从而验证【某商业逻辑成立】。」
【第二部分:用户体验问题分析】
模拟用户真实使用,只输出 3–5 个问题,必须按"对业务指标影响权重"从高到低排序。
每个问题含:
1 问题描述(What):一句话点本质(不是表象)
2 具体表现(Where & Detail):结合界面细节——信息架构/交互路径/视觉层级/视觉权重/比例尺度/一致性
3 影响的业务指标(Impact):哪个指标 + 如何影响(↑/↓)
4 原因解释(Why,大白话):为什么这问题导致指标变化,用户在这卡住/犹豫/放弃的真实心理
风格:不复述输入 / 不泛泛而谈 / 不讲"设计原则",只讲"问题→影响→原因" / 每句是结论 / 可直接用于作品集
Why: The design philosophy of this prompt is"business first, then experience, and experience problems must be tied to business metrics". The most common mistake new UX practitioners make in reviews is "listing a bunch of design flaws" (misaligned elements, ugly color schemes) without being able to explain what exactly those flaws cost the company. This structure forces every problem to answer "which metric does it drag down, and why" — upgrading "aesthetic complaints" into "business justification".
Relationship with Google UX Certificate / UX Research & Empathy - Define relationship: The "usability studies" in that material have real users operate to discover problems; here, AI is used to simulate user operations to quickly generate problem hypotheses. The AI version is cheap and fast, but can only serve as a "list of hypotheses to be validated"; real usability testing is what confirms truth — do not treat AI's guesses as conclusions.
Pitfall: "Sort by weight of business metric impact" is critical. Without sorting, AI will lay out 5 problems as if they are equally important; forcing sorting pushes it to judge "which problem is the deadliest", which is exactly a PM's core competency.
VI. AI Technique 5: Rewrite Vague Problems into "Actionable Problem Statements + Overview Diagrams"
Work it solves: Rewrite a vague complaint ("churn is getting higher") into a precise, quantifiable, locatable problem statement, paired with a data description for a one-page "problem overview diagram".
Input: Step 1 first use the GPTs "PitchPro" to upload project screenshots and produce an overall framework of "background/challenge/problem/solution"; Step 2 feed the framework + prompt in → Output: Precisely defined problem + supported by research data.
Reusable prompt skeleton
需求:把模糊问题"可行动化",转化为可量化、可定位的问题陈述。
输出形态:
A 一条精炼的问题陈述语句
B 一页问题概览图(含 时间趋势图 + 关键指标数值 + 受影响人群描述)
问题陈述示例(目标质感):
「近两个月付费用户月度流失率从 3% 上升到 5%,其中新用户前 30 天流失占比增加最快。」
「自 10 月起,使用 X 功能的 B 端小团队客户在第 2–3 个计费周期的流失率从 12% 上升到 21%,
主要集中在年付转月付的客户。」
一页问题概览图:给出数据使用的图表类型 + 数据明细。
Why: A qualified problem statement must include time (since when) + magnitude (from X% to Y%) + audience (concentrated in whom). Compare "churn is getting higher" with "since October, churn for B-end small teams in the 2nd–3rd billing cycle rose from 12% to 21%, concentrated among users switching from annual to monthly billing" — the latter directly tells you where to look and whom to check. This is the Google UX Certificate / UX Research & Empathy - Define problem statement formula (
[用户]需要[需求]因为[痛点]) "data-located version", leaning more toward PM metric language.Pitfall: This environment does not embed images; in practice, the "problem overview diagram" means having AI describe "what chart to use + which numbers to mark", then you or a design tool draw it out.
VII. AI Technique 6: MVP Goals & Metrics (a Paragraph of Interview Verbal Script)
Work it solves: Given product/users/scenario, have AI derive the full chain "value hypothesis → MVP form → testing method → metrics → simulated results → conclusion" in one go, and output it as a segment of roughly 5 sentences of interview script that can be spoken directly.
Reusable prompt skeleton
【用户输入】项目/产品: / 目标用户: / 使用场景:
【你的任务】基于输入自动推理(不显式展示过程):
1 推断最核心的价值假设(1 个)
2 选择 MVP 形式(原型/代码)
3 推断测试方式(定性/定量/混合)
4 定义 ≤3 个核心指标(必须符合该产品场景)
5 合理生成一组典型测试结果(有真实感,避免极端)
6 给出结论(支持/部分支持/不支持)
【输出要求】一段面试口述话术,约 5 句,只含 目标→方法→指标→结果→判断;
不解释推理 / 不给策略 / 不夸张(避免"非常成功""效果很好")/ 用词客观(表现较好/存在下降/有一定问题)
【输出风格】这次 MVP 主要验证的是…… 我们使用的是…… 核心看三项指标…… 结果是…… 整体判断是……
What the output looks like
"The main thing this MVP validates is: after receiving personalized financial advice, whether users will develop actual willingness to act. We used a clickable prototype and conducted qualitative testing among target users. We focused on three core metrics: whether users understood the product value, whether they recognized the advice as useful, and whether they expressed willingness to execute. The results showed good performance on the understanding and recognition dimensions, but a clear drop on 'actual execution willingness', with users generally hesitating. Overall judgment: value perception is established, but the behavioral conversion layer is not fully validated."
Why: The most exquisite constraint in this prompt is"use objective wording, avoid exaggeration". Newcomers writing MVP retros love to say "the effect was very good, a great success" — and they crash as soon as they are pressed with follow-up questions. Will's set deliberately trains restrained expressions like "performed relatively well / showed a drop / partially validated", which instead makes it sound like you actually did it and thought it through. This directly echoes §0's MVP dual hypothesis (value vs solution): a conclusion that "value perception is established but behavioral conversion is not validated" is a hundred times more credible than "total success".
Aligning with stakeholders: When talking about MVP, you must (1) clarify which hypothesis is being validated + why it relates to the business (2) frame it as an experiment using pilot/experiment (3) clearly state "what result counts as supporting/partially supporting/not supporting".
VIII. AI Technique 7: Generate a Complete "Product Concept User Research Report" (Including Simulated Data + Risk Signals)
Work it solves: After a completed product/project,fill in the argumentation chain of the early "user research" segment, producing a structurally complete user research report (simulated case) that can clearly explain "why we did it" in interviews. This is the heaviest prompt in this phase.
⚠️ Red lines for use (must understand first, otherwise you will crash)
The users and data in the report are simulations based on reasonable deduction, not real collected data. A safer way to present it in interviews/defenses is to frame it as"my user research approach and argumentation"(how I would define users, how I would find evidence, what conclusions I would reach), rather than claiming "I actually interviewed 30 users".
Reason: Once an interviewer presses "tell me about a user quote that surprised you most", fabricated "real data" will collapse on the spot; a "research approach" always stands up to follow-up questions. Similarly, the report deliberately includes a section on"risks and opposing signals" — a report full of praise looks fake at a glance; a report that says "we also found problem XX" looks like real research was done and has the highest credibility.
Reusable prompt skeleton (9-step workflow)
【输入(我会填)】产品是什么 / 目标人群 / 使用场景 / 用户任务(JTBD)+ 期望收益 / 现有替代方案
Step 0 输入诊断 + 升级(不打断,而是教学):逐项检查输入质量,对不合格字段
① 指出问题(为什么会让研究失焦)② 给"合格版本"示范 ③ 用升级版继续并告诉我升级成了什么
常见问题:人群写成"想学 X 的人"= 循环定义且混淆购买者vs使用者(要拆到角色/年龄规模/熟练度/谁掏钱/谁用);
场景写成"任何碎片化场景"= 没触发点(要写清触发事件/频率/上下文);
替代方案写"没有"= 危险不专业(要含直接竞品 + 间接/手动替代:Excel/纸笔/找人代劳/免费视频)
Step 1 研究设计:研究目标 / 方法(深访+问卷,定性+定量混合)/ 样本设计(N=15–30,如何分层,招募标准)
Step 2 受访者画像:N 个有代表性受访者,分层覆盖,必须同时含购买者和使用者两类
Step 3 定性发现(行为回溯法):对关键受访者用第一人称呈现"最近一次真实故事"
(具体时刻/当时在做什么/目标 → 现在怎么解决/最麻烦处 → 代价 → 在他烦恼里的优先级),
归纳成 3–5 个主题,每主题配 1–2 句代表性"原话"
Step 4 定量统计:汇总成数据(X% 一周遇到 N 次 / X% 用某替代方案凑合 / 痛点强度 1–5 均值 / 付费意愿分布),
务必注明"以上为模拟数据"
Step 5 痛点优先级(四维打分):频率/强度/现有替代成本/付费迁移意愿 各 1–5 打分排序,得出最该优先解决的痛点
Step 6 机会点 & 设计启示:把高优先级痛点翻译成设计机会,反向连到具体功能
——明确"因为发现痛点 A,所以做了功能 B"(面试官最想听的逻辑链)
Step 7 风险与反对信号(关键别省):诚实列反对意见/风险/未解问题/这方案可能不成立的条件
Step 8 执行摘要(最后写,放最前):一段话讲清 谁·什么场景·什么核心痛点·多强证据·所以值得做
【输出顺序】1 执行摘要 2 背景与研究目标 3 研究方法与样本 4 受访者画像 5 定性发现 6 定量统计(注明模拟)
7 痛点优先级四维表 8 机会点与设计启示(痛点→功能)9 风险与反对信号 10 结论
语气:客观专业、像真做过,但保留局限与反对证据,避免"一边倒好评"的失真感
What the output looks like (using the "Children's Phonics App" demo case as an example)
The value of this demo case is to demonstrate how "input diagnosis" can rescue useless input, and how research conclusions can reverse product direction:
- Step 0 Diagnosis Upgrade "users who want to learn phonics" to "user = 4–6 year old children / purchase decision-maker = 25–38 year old mothers"; upgrade "any fragmented scenario" to "trigger = parent-child bedtime reading, once per day for 5–10 minutes"; upgrade "alternative: none" to "Zebra English / Jiliguala / Starfall + Bilibili free videos/letter flashcards for self-teaching".
- Qualitative findings Summarize 5 themes, each paired with a quote in a real person's tone, such as "I buy courses just to save trouble; you want me to listen to my kid read and judge right or wrong myself? I'm not an English teacher".
- Quantitative statistics(marked as simulated): 81% consider phonics important, but 76% admit they cannot judge whether pronunciation is standard; only 19% are willing to pay for a "practice tool", while 58% are willing to pay for "AI pronunciation correction"; pain point intensity for "unable to correct pronunciation" is 4.3 vs "lack of practice tools" at 2.4.
- Four-dimensional scoring Leads to a reversed conclusion: the product's originally featured "self-test practice tool" is the lowest-priority pain point, and the real high-value opportunity is AI voice listening + real-time error correction.
- Opportunity points → features: Core feature upgraded from "view answers for self-evaluation" to "child reads → AI scores in real time + highlights erroneous phonemes"; bedtime push + consecutive check-ins; mispronunciations go into a "mistake notebook" for review based on the forgetting curve.
- Risks and opposing signals(presented honestly): The track is extremely crowded, AI recognition accuracy for children's accents is the lifeline, under 4 years old is a fake demand (those parents cannot name a recent example), and the 58% "willing to pay" is only attitudinal data requiring a fake door test to verify real conversion.
Why: The soul of this report is Step 6's "pain point → feature" logic chain + and Step 7's honest opposing signals. The former is exactly what interviewers most want to hear — "because research found A, I changed the feature from X to Y"; the latter builds credibility by saying "we also found problems". It strings together §0 mental model 4 (four-dimensional demand scoring) and §I (behavioral retrospection method) into one deliverable document.
Relationship with Google UX Certificate / UX Research & Empathy - Define relationship: That piece covers how to actually do interviews, draw affinity diagrams, and write strong insights against 5 criteria; this piece is for when you "don't have time/conditions to do real research", using AI to generate a simulated report with a logically sound argument structure can serve as the skeleton of a portfolio — but only if you honestly label them as simulations and frame them as "research thinking demonstrations." The two are distinct: "real practice" versus "structure demonstration"; do not mix them, and never pass off simulated data as real user research.
IX. AI Technique 8: Chart Prompts for Converting Content into Professional Infographics
Work it solves: Give AI a piece of product information (business background / user journey / system modules / growth logic, etc.), and have it produce a"chart prompt", then feed that prompt into a diagramming tool to generate professional infographics suitable for portfolios or presentations (conceptual framework diagrams, user flow diagrams, information architecture diagrams, system architecture diagrams, strategy roadmap diagrams, etc.). This is the visualized version of "project background presentation."
Three-step workflow: Step 1: Information (images/text) + prompt → graphical descriptions of multiple options; Step 2: Draw the selected diagram entirely in English; Step 3: Provide a visual style reference image and request "keep the content unchanged, adapt it to this visual style."
Reusable prompt skeleton (for generating "chart prompts")
你是熟悉互联网数字产品表达的专业图表设计师,擅长把复杂的产品信息/业务逻辑/用户流程/系统关系/
策略路径/关键结果,转化为适合专业汇报、UX 作品集、产品文档、管理层沟通的高质量可视化图表。
我会提供产品项目的关键信息(业务背景/目标用户/核心问题/产品目标/功能结构/信息架构/用户路径/
关键策略/系统模块/增长逻辑/数据结果/实验设计/优化结论等),请生成中文提示词用于制作专业图表
(概念框架图/产品业务逻辑图/用户流程图/信息架构图/功能结构图/系统架构图/策略路径图/机制示意图/核心结果可视化图)。
整体风格:简洁现代的数字产品风格,接近高质量产品方案图/咨询图/高级 UX 作品集;布局清晰、信息层级明确、
配色 3–4 种以内、无衬线字体。
每条提示词必须说明:① 图表呈现对象(业务系统/产品模块/用户任务/策略机制/指标结果)
② 核心变量或关键要素(用户角色/触点/功能模块/决策节点/输入输出关系/增长杠杆/指标变化)
③ 逻辑结构(先后流程/因果关系/层级关系/闭环机制/路径拆解/模块协同)
④ 需强调的重点结论(核心问题/关键影响因素/方案如何起作用/优化后结果/业务或体验价值)
风格要求:专业简洁清晰 / 强调逻辑表达而非装饰 / 不得编造未提供的信息 / 信息不足只基于已知组织不补细节
最重要:不要沿用我输入内容原本的结构直接出图——即使我给的是文字/已有图表/PPT 结构,
也必须先理解真实含义和逻辑,再重建更适合可视化的新结构,目标是"更利于理解、展示、传达"而非机械复刻排布。
"Transfer/Prohibit" checklist for precise visual style control (used in Step 3)
When you want to "borrow the style of a reference image without copying its content," explicitly tell AI:
- Allowed to transfer: Primary color / secondary color / brushstroke and texture / modeling language (how details are simplified).
- Prohibited from transferring: Main content and structure / specific symbols / specific composition and layout / background.
Why: The entire prompt repeatedly emphasizes one core point —"understand the logic first, then reconstruct the structure; do not replicate the original layout". The most common failure when beginners ask AI to generate diagrams is "directly arranging a paragraph of text horizontally into a single line of boxes," with no information hierarchy. Only by forcing AI to "reconstruct a new structure better suited for visualization" can you get a real infographic. The "allowed/prohibited transfer" checklist, meanwhile, solves the off-flavor problem when changing styles: "failing to capture the style while accidentally drifting the content."
Pitfall (in this environment): In Will's hands-on practice, diagrams are generated directly; this wiki does not embed images, so only "how to write the prompts" is retained here. When you actually need to produce diagrams, feed the skeleton into a diagramming model that supports text rendering (for Chinese card-style materials, see the content-replication experience notes in memory).
Beyond the core: Supporting mapping tables (for lookup, not an AI technique)
The source area also includes 4 "quick-reference mapping tables," which are comparison tools for research design, not prompts. Key points:
- Project phase × Requirement type: Covers the full lifecycle from "requirement definition → concept → design → prototype → development → testing → launch → operation → optimization → growth → repositioning → end of lifecycle," with the work to be done at each phase (discovery phase = requirement collection / market research / requirement prioritization).
- Requirement type × Business goal: Six categories of requirements — user / business / technical / market / operational / lifecycle — each mapped to growth / profit / cost reduction / efficiency improvement (e.g., "basic functional requirement → efficiency improvement," "market requirement → growth," "compliance requirement → cost reduction").
- Requirement type × UX research method: Which research method to use for each type of requirement, plus qualitative/quantitative labeling (e.g., "pain point requirement → user interviews + journey mapping + task analysis, qualitative"; "growth requirement → A/B testing + surveys, quantitative").
- Project phase × UX research method: Discovery phase = interviews / surveys / focus groups / field research; Concept phase = Personas / journey maps / concept testing; Iteration phase = usability testing / A/B testing / eye-tracking / heatmaps; Post-launch = NPS / logs / sentiment analysis. This table and Google UX Certificate / UX Research and Empathy - Definition §1 "Three research types × timing" are refined versions of the same map.
Why included: These tables answer "what phase am I in now, which method should I use, and which business goal does it correspond to" — they serve as the index that "hangs all the preceding AI techniques back onto the full project landscape." But they are lookup reference materials, not core daily-use content, so they are placed at the end as an appendix.
Key Terms Quick Reference (Glossary)
| English | Chinese | One-sentence explanation |
|---|---|---|
| Market Need | Market requirement | Only counts as valid when multiple pieces of evidence point to the same "pain point / audience / scenario" |
| JTBD (Job To Be Done) | User task | What the user wants to accomplish (the third element defining audience and scenario) |
| Behavior recall | Behavioral recall method | Ask users to tell "their most recent real story" rather than state opinions on a concept |
| Fake door | Fake door test | Build an entry point to observe click-through conversion, verifying whether users are willing to pay the cost |
| PB (Project Background) | Project background presentation | Distill scattered information into articulable, professional background context |
| Value-Proposition / Solution Hypothesis | Value/solution hypothesis | For MVP, first test "is there value" before testing "can the approach be delivered" |
| MVP Risk-Reward Matrix | Risk-reward matrix | High risk high reward → prototype MVP; low risk high reward → code MVP |
| Business outcome = Traffic × Conversion × Cost | — | Experience only acts on the layer of "behavior / conversion / retention" |
| Growth / profit / cost reduction / efficiency improvement | The four major business goals | Experience has different boundaries of effect in each category (greatest for efficiency improvement) |
| Four-dimensional requirement scoring | — | Frequency / intensity / substitution cost / willingness to pay and switch; if two dimensions score low, do not build it |
| Pain point → feature logic chain | — | "Because pain point A was discovered, feature B was built" (what interviewers most want to hear) |
| Risks and counter-signals | — | A mandatory section in user research reports; reports are only credible when they include opposing evidence |
<!-- The reference page in the source area "UX Research" is a slide deck consisting purely of images and video (11 images + 1 mp4 clip) with no extractable text; this wiki does not embed images so it is not included. Its content overlaps with the research methods section of [Google UX Certificate / UX Research and Empathy - Definition](/knowledge/kb-a307fb5b2fe9b584760983817c93009b). The English prompt page is an English mirror of each Chinese prompt, with equivalent content, so it is not duplicated here. -->