需求强度、可用性和付费意愿回答的是三个不同问题，证据来源也不同：需求强度看问题是否真实且值得解决，可用性看用户能否顺利完成关键任务，付费意愿看用户是否愿意为此付出代价。本文按这三类问题给出方法选择、操作步骤、角色分工和完成检查，帮助你把验证结论整理成可支撑决策的证据。验证过程中的访谈记录、假设状态与结论，可以在ONES这类研发协作平台中随需求和工作项一并沉淀。
要点总览（TL;DR）
- 需求强度、可用性、付费意愿对应不同证据来源：需求强度看问题是否真实且值得解决，可用性看用户能否完成关键任务，付费意愿看用户是否愿意付出代价。
- 需求强度优先用问题访谈配合线索数据交叉验证，样本覆盖现有用户、流失用户和目标新用户，结论按强、中、弱、不成立分档。
- 可用性优先用原型测试暴露任务路径问题，A/B测试需满足流量、指标定义与实验周期条件，灰度发布用于控制上线风险，不替代任务测试。
- 付费意愿用价格访谈、报价测试、预售或付费意向测试获取意向与行为证据，只有口头意愿时结论应表述为初步意向。
- 同一功能按需求强度、可用性、付费意愿顺序分阶段验证，前一段结论不成立时停止后续投入，验证记录与决策结果随需求一并沉淀。
先分清三类验证问题，再选方法
方法选错，往往不是执行不认真，而是一开始要回答的问题就没界定清楚。用访谈去证明可用性，或用灰度发布的上线数据去推断付费意愿，都会得到看似有数据、实际无法支撑决策的结论。先判断当前要回答哪类问题，再选方法。
三类问题的验证目标与判断标准
需求强度验证的目标是确认“这个问题真实存在，且值得投入解决”。判断标准包括：目标用户能具体描述问题发生的场景与频率；问题造成的损失或成本可以说明；现有替代方案存在明显不足；多个独立来源指向同一问题。
可用性验证的目标是确认“用户能否顺利完成关键任务”。判断标准包括：关键任务完成率达到预设阈值；完成时间与操作步骤在可接受范围；严重可用性问题已识别并分级；用户对操作路径的理解与设计预期一致。
付费意愿验证的目标是确认“用户是否愿意为此付出代价”。判断标准包括：用户在明确价格条件下表达购买意向；出现真实付费行为或可验证的付费承诺；价格敏感区间可以描述；不同用户群体之间的付费意愿差异可以解释。
方法选择表
| 验证问题 | 推荐方法 | 证据形式 | 常见误用 |
|---|---|---|---|
| 需求强度 | 问题访谈、需求线索数据交叉验证、方案前调研 | 访谈记录、问题频次与场景描述、工单/搜索/流失原因数据 | 拿功能偏好访谈当需求验证；只问“你会用吗” |
| 可用性 | 原型测试、可用性测试；流量与指标条件满足时用A/B测试 | 任务完成率、完成时间、错误记录、问题分级清单 | 样本过少就下统计结论；用灰度发布替代任务测试 |
| 付费意愿 | 价格访谈、报价测试、预售、付费意向测试；灰度发布观察真实转化 | 价格接受区间、付费意向记录、预售订单、转化数据 | 把口头“愿意买”直接当成付费证据 |
同一功能的分阶段验证顺序
同一功能通常按需求强度、可用性、付费意愿的顺序推进。需求强度不成立时，后续的原型测试和报价测试都缺少意义，应停止投入或调整方向。需求强度成立后，先用原型测试解决“用户能不能用”，再进入价格与付费测试。灰度发布放在可用性和付费意愿阶段使用，用于观察真实使用与转化，不宜单独作为付费意愿证据。
验证需求强度：访谈与线索数据怎么配合
需求强度验证的核心动作是问题访谈加线索数据交叉验证。访谈负责还原问题场景，数据负责检验问题是否普遍、是否持续。两者结论一致时，需求强度结论才可靠。
问题访谈的输入与提问方式
访谈输入包括：待验证的问题假设、目标用户名单、访谈提纲和记录模板。提问围绕过去发生的事实展开，例如“最近一次遇到这个问题是什么时候”“当时你怎么处理的”“为此花了多少时间或成本”。追问具体事件、频率和影响，比询问未来意愿更有信息量。
避免引导性提问。不要问“如果有一个功能能解决这个问题，你会用吗”，也不要先介绍方案再问感受。把方案描述放到访谈后段，且只用于确认理解，不作为需求强度证据。
样本选择
样本至少覆盖三类人：现有用户中高频使用核心流程的人，流失用户或放弃使用的人，目标新用户中符合画像但尚未使用的人。三类样本回答的问题不同：现有用户提供场景细节，流失用户暴露未满足的需求，目标新用户检验问题是否普遍存在。每类样本数量不必多，但要保证每类都有覆盖，并记录样本来源与筛选条件。
可交叉验证的线索数据
- 搜索数据：相关关键词的搜索量与变化趋势。
- 工单与客服记录：同类问题的出现频次、处理耗时。
- 销售反馈：成单与丢单原因中反复出现的问题描述。
- 流失原因：取消订阅、停止使用时的填写内容与回访记录。
线索数据的作用是检验访谈结论是否被独立来源支持。访谈中反复出现的问题，如果在工单和流失原因中也有对应记录，需求强度结论更可信；如果访谈结论在数据中找不到痕迹，需要补充样本或重新界定问题。
判定标准与记录字段
需求强度结论建议按“强、中、弱、不成立”四档判定。判定依据包括：问题出现的用户比例、发生频率、造成的可量化损失、现有替代方案的满意度。记录字段至少包含：假设编号、访谈对象类型、问题场景、发生频率、影响描述、对应线索数据、结论档位、待补充证据。
输出物是一份需求强度结论与证据清单，每条结论都能追溯到具体访谈记录和数据来源。
验证可用性：原型测试与A/B测试的取舍
可用性验证优先用原型测试，因为它能在开发投入前暴露任务路径上的问题。A/B测试用于比较两个已上线或可运行的方案，前提是流量和指标定义都满足条件。灰度发布用于控制真实环境中的风险，不替代任务测试。
原型测试的任务设计与观察记录
任务脚本围绕关键任务设计，每条任务写明：任务目标、起始状态、成功标准、允许的提示次数。例如“请找到修改收货地址的入口并完成修改”，成功标准是进入正确页面并保存成功。测试过程中记录完成情况、完成时间、操作路径、卡点位置和用户口头反馈。
观察记录采用统一模板，测试结束后按严重程度分级：阻断级（任务无法完成）、严重级（需要提示才能完成）、一般级（完成但路径绕行）、建议级（体验优化）。分级结果直接对应修复优先级。
A/B测试的适用前提
A/B测试需要满足三个条件：有足够流量使两组样本量达到统计判断要求；指标定义明确，例如任务完成率、关键按钮点击率、流程转化率；实验周期覆盖完整的用户行为周期。条件不满足时，A/B测试的差异可能来自随机波动，结论不可靠。样本量估算应在实验开始前完成，避免看到结果后再决定是否继续。
灰度发布在可用性验证中的角色与局限
灰度发布让部分真实用户先使用新版本，用于观察错误率、崩溃率、关键路径成功率等运行指标。它能发现测试环境难以复现的问题，但用户不会按任务脚本操作，因此难以判断“某个任务是否可完成”。灰度发布适合作为上线前的风险控制手段，与原型测试配合使用。
判定标准与输出
可用性结论以关键任务完成率和严重问题数量为主要依据。阻断级问题未清零前，不建议进入更大范围发布。输出物包括可用性问题清单、每条问题的分级与修复建议、验证记录（测试时间、样本、任务脚本、结果）。
验证付费意愿：从价格访谈到付费意向测试
付费意愿验证要区分“表达意愿”和“付出代价”。价格访谈和付费意向测试提供方向性判断，预售和灰度发布中的真实转化提供行为证据。结论中应写明证据类型和不确定性。
价格访谈的提问结构与常见偏差
价格访谈通常按以下结构展开：先确认用户当前如何解决该问题及相应支出，再询问可接受的价格区间，然后给出具体报价询问购买意向，最后询问影响决策的因素。提问时给出明确的产品范围和价格条件，避免笼统询问“你觉得值多少钱”。
常见偏差包括：锚定偏差，先给出的价格影响后续判断；礼貌偏差，用户不愿当面否定价格；假设偏差，用户对尚未使用的产品高估自己的购买行为。减少偏差的做法是给出多个价格点分别询问，并追问“在这个价格下你会放弃哪些替代方案”。
报价测试、预售与付费意向测试
| 方法 | 输入 | 输出 | 适用条件 |
|---|---|---|---|
| 报价测试 | 多个价格档位、功能范围说明 | 各档位的意向分布、价格敏感区间 | 产品范围已基本明确 |
| 预售 | 可交付的产品承诺、定金或全款条件 | 实际订单数、退款率 | 能在承诺周期内交付 |
| 付费意向测试 | 落地页或试用入口、明确价格 | 留资转化率、试用转付费率 | 有可触达的目标流量 |
灰度发布观察真实付费转化的条件
灰度发布用于观察真实付费转化时，需要满足：灰度用户具有代表性；定价与正式方案一致；观察周期覆盖用户的决策周期；转化数据可按用户群体拆分。灰度阶段的转化率可以作为付费意愿的参考证据，但样本量不足时不宜外推到全量用户。
结论判定与不确定性说明
付费意愿结论建议写明三层信息：意向层面的结论（价格区间与意向比例）、行为层面的结论（预售或转化数据）、不确定性说明（样本量、观察周期、与正式定价的差异）。只有意向数据时，结论表述为“初步意向”，不写成“已验证付费意愿”。输出物是付费意愿验证结论与后续定价决策依据，包括建议价格区间、需要继续观察的指标和下一步验证计划。
角色分工与验证记录怎么留
三类验证涉及产品、设计、研发、数据和业务多方，职责不清时容易出现访谈做了没人整理、测试问题没人跟进的情况。每类验证都应明确输入、动作、输出和完成标志。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品经理 | 提出假设、设计访谈提纲、组织结论评审、决定是否进入下一阶段 | 假设清单、需求强度结论、阶段决策记录 |
| 设计师 | 制作原型、设计任务脚本、主持原型测试、整理问题分级 | 原型、任务脚本、可用性问题清单 |
| 研发 | 支持A/B测试与灰度发布的技术实现、埋点与发布控制 | 实验配置、埋点说明、灰度发布记录 |
| 数据分析 | 定义指标口径、估算样本量、输出实验结果与转化分析 | 指标定义文档、实验分析报告 |
| 业务与销售 | 提供客户线索、参与价格访谈、反馈成单与丢单原因 | 客户反馈记录、报价测试结果 |
每类验证的完成标志不同：需求强度以结论档位和证据清单齐备为完成；可用性以阻断级问题清零、问题清单归档为完成；付费意愿以意向与行为证据齐备、不确定性已说明为完成。
验证记录建议统一存放，每条记录包含假设、方法、样本、证据、结论和决策结果，并与对应需求关联。这样后续复盘时能追溯“当时为什么做这个判断”。在ONES中，需求可以承载假设与结论字段，访谈纪要和测试报告可以放在关联文档中，阶段评审结论随工作项状态流转，使验证过程与需求决策保持在同一处可查。
一个完整示例：新功能上线前的三段验证
以下为演示情景，用于说明方法组合与判断节点，不代表真实项目数据。
某团队计划为协作工具增加“自动生成周报”功能。待验证假设有三条：成员每周花大量时间整理周报；现有模板和复制粘贴方式效率不足；团队愿意为自动化能力支付更高套餐费用。
需求强度阶段
团队访谈了8名现有用户、4名流失用户和4名目标新用户，提问围绕最近一次写周报的过程、耗时和返工情况。同时调取工单中与周报相关的咨询记录和流失回访问卷。访谈显示周报整理耗时集中在信息汇总环节，工单和流失原因中也有对应描述。结论判定为“强”，证据清单记录了访谈编号与数据来源。
可用性阶段
设计师制作可点击原型，设计三条关键任务：生成周报初稿、修改自动汇总的内容、导出并发送。邀请6名目标用户完成测试，记录完成率、耗时和卡点。测试发现“修改自动汇总内容”环节有两名用户找不到编辑入口，定为严重级问题，修复后复测通过。此阶段未使用A/B测试，因为功能尚未上线、流量条件不满足。
付费意愿阶段
产品经理组织价格访谈，给出三档价格分别询问购买意向，并对其中一档进行小范围报价测试。结果显示价格敏感区间集中在中间档，但样本量有限。团队将结论表述为“初步意向成立，行为证据不足”，并计划在灰度发布中观察试用转付费率。灰度阶段转化数据达到预设观察阈值后，才将结论更新为“付费意愿得到行为数据支持”。
阶段衔接与停止条件
三段验证之间设置判断节点：需求强度结论为“弱”或“不成立”时停止后续投入；可用性阶段阻断级问题未清零时不进入灰度；付费意愿只有意向数据时，定价决策标注为待验证。每个节点的决策结果记录在需求工作项中，作为下一阶段的输入。
完成检查：验证结论能不能支撑决策
验证结束前，用以下清单逐项核对。任何一项不满足，都应补充验证或下调结论强度。
三类验证的完成标志
- 需求强度：访谈覆盖现有用户、流失用户和目标新用户；结论有至少两类线索数据交叉支持；结论档位与证据清单已归档。
- 可用性：关键任务脚本已执行；问题按严重程度分级；阻断级问题已修复或明确处理计划；测试记录完整。
- 付费意愿：价格条件明确；意向数据与行为数据分别记录；不确定性已写明；后续观察指标已确定。
证据充分性与样本代表性
- 样本来源、筛选条件和数量已记录，能说明为何具有代表性。
- A/B测试的样本量在实验前已估算，指标口径在实验前已确定。
- 灰度发布用户群体与全量用户的差异已说明。
结论与假设的对应关系
- 每条原始假设都有对应的验证结论，结论明确为支持、部分支持、不支持或证据不足。
- 结论中引用的证据可以追溯到具体访谈记录、测试记录或数据报表。
- 口头意愿与行为证据分开表述，未混为一谈。
需要补充验证的阻断条件
- 需求强度结论仅来自单一来源，缺少交叉验证。
- 可用性测试样本过少，或阻断级问题未处理即计划上线。
- 付费意愿仅有访谈意向，没有报价测试、预售或转化数据支撑，却要据此确定正式定价。
- 验证记录缺失关键字段，无法支撑复盘和决策追溯。
出现上述任一情况时，先补充验证再进入决策环节。验证的价值在于让决策有据可依，结论强度与证据强度保持一致，比追求“验证通过”的结论更重要。
常见问题
需求强度访谈已经做了，还需要再查线索数据吗？
建议补充。访谈能还原问题场景，但样本量有限，结论容易受个别用户影响。把访谈中反复出现的问题与工单记录、搜索趋势、销售丢单原因、流失回访问卷等独立来源对照，可以判断问题是否普遍、是否持续。访谈结论在数据中找不到痕迹时，先补充样本或重新界定问题，再给出需求强度结论。
流量不大的产品能不能用A/B测试验证可用性？
流量不足以在实验前估算出所需样本量时，A/B测试的组间差异可能来自随机波动，结论不可靠。这类情况优先用原型测试或可用性测试，通过任务完成率、完成时间和卡点记录判断问题。等产品上线、流量条件满足后，再用A/B测试比较两个可运行方案的转化差异。
灰度发布的数据能不能直接证明用户愿意付费？
灰度发布可以观察真实使用与转化，但作为付费意愿证据需要满足条件：灰度用户具有代表性、定价与正式方案一致、观察周期覆盖用户决策周期、转化数据可按用户群体拆分。样本量不足时，灰度转化率只作参考，不宜外推到全量用户。付费意愿结论应同时写明意向证据、行为证据和不确定性。
三类验证一定要按顺序做吗？可不可以并行？
常见顺序是先需求强度、再可用性、后付费意愿，因为需求强度不成立时，原型测试和报价测试缺少投入意义。部分动作可以并行，例如需求强度访谈期间同步准备原型、梳理线索数据。但阶段判断节点建议保留：需求强度结论为弱或不成立时停止后续投入；可用性阻断级问题未清零时不进入灰度；付费意愿只有意向数据时，定价决策标注为待验证。
验证记录应该包含哪些内容，放在哪里方便复用？
每条记录至少包含假设、方法、样本、证据、结论和决策结果，并与对应需求关联。访谈记录、测试报告、实验分析报告作为附件或关联文档存放，阶段评审结论随工作项状态流转。在ONES中，需求工作项可以承载假设与结论字段，访谈纪要和测试报告可放在关联文档中，后续复盘时能追溯当时的判断依据。
