1. 理解用户验证的价值
在《Figma原型快速验证用户需求教程》的开篇，我们需要先达成一个共识：产品经理和设计师最昂贵的错误，不是写了有 Bug 的代码，而是构建了一个无人问津的完美功能。用户验证，正是避免这一悲剧的核心手段。
不同于传统的“交付即结束”，验证驱动的开发模式强调用最小的成本，在投入研发资源之前，确认方案与用户真实需求的匹配度。它的核心目标包括：
- 风险排除：在编码前发现逻辑漏洞、流程断点或认知偏差。
- 方向对齐：确保团队成员、业务方和用户对“要做什么”达成一致理解。
- 成本压缩：修复一个原型上的错误，成本远低于修改已发布的线上代码。
- 证据积累：用真实的用户反馈数据，而非主观臆断来支撑产品决策。
💡 核心认知：验证不是质量检查，而是风险投资决策。每一次验证都是在用极低的成本，购买一个“确认方向正确”的保险。
1.1 验证（Validation）与测试（Verification）的区别
许多刚接触验证的同学容易混淆这两个概念。虽然中文翻译相近，但在产品研发语境下，两者有本质不同：
| 对比维度 | 用户验证（Validation） | 功能测试（Verification） |
|---|---|---|
| 核心问题 | 我们是否在做正确的事？ | 我们是否正确地做事？ |
| 验证对象 | 需求、流程、界面方案、商业逻辑 | 代码逻辑、数据库、接口、性能 |
| 执行阶段 | 需求分析阶段、设计阶段（早期） | 开发阶段、测试阶段（后期） |
| 参与者 | 真实用户、业务方、产品经理 | 开发工程师、测试工程师 |
| 失败代价 | 产品无人使用，商业目标失败 | 功能 Bug，系统崩溃，需重新发布 |
📌 记忆辅助：“Verification（确认）”确保“产品符合规格说明书”；“Validation（验证）”确保“产品符合用户真实需求”。本课程全部内容聚焦于后者。
1.2 快速迭代闭环：Figma 的核心作用
传统瀑布流开发模式下，用户验证往往发生在产品上线之后，成本极高。敏捷开发虽然缩短了周期，但通常仍需要开发资源介入。本课程推崇的Figma 快速验证闭环，将验证节点大幅前移至设计阶段：
使用 Figma 进行快速验证，可以将传统数周甚至数月的反馈周期压缩到几天甚至几小时。以下是传统开发流程与我们倡导的验证流程的核心差异：
| 阶段 | 传统开发流程 | Figma 快速验证流程 |
|---|---|---|
| 方案确认 | 需求文档（PRD）评审 | 可点击原型 + 用户任务演练 |
| 首次验证 | 开发完成，进入测试环境 | 低保真原型绘制完毕 |
| 反馈成本 | 高（需重写代码、调整数据库） | 极低（仅需调整图层和交互逻辑） |
| 协作方式 | 产品 → 设计 → 开发 → 测试（串行） | 产品 + 设计 + 业务方 + 种子用户（并行） |
| 最终质量 | 依赖需求文档的严谨度 | 依赖真实用户反馈的迭代次数 |
⚠️ 常见误区：过早进入高保真
很多产品经理和设计师在第一个版本就花费大量时间打磨像素级细节，这会导致两个问题：一是沉没成本高，不愿轻易推翻方案；二是用户的注意力会被视觉细节吸引，而忽略了核心流程的体验。在快速验证阶段，优先使用低保真（Wireframe）或中保真原型进行核心逻辑闭环的验证。
1.3 本章核心交付物：验证目标清单
在开始任何原型设计前，请先使用以下清单明确你的验证目标：
- 本次要验证的核心假设是？（例如：用户希望在一个页面内完成报销申请）
- 目标用户群体是谁？（例如：入职 1-3 年的初级员工）
- 成功指标是什么？（例如：用户在 3 分钟内完成报销流程，无需外部帮助）
- 准备了几套方案？（例如：方案 A（列表式） vs 方案 B（引导式））
- 预期验证结论是什么？（例如：方案 B 的任务完成率比方案 A 高 20%）
这个验证目标清单将贯穿整个课程。你现在需要建立的思维是：验证不是最后一步，而是每一步。带着假设去画图，带着问题去访谈，带着指标去迭代。