What this covers: the "Define & Insight" segment of the design process — you already have a pile of user research materials and data, and now you need to turn them into insights that can guide design, and communicate them clearly. The manual labor in this segment (reading transcripts, synthesizing, drawing charts, scoring) is the most suitable to outsource to AI. This article presents 6 reusable AI workflows + 4 mental frameworks.
Significance for PMs: the thing you do every day — "distilling what should be done from a pile of feedback" — is exactly this. The difference is that in the past you relied on reading item by item and making calls based on experience; now you can let AI run through it first to produce a structured draft, and you only do judgment and tradeoffs.AI does not make decisions for you; it saves you 80% of the organizational manual labor, letting you spend your time on "whether this insight actually holds".
Division of labor with Google UX Certificate / UX Research and Empathize-Define division of labor: that piece is a "manual craft handbook" — how to conduct interviews, how to draw empathy maps, how to run usability tests, how to turn sticky notes into themes with affinity diagrams. This piece is "prompts and judgment rules for handing the same set of work to AI". The underlying concepts such as criteria for strong insights, affinity diagram method, and problem statements are already thoroughly explained there, so here we only cross-reference when necessary and do not rewrite them, focusing instead on AI prompt skeletons + when to use them + counterexamples.
0. First build the map: 4 types of work in the Define & Insight phase + 2 core principles
The pipeline of the entire phase (derived from Will's Define & Insight framework):
构建假设(Hypothesis) → AI 模拟/补充研究数据 → 结构化整理 + 可视化(Visualization) → 提炼输出关键洞察(Insight)
For PMs, there are 4 specific types of work that can be outsourced to AI, and this article provides prompts for each one:
| Work | Input | AI Output | Section in this article |
|---|---|---|---|
| Extract insights | Interview transcripts / single core question | Structured insights / insight cards | §1, §2 |
| User research visualization | User research report / a segment of data | Chart selection + ECharts/HTML code | §3 |
| Chart selection | "What chart should I use for this kind of data" | PM quick reference for 80 chart types | §4 |
| Interface eye-tracking | Interface screenshots | AI-simulated heatmap + scanning pattern interpretation | §5 |
| Solution scoring | Multiple UI screenshots | 6-dimension expert review + deduction table | §6 |
Two core principles that run through the entire article(memorize them first; they are used in every section later):
Principle 1 — No conclusion without a "why" is an insight."Users find it complicated / don't like this feature / want it simpler" are not insights, they are just restatements of phenomena. An insight must answer "why users do this" and connect directly to design actions. See §1 for details.
Principle 2 — Data and user research divide labor; they do not replace each other. Data tells you "where" the problem is, user research tells you "why" and "what else can be done". The ratio of the two differs across 4 types of projects (growth/fix/validation/exploration); see §7 for details.
Why build the map first: PMs tend to jump in and ask "help me analyze these interviews", only to get a bunch of unfocused summaries from AI. If you first clarify "what type of work I am doing now and what output I need", then select the corresponding prompt, efficiency is 3 times higher.
1. Batch extracting insights from interview transcripts (Research Synthesis)
Applicable scenarios: You have completed a round of user interviews, have N transcripts (thousands to tens of thousands of words) on hand, and need to produce a "research synthesis report" that can guide design within 2 hours.
What is a "strong insight" — first dispel misconceptions
A true insight must satisfy all 3 conditions at the same time (this set of standards is also covered in Google UX Certificate / UX Research and Empathize-Define; here we provide directly usable sentence patterns):
- Explains "why" (causality) — not "users didn't click", but "because users were unsure about the outcome, they dared not click"
- Can guide "how to fix it" (actionable) — not "users find it complicated", but "the core of the complexity is not the number of steps, but that every step requires re-judgment"
- Generalizable (not an isolated case) — not "what a certain user said", but "a group of users will make this decision in a certain context"
Causal sentence template (strongly recommended to save as a snippet):
在【某种用户 / 场景】下,用户会【某种行为或决策】,
因为【背后的认知 / 情绪 / 动机】,
这导致了【当前问题或机会】,
因此我们应该【设计方向】。
Counterexample ❌: "Users are unwilling to click the purchase button" Positive example ✅: "When first encountering high-priced products, users do not click purchase immediately, because they first need to confirm 'is it worth it' and 'is it reliable', which causes users to stall at key conversion nodes; therefore we need to provide trust and value proof before decision-making, rather than strengthening the CTA."
Prompt skeleton A: Batch transcripts → research synthesis report
Let AI act as a rigorous UX researcher, extract item by item along 5 dimensions,and each item must be quantified (frequency/severity) + cite original quotes:
我是高级产品设计师,正在做用户研究综合分析。已上传 [N] 份访谈转录稿。
项目背景:产品 [X] / 功能领域 [Y] / 目标用户 [Z] / 使用场景 [...] / 当前用户怎么处理 [...]
请以「准备设计需求」的严谨度分析,按以下框架提取可执行洞察:
1. 痛点:每条 = 直接引用原话(标参与者+段落) + 频次(X/总数) +
严重程度(致命/高/中/低,按用户用词判定) + 发生情境 + 当前替代方案 + 主题归类
2. 心智模型:用户拿它和什么类比?「它应该像 X 一样」+ 理想流程 + 交互预期 + 角色差异
3. 边界场景与失败模式:每个「如果……会怎样」+ 频次 + 类型(用户行为/系统/数据/部分失败) + 设计含义
4. 成功标准:用户眼里「运行良好」长什么样?显性指标 + 任务完成标准 + 质量指标 + 对比基准
5. 跨主题洞察:所有人都提的(普遍需求) / 多数人提的(强信号) / 仅一人但关键的(边缘创新) /
矛盾点 / 未明说的假设 / Top 5 必须项
最后输出「设计含义(建议)」:核心交互模型 / 关键安全机制 / 反馈需求 / 错误处理 / v1 范围 / v2-v3 延后项。
铁律:量化一切;用原话引用;标注矛盾;以设计者思维串联痛点→心智模型→成功标准;
保持怀疑——标注「说的」和「做的」不一致之处;严格区分致命 vs 可选。
Severity judgment anchors(so AI does not rely on gut feeling): Critical = "I can't complete my work / it blocks me / wastes several hours"; High = "very frustrating / major problem / happens all the time"; Medium = "annoying / wish it were better"; Low = "minor hassle / no big deal".
Why this framework is valuable: It forces AI to output quantifiable, evidence-backed content that can directly connect to design decisions, instead of a bunch of nonsense like "users generally report that the experience needs improvement". Among them, "stay skeptical and mark inconsistencies between what users say and what they do" is the most easily overlooked and most valuable rule — users say they want A, but their behavior is B, and such contradictions often hide real insights.
Prompt skeleton B: Single core question → insight card (UX Insight Card)
Use this when you have only one clear question and want to quickly produce an insight card that "can be pasted into a project page". The output tone should be research conclusion, not a tutorial:
请基于以下输入,生成一条「用户研究洞察卡片(UX Insight)」。
【核心问题】{{必填}} 【核心结论(如有)】{{选填}}
严格按结构输出:
1. Insight 标题:一句话总结结论,判断明确,语气偏研究结论不偏营销
2. 用户背景与情境:用户是谁 + 真实限制条件(别假设用户理性或有耐心)
3. 行为与事实发现:2-3 条「被观察到的行为/事实」,用具体时间/频率/习惯,不用抽象形容词
4. 用户原话 Quotes:2 条代表性原话,口语化,体现不同侧面情绪,标 Participant A/B
5. 设计/产品启示:2-3 条可执行原则,用「应该/必须/不应」强约束表达
整体:偏判断不偏描述;偏「告诉设计师该怎么做」不偏「发生了什么」。
Why separate the two skeletons: A is "a pile of raw materials → panoramic report" (suitable for summarizing after a round of interviews), B is "one judgment → one card" (suitable for standardizing expression when you already have a conclusion, or for letting AI force your vague feelings into structure). The prompt in B that says "do not assume users are rational or patient" is critical; it prevents AI from generating a bunch of false insights about "ideal users".
2. Communicating insights clearly: the sample → behavior → commonality → insight reporting structure
Having insights is not enough; you need to make bosses/teams believe it is not your subjective judgment. The core structure:Anchor conclusions with a small amount of key data.
Counterexample ❌: "Users feel the page information is unclear" (purely subjective, unverifiable) Positive example ✅: "Among 12 users, 8 repeatedly switched between modules after browsing the core information, staying an average of 2–3 times or more; the main reason was being unable to judge the credibility of the information, and the core problem was ultimately summarized as 'insufficient decision-making trust'."
5 expressions that must be avoided: ① Purely subjective conclusions (users feel...) ② Only talking about methods without results (we did interviews — so what?) ③ Only talking about phenomena without synthesis (users stall — that is just an observation) ④ Conclusions staying at the surface level (find it troublesome, complicated) ⑤ No sense of sample (some users... not credible).
Professional reporting sentence template(stringing "scenario type → data positioning → user research supplements causality → behavioral evidence → insight wrap-up" into one paragraph):
在这个项目中,我们先基于数据判断当前属于一个【场景类型】问题。
当时数据表现是【数据现象】,通过分析发现问题集中在【问题范围】。
但数据只能告诉我们这个环节有问题,无法解释用户为什么这么决策,所以引入了用户研究。
我们招募了【样本量】位目标用户,覆盖【用户结构】,用【研究方式】让他们完成【关键任务】。
过程中发现,约【比例,如 70-80%】的用户在【关键行为节点】会出现【重复行为:反复查看/停顿/返回】,
平均【次数或时长】,他们普遍面临的核心问题是【共性问题1】;
同时有【次要比例】的用户在【补充场景】下出现【共性问题2】。
归纳这些行为和访谈后,我们发现一个更本质的问题是:【核心洞察(行为→结论)】。
Why this structure is a "portfolio / reporting artifact": It transforms "I feel based on gut" into "sample + behavior + reproducible synthesis". It has great transfer value for PMs — when you present any data conclusion to your boss, applying "data locates the problem → user research explains the reason → behavioral evidence → one-sentence insight wrap-up" immediately raises credibility by a notch.
3. User research visualization: let AI help you select charts + generate code
Applicable scenarios: You have a user research report or a segment of data, and want to make presentation/portfolio-level charts, but don't want to struggle with what chart to use or write code by hand.
Core judgment logic: the number of charts depends on the "number of conclusions", not the amount of data
This is the soul of the entire set of visualization prompts. Let AI run through a judgment before drawing:
- Question structure: Single relationship (A/B comparison, trend, funnel) / multi-factor / causal breakdown (funnel drop-off, path)
- Information density test: If everything is crammed into one chart, does it take the user more than 3 seconds to understand? If yes → split into multiple charts
- Number of conclusions: 1 conclusion = 1 chart; multiple conclusions = multiple charts.Expressing multiple conclusions in one chart is prohibited
Prompt skeleton: User research data → chart plan + ECharts code
你是数据可视化专家 + UX 研究分析师。我会提供:用研方法 / 研究过程(样本/分组/路径) /
数据结果(数值/趋势/对比/分布/转化)。
请完成三件事:① 提炼最关键的业务问题 ② 判断用一张图还是多张图 ③ 生成最能表达核心结论的图(含代码)。
强约束:数据全部来自输入不许编造;每张图只表达一个核心结论;删除无关数据;
图表类型必须匹配数据结构;输出可直接用于作品集/汇报。
执行步骤:
1. 图表策略判断(单图/多图,给 Reason)
2. 每张图的 Core Insight:一句话,必须有业务指向(转化/留存/收入/行为变化)
3. Chart Type:从 比较/趋势/分布/构成/转化 里选一个,格式「Chart Type: xxx — because xxx」
4. Chart Data:结构化 JSON(title / x_axis / y_axis / series / highlight),highlight 必须指向关键差异/峰值/下降点
5. Design Spec:视觉重点(第一眼看什么) + 信息层级 + 是否用强调色/弱化非重点 + 关键标注
6. 完整可运行 HTML(基于 ECharts),含 highlight 逻辑和 annotation
禁止:一图多结论 / 展示全部数据而非关键数据 / 图表类型错误(如饼图表趋势) / 没有视觉重点 / 没高亮关键数据。
核心原则:控制读图认知成本 < 3 秒。
Three-step iteration method(from practical workflow, can be used in sequence): ① User research data + prompt → output code; ② Paste the code + "output visualization chart based on original data" → get an editable chart; ③ Upload a reference chart (you can copy a certain chart type from §4 Chart 80) + "change to the chart type of the reference image" → switch styles. You can also skip code and directly generate images (e.g., "extract funnel data separately and generate an English chart with Bar Chart"), or use tools like lovart.ai to generate images directly.
Why "one chart per conclusion + 3-second rule" is a foundational literacy for PMs: The most common way to fail in portfolios and boss presentations is "cramming ten metrics into one chart, so viewers don't know where to look". This set of prompts solidifies into a process the idea of "first figure out what one sentence you want this chart to make people remember, then delete everything that does not serve that sentence". Even if you don't use AI to draw charts, this judgment logic itself should be internalized every time you make a PPT.
4. PM/UX quick reference for selecting among 80 chart types (Chart 80)
Applicable scenarios: You have a type of data and want to know "what chart to use". Will compiled 80 chart types, each marked with "how to read it + what data it suits + UX/PM scenarios". Here they are summarized into 6 families + highlighting the most commonly used ones for PMs (this article does not embed images; it uses text descriptions).
| Family | What problem it solves | High-frequency PM charts (highlighted) | One-sentence selection guide |
|---|---|---|---|
| Comparison | Comparing magnitudes across categories | Bar · Column · Grouped Bar · Bullet · Radar · Quadrant | Use bar charts for discrete categories + one numerical value; use grouped bar charts for version/AB multi-metric comparison; use bullet charts for KPI target vs actual; use radar charts for multi-dimensional scoring |
| Correlation | Whether there is a relationship between two variables | Scatter · Bubble · Heatmap | Use scatter plots to see correlation between two metrics; add a third dimension (size) with bubbles; use heatmaps for matrix-style strength/weakness |
| Part-to-Whole / Hierarchy | Proportions & nested structures | Pie/Donut · Stacked Bar · Funnel · Treemap · Sunburst | Use pie charts for categories with small proportions; use funnels for each stage of conversion; use treemaps/sunbursts for information architecture hierarchies |
| Temporal | Changes over time | Line · Area · Gantt · Bump | Use line charts for long-term trends (do not use bar charts); use Gantt charts for scheduling; use Bump charts for ranking fluctuations |
| Distribution | How data is dispersed | Histogram · Box Plot · Beeswarm · Violin | Use histograms to view distribution shape; use box plots to view medians/outliers |
| Geospatial & Other | Geography / Relationships / Flow | Choropleth · Sankey · Chord · Network · Flow | Use Sankey diagrams for user path traffic; use network diagrams for relationship networks; use choropleth maps for geographic distribution |
The 5 counterexamples PMs should remember most(Using the wrong chart is worse than not drawing one at all):
- ❌ Using pie charts to express trends → ✅ Always use line/area charts for trends
- ❌ Using bar charts for long time spans → ✅ Line charts are clearer when there are many time points
- ❌ Using pie charts when there are far too many categories (it becomes messy beyond 5-6 categories) → ✅ Switch to bar charts or treemaps
- ❌ Drawing a mess of arrows for user paths → ✅ Use Sankey diagrams to see traffic direction and volume
- ❌ Using ordinary bar charts to view "goal completion" → ✅ Use bullet charts to see target vs actual vs ranges at a glance
Why PMs need to understand chart selection: You don't necessarily have to draw them yourself, but you need to be able to judge "Is this chart provided by the designer/analyst correct, and is it misleading?" The most frequent pitfalls are "pie charts with too many categories" and "using pie charts to present trends." Remember one sentence:Chart type must match data structure——Comparing category sizes → bar charts; viewing trends → line charts; viewing proportions → pie/stacked charts; viewing flow → Sankey diagrams; viewing distribution → histograms/box plots.
V. AI Eyetracking Testing: Upload screenshots to view attention flow (Eyetracking)
Applicable scenarios: The interface is not yet live, you do not have access to real eyetracking equipment, but you want to know "Where will users look first, and will key information be ignored?" AI tools (such as attentioninsight.com) can simulate and generate heatmaps based on screenshots.
Extremely simple to use: Input an interface screenshot → Output an AI-simulated attention heatmap (red = high attention, blue = ignored).
The key is being able to interpret 4 scanning patterns(which determine whether your content structure is correct):
| Scanning pattern | What it looks like | What it indicates | How to use it |
|---|---|---|---|
| F-pattern | Attention is concentrated on the left side + the first few lines, forming an F-shape | Users are scanning quickly, not reading word by word;A large amount of information is ignored | Warning signal — indicates the wall of text is too thick; add subheadings/lists |
| Spotted | Attention is scattered across keywords, numbers, and bullet points | Lists and keywords are extremely effective for scanning | Make key points into lists + bold keywords to guide attention |
| Layer-cake | Skips layer by layer along bold subheadings | Subheading hierarchy is clear, and users are "looking for the steps they need" | Good signal — indicates your heading structure is working |
| Commitment | Almost reads the full text completely | Users have high interest or strong motivation (e.g., about to take a quiz) | Rare; indicates the content itself is highly attractive |
Important risk control:Gaze ≠ Comprehension. Heatmaps can only show that users "looked" but not that they "understood." "More fixations" does not equal "deeper understanding" (it may mean they couldn't understand and were searching repeatedly). AI simulation is even more of a "prediction" rather than real physiological data; it can only be used as an early reference and cannot replace real testing.
Best practices (scan-friendly pages): Add clear subheading hierarchies / use lists and highlight keywords / keep paragraphs to 1-3 lines / place important information at the start of paragraphs / leave enough white space for the eyes to have "resting points" / avoid "walls of text."
Why it is useful for PMs: When you review a detail page/landing page, you often debate "Is this selling point placed prominently enough?" AI eyetracking gives you a low-cost objective reference——Throw the design draft in to run a heatmap; if the core CTA is blue (no one is looking at it), you have evidence to demand adjustments, instead of getting into a back-and-forth of "I don't think it's prominent enough."
VI. Comparative scoring of multiple UI options: 6-dimension expert review (Options Scoring)
Applicable scenarios: You have 2-3 UI options, and before conducting user testing, first run a round of strict expert critique with AI to quickly eliminate obviously problematic options.
6 scoring dimensions (total score 90)
| Dimension | Full score | Core question |
|---|---|---|
| Primary users | 10 | Can high-frequency, proficient users complete tasks efficiently? (Speed/click efficiency/cognitive load) |
| Secondary users | 10 | Can new/low-frequency users understand it? (Learnability/discoverability/guidance) |
| Edge users | 10 | Is it still usable in extreme scenarios? (Mobile/poor network/one-handed use/distracted use) |
| Business Fit | 10 | Does it fit the business scenario? (Trust/industry maturity/enterprise-level applicability) |
| Accessibility | 40 | Can users with special needs use it? (Per WCAG 2.1 AA: contrast/focus visibility/keyboard operability/click target size) |
| Scalability | 10 | Will it break when complexity increases later? (Engineering feasibility/responsiveness/large data volumes/empty states) |
Note that accessibility accounts for 40 points (nearly half), deliberately elevating "whether it can be used by everyone" to the top weight — this is the dividing line between professional UX and "just looking good."
Prompt skeleton: Multiple UI screenshots → comparison matrix + deduction table
The soul is every score must be mathematically explainable: Start from the full score for each dimension; every point deduction must include a "precise issue tag + plain-language explanation + deduction value," and ultimately "starting score − total deductions = final score."
我是高级产品设计师,要在用户测试前对设计概念做严苛的专家级批评。已上传 [X] 套设计概念截图。
项目背景:产品 / 功能流程 / 行业 / 阶段(原型前-概念评审) / 概念数量。
请扮演跨学科高级评审小组(高级 UX + 产品设计 + 无障碍专家 + 软件架构师 + 性能工程师 + 行业专家)。
毫不留情,像真实生产团队一样思考,不要假客气。
评分规则:每维从固定满分起,每项扣分 = 问题标签 + 通俗解释 + 扣分值;最终「起始分 − 总扣分 = 最终分」;禁止无依据打分。
维度与满分:主要用户10 / 次要用户10 / 边缘用户10 / 商业适配10 / 无障碍40(按WCAG 2.1 AA) / 可扩展性10 = 总分90
输出:先出「对比矩阵」(每维 × 每个概念的分数 + 总分),再按顺序出每维的详细扣分表。
强制:引用明确 UI 证据 / 数学化打分 / 严厉直接 / 聚焦实际 UX 与工程现实。
禁止输出:高管摘要 / 优势分析 / 正面反馈 / 推荐方案 / 泛泛评论 / 填充废话。只要对比矩阵 + 扣分表。
Why "every point is mathematically explainable" counters sloppy design: The biggest flaw in scoring by AI (and humans) is saying "I think this is a 7 and that's an 8" without being able to state where the difference lies. Mandating "start from full score, deduct point by point, every deduction must have a reason" turns vague preferences into an arguable, traceable checklist. Even if you don't use AI, this scoring method of "anchoring to full score + itemized deductions + every deduction must be evidence-based" can be directly applied to any comparative scoring decision in your team (vendor selection, solution PK). "Prohibiting output of positive feedback/recommended solutions" is intentional — this prompt is only responsible for finding flaws, leaving the final call to you to avoid AI making decisions for you.
VII. Underlying cognition: How data and user research divide work across 4 types of projects
Why "do user research when we already have data"? Because data and user research each have their own ceilings. Divide digital product projects into 4 categories, and you'll see clearly at a glance:
| Project type | What data can do | Data's ceiling | What user research fills in | Recommended user research methods |
|---|---|---|---|---|
| Optimization(Stable data, seeking improvement) | Locate bottlenecks: which step has low conversion | Can only optimize existing paths; cannot discover new paths | Discover better paths + identify real motivations | Usability testing / task interviews / path observation |
| Anomaly(Data decline) | Locate the problem position: where the drop happened | Cannot explain "why it suddenly changed" | Restore the cause of failure (misunderstanding/trust drop/cost increase) | Churned user interviews / behavior replay / comment analysis |
| Validation(Launching new features) | Judge whether results changed (up/down/flat) | Cannot judge "whether the change is valuable" | Explain how the change is perceived + whether the value holds | A/B testing + interviews / first-use testing |
| Discovery(New direction) | Describe the status quo: what users are doing | Only covers already-occurred behaviors; cannot discover new needs | Define real tasks + discover unmet needs | In-depth interviews / contextual observation / diary studies / alternative analysis |
One-sentence mnemonic: Optimization — data finds bottlenecks, user research finds opportunities; Anomaly — data locates, user research explains; Validation — data sees results, user research sees whether value is understood; Discovery — data sees the status quo, user research defines the problem.
4 types of user psychology when growth is stuck + corresponding tactics(Extremely practical when exploring growth opportunities):
- Don't understand → Explain the value in one sentence + provide replicable examples so users can get started immediately
- Don't trust → Credible endorsements + verifiable evidence (data/reviews/third-party certifications)
- Not urgent → Scenario-based time-sensitive benefits / limited-time mechanisms to make "doing it now a better deal"
- Don't dare → Low-risk trial + guarantees (revocable/refund/privacy commitments) to reduce decision cost
Why this is the outline of the entire article: The previous 6 AI workflows all serve this table. First determine "which category my project falls into," and you will know whether data or user research should take the lead, which research method to use, and what kind of insights AI should help you extract.The easiest pitfall for anomaly-type projects is "when data drops, assume needs have changed" — in fact, attribution should be ruled out layer by layer in the order of technical issues → version changes → external market factors → user cognition. The first three layers are matters for data/engineering; only after they are ruled out does it become user research's turn to explain "why users stopped doing it."
VIII. Quick reference: Research methods ↔ visualization outputs (User research types and visualization results)
Every user research method has its "naturally appropriate chart." Bind methods to visualizations, and when you take on a type of research, you'll know exactly what to produce:
| User research method | What question it answers | Typical visualization outputs |
|---|---|---|
| Kano model | Which features are must-haves/performance enhancers/delighters/indifferent | Kano four-quadrant chart (Must-be/One-dimensional/Attractive/Indifferent) |
| RCA root cause analysis | Where the root cause of the problem lies | Fishbone diagram / 5-Why tree |
| Service Blueprint | How frontstage and backstage systems collaborate to support a service | Swimlane diagram (customer journey + frontstage/backstage/system layers) |
| Journey Map | Users' emotional ups and downs and experience points across the full process | Journey curve (stage × emotion) |
| Tree Testing | Whether users can find things in the information architecture | Task success rate table (path + success rate %) |
| User interviews / emotion words | Differences in how different groups feel about the same thing | Venn diagram (shared/differentiated vocabulary) + word frequency bar chart |
| Card Sorting | The categorization logic in users' minds | Similarity matrix / standardized grid / Dendrogram |
| User path analysis | Where they enter → where they go → where they exit | Sankey diagram (node traffic direction) |
| Drop-off analysis | Which stage loses the most users | Funnel chart (entry/completion/conversion rate per step) |
| Heatmap | Which parts of the page are ignored/misclicked | Scroll heatmap / click heatmap |
| Eyetracking | Whether attention flows to expected locations | Heatmap / fixation plot / scanpath diagram (see §V) |
| A/B testing | Which version performs better | Comparison table (conversion per version + probability of beating baseline) + bar chart |
There is also a six-stage "UX optimization closed loop"framework that strings the entire process together: Preparation → UX analysis → hypothesis formation → prioritization of optimizations (P1/P2/P3) → implementation → performance evaluation, then back to analysis for iterative cycles.
Why this table is a "translator": It translates the abstract "I did card sorting" into the concrete "so I should produce a similarity matrix + dendrogram." When a PM receives any research method, following this table tells them what chart to have AI generate next (using the prompts in §III), without having to figure it out from scratch.
IX. Apply this set of methods to your AI product
As a PM building AI products, the specific transfer value of this phase for you:
- Every time batches of user feedback come in(app store reviews, customer service records, interviews), first run a structured synthesis using Skeleton A in §I, instead of manually reading them one by one. You only make the judgment of "whether this insight holds."
- When presenting data conclusions to bosses/investors, use the "data positioning → user research explanation → behavioral evidence → one-sentence insight" structure from §II, and your credibility will immediately be different.
- When doing competitor/solution comparisons, use the "start from full score, deduct item by item" scoring method from §VI to turn back-and-forth arguments into traceable checklists.
- When judging whether your product should currently prioritize data or user research, first match it against the 4-category project table in §VII. For AI chat products, "why is retention dropping" is often an anomaly-type issue — first rule out technical/version factors, then use user research to explain "why users stopped chatting."
- All AI outputs are drafts. The essence of this entire system is:Let AI handle 80% of the manual labor of organizing, synthesizing, drawing charts, and scoring, leaving your time for the most irreplaceable 20% — judging which insight is real and which direction to take.
and Google UX Certificate / UX Research and Empathy - Definition / AI-Assisted UX · Discovery & Research Phase (Prompts and Workflows for Using AI to Define Business/Experience Goals, MVP Metrics, Problem Positioning, User Research Reports, and Background Infographics) relationship: Discover & Research comes earlier — defining research objectives, recruiting participants, and conducting interviews; this Define & Insight piece follows right after it — turning research outputs into insights and decisions. google-ux-research provides the shared manual foundational craft for both phases (interview SOPs, affinity diagrams, usability studies, strong insight standards).Reading all three pieces together = the complete chain of "how to set research objectives → how to conduct research → how to turn results into design decisions".