产品设计实践
理论要落地。这一章给你一套从想法到上线的具体操作流程。
1. 阶段一：问题定义（动手之前最重要的事）
软件工程里有句话：“一个被正确定义的问题，已经解决了一半。”
很多功能失败的原因不是技术，是方向错了——我们解决了一个没有人真正在意的问题。
1.1 用“问题陈述”代替“需求文档”
传统需求文档往往描述的是解法（“加一个按钮”），而不是问题。
更好的起点是写一个问题陈述（Problem Statement）：
[用户类型] 在 [具体情境] 下，需要 [完成的任务]，
但目前 [存在的障碍/摩擦]，导致 [负面结果]。
示例（好的问题陈述）：
商户在结算日需要确认各笔订单是否已付款，但目前只能逐一发微信追问， 耗时且遗漏风险高，导致对账不及时，甚至与租户产生纠纷。
示例（坏的需求描述）：
加一个订单付款状态汇总页面。
前者告诉你为什么要做，后者只告诉你做什么。只有理解了前者，你才能判断后者是不是正确的解法。使用这个框架解决问题还有一个好处，那就是你会发现这是一个完美的 prompt！
1.2 5 Whys（五问法）
对任何需求，连续问 5 次“为什么”，直到找到根本原因。
示例：
- 需求：给合同页加一个“下载 PDF”按钮
- Why 1：为什么要下载 PDF？ → 租户要打印合同备份
- Why 2：为什么要打印备份？ → 担心电子合同不被认可
- Why 3：为什么担心不被认可？ → 遇到纠纷时不知道该提供什么证据
- Why 4：为什么不知道该提供什么证据？ → 平台没有说明电子合同的法律效力
- 根本原因：用户对平台的电子合同缺乏信任和了解
更好的解法可能是： 在合同页展示电子合同的法律说明，以及一键获取平台盖章版本的方式，而不只是 PDF 下载。
2. 阶段二：用户验证（在开发前验证假设）
2.1 快速原型验证
不要用代码去验证概念，用纸或 Figma 就够了。
验证层级（从低成本到高成本）：
| 层级 | 工具 | 适合验证 | 成本 |
|---|---|---|---|
| 纸质草图 | 纸笔 | 核心流程是否合理 | 30 分钟 |
| 静态 Figma | Figma | 界面布局和信息层次 | 2-4 小时 |
| 可点击原型 | Figma 交互 | 完整操作路径是否顺畅 | 半天 |
| HTML 原型 | 简单网页 | 真实交互感受 | 1-2 天 |
| MVP 代码 | 真实开发 | 技术可行性 + 用户反应 | 数天-数周 |
关键原则：在层级最低的地方，能解答你的疑问就停下来，不要做过度验证。
2.2 用户测试的最简做法
找 3-5 个真实用户，给他们一个任务，然后闭嘴观察。
不要说： “你觉得这个设计怎么样？”（引导性问题）
要说： “假设你现在想查看上个月的租赁付款记录，请操作给我看。”（任务式测试）
观察他们：
- 在哪里停顿了？
- 他们点击了什么不该点的地方？
- 他们看哪里找功能，但没找到？
- 他们说了什么，哪怕是叹气或皱眉？
3 个用户已经足够发现 80% 的主要可用性问题（Nielsen Norman Group 的研究结论）。不需要做 100 人的测试才能得出结论。
3. 阶段三：MVP 设计原则
MVP（最小可行产品）不是“随便做个垃圾版本”，而是用最少的工作量，验证最重要的假设。
3.1 什么应该在 MVP 里
要包含的：
- 核心价值主张（用户选择你而不是竞品的原因）
- 主干路径（用户完成核心任务的最短路径）
- 基本的错误处理（不 能让用户在关键步骤卡死）
不需要在 MVP 里的：
- 边缘情况的完整处理（先记录，后续迭代）
- 高级功能和“锦上添花”的细节
- 完美的视觉设计（够用就好）
- 复杂的后台管理工具（先手动处理）
3.2 从核心流程出发设计
画出用户完成核心任务的最短路径，然后问：每一步是否真的必要？
示例：租赁付款功能的核心流程
理想路径（5步）：
首页 → 待付款提醒 → 确认金额 → 完成支付 → 看到成功凭证
每一步的必要性检查：
- 首页提醒：必要（入口）
- 确认金额：必要（避免支付错误金额）
- 完成支付：必要（核心操作）
- 成功凭证：必要（安全感，减少重复操作和客诉）
如果加了"选择支付方式""输入备注""分享给联系人"→ 这些是否真的必要？
3.3 用 RICE 评分排优先级
当有多个功能要做时，用 RICE 方法打分：
| 维度 | 含义 | 示例评分 |
|---|---|---|
| Reach（覆盖面） | 每月有多少用户会用到这个功能？ | 50 个商户 |
| Impact（影响力） | 对这些用户的影响有多大（1-3 分）？ | 3（高影响） |
| Confidence（信心） | 我们对以上估算有多大把握（%）？ | 70% |
| Effort（工作量） | 需要多少工程人月（越小越好）？ | 0.5 人月 |
RICE 分 = (R × I × C) / E = (50 × 3 × 0.7) / 0.5 = 210
分数越高，优先级越高。这个方法的价值不在于精确数字，而是让决策显式化，避免靠感觉排优先级。
4. 阶段四：开发中的产品意识
代码在写的时候，产品思维不能停。
4.1 微决策的产品影响
开发过程中有无数个“微决策”，每一个都会影响用户体验：
| 微决策 | 只考虑技术 | 考虑产品 |
|---|---|---|
| 错误信息怎么写 | error.message 直接展示 | “支付失败，请检查微信余额或稍后重试” |
| 加载时怎么处理 | 空白等待 | 骨架屏 + 合理的超时处理 |
| 空状态怎么处理 | 空列表，什么都不显示 | “暂无租赁订单，点击发布你的第一件上架物品” |
| 操作成功怎么反馈 | 无反馈或控制台 log | Toast 提示 + 数据刷新 |
| 用户权限不足 | 403 错误页 | “此功能仅认证商户可用，去完善认证信息？” |
这些决策合在一起，决定了用户是觉得“这个 App 很专业”还是“感觉不太靠谱”。
4.2 边界情况也是产品设计
开发者容易只想到主干路径，但用户会走各种奇怪的路径。
在开发前，强迫自己想清楚以下场景：
- 如果网络断了怎么办？
- 如果数据为空（第一次使用）怎么办？
- 如果用户连续点击按钮两次怎么办？
- 如果操作超时怎么办？
- 如果用户中途退出，再回来状态是否正确？
这些不是“高级功能”，是基本产品完整性的要求。
5. 阶段五：上线即学习
上线不是结束，是学习的开始。
5.1 上线后的第一个 24 小时
| 时间点 | 检查项 |
|---|---|
| 上线后 1 小时 | 查看云函数错误日志，有没有新的报错？ |
| 上线后 6 小时 | 新功能的核心操作有没有真实用户使用？ |
| 上线后 24 小时 | 用户反馈渠道（群聊/表单）有没有相关问题？ |
5.2 建立最简单的数据反馈
不需要复杂的数据平台，最简单的方式是在关键操作点记录日志：
// 关键操作：租赁付款成功
console.log(JSON.stringify({
event: 'lease_payment_success',
userId: tenantId,
amount: paymentAmount,
contractId: contractId,
ts: Date.now()
}));
// 关键操作：租赁付款失败
console.log(JSON.stringify({
event: 'lease_payment_failed',
userId: tenantId,
reason: error.code,
ts: Date.now()
}));
定期查看这些日志，你会发现：哪些操作频繁失败？哪些功能从未被使用？哪些路径是用户的高频行为？
5.3 迭代的心态：每次上线都是假设验证
把每个功能当成一个假设：
假设：如果我们在付款页面显示历史记录，
商户的催收电话数量会 减少。
验证方式：
- 上线后 2 周，对比催收款项相关的客服问题数量
- 对比付款成功率（有记录参考是否会降低焦虑）
结果判断：
- 如果符合预期 → 继续强化这个方向
- 如果无明显变化 → 探索是否还有其他原因
- 如果反向变化 → 了解原因，调整设计
6. 工具箱：实用资源
6.1 用于产品思考的问题清单
需求质疑：
- 这个功能解决谁的什么问题？
- 用户现在是怎么解决的？
- 如果不做这个，最坏的影响是什么？
- 成功的衡量标准是什么？
设计决策：
- 最简单的方案是什么？
- 可以在不写代码的情况下验证这个假设吗？
- 边界情况都考虑到了吗？
- 第一次用的用户能直觉性地明白怎么用吗？
上线后：
- 有没有人用这个功能？
- 用的人是我们预期的那类用户吗？
- 他们在哪里卡住了？
- 最常见的操作路径是什么？