产品设计不是凭感觉拍板，而是有章可循的判断过程。本文提出四层框架：价值过滤、边界界定、体验设计与闭环验收，并串联RICE、Kano、尼尔森原则等实用工具，帮助产品经理把模糊需求转化为可验证、可交付的决策。

“人人都是产品经理”这句话，我一直觉得只说对了一半。

说对的是，人人都能感知产品好不好用，也有资格提出建议；没说完的是，有产品意见不等于能完成产品设计。普通人可以表达偏好，产品经理则要用经验和理论把偏好变成判断，并为结果负责。

产品经理既是名词，也像形容词：前者是一份职业，后者是一种把问题拆清、在约束中取舍、用结果验证的工作方式。经验告诉我们原则何时失效，理论则让零散经验可以迁移，二者缺一不可。

做产品这些年，我把工作中真正用得上的产品设计原则重新整理了一遍，拆成四个层次：价值过滤、边界界定、体验设计和闭环验收。四层有先后，但不是瀑布流程；遇到新证据、新风险或兼容问题，仍要退回前一层重新判断。

先看四层框架。

如果只记住一件事，就记住这四个问题：

该不该做 → 做多少、动了谁 → 怎样更容易完成 → 凭什么证明完成

下面出现的模型和定律，都是帮助回答这四个问题的工具。

一、价值过滤：先判断该不该做

产品设计的起点不是页面，而是证据。这一层可以连续过四道筛。

证据先于需求

Lean UX（精益用户体验）可以理解为：先把想法写成假设，再用尽可能小的成本验证，而不是一上来就做完整方案。

业务方说“用户找不到入口”，只是线索。用户是否真的在这里流失？是入口不明显，还是不理解功能价值？工单、行为数据、访谈和可复现的用户任务，才会提高判断的可信度。

优先级就是机会成本

RICE 是一种需求排序方法，分别比较触达人数（Reach）、影响程度（Impact）、证据置信度（Confidence）和投入（Effort），公式是“触达 × 影响 × 置信度 ÷ 投入”。

它的价值不是制造一个绝对正确的分数，而是逼团队说清楚：选择这件事，要推迟什么。风险不属于 RICE 原公式，应单独评估。

基本需求先于惊喜需求

Kano 模型按照需求对满意度的影响，将其区分为基本型、期望型和兴奋型。讲人话，基本型是“没有就不能接受”，兴奋型是“有了会惊喜”。

在许多账号产品中，注销可能很低频，却比个性化装饰更基础。但分类不是永久标签，仍要结合具体用户和场景验证。

核心场景优先于长尾完整

帕累托法则常被称为“二八法则”，提醒我们少数关键场景可能贡献大部分价值。它是一种寻找价值分布的启发，不是所有产品都天然符合 80/20。

因此，这一层只看四件事：证据、机会成本、基本预期、核心场景。

四个问题连起来，就是价值过滤漏斗。

通过漏斗，不等于方案已经成立。

二、边界界定：想清楚做多少、动了谁

价值成立，只说明值得继续研究，不代表范围已经清楚。边界层要检查四类影响。

权限不能只看按钮

RBAC（基于角色的访问控制）是一种通过角色给用户分配权限的方法，回答的是“谁能对什么对象做什么”。因此，按钮隐藏只解决界面可见性，服务端仍要校验权限，数据层还要限制可访问范围。

先计算存量影响

新功能进入的不是白纸，而是已有用户、历史数据、操作习惯和上下游关系。老用户是否要重新操作？旧数据如何解释？旧客户端会不会失效？这些迁移成本和信任损失，也属于产品范围。

合规与安全是硬约束

合规不是与收益平级的普通选项。以个人信息为例，《个人信息保护法》要求处理目的明确、与目的直接相关，并控制在最小范围内，不能因为“转化率可能更高”就跳过。行业规则也要说明适用范围，不能把特定行业要求包装成通用原则。

复用必须有证据

YAGNI 是“You Aren’t Gonna Need It”的缩写，意思是不要为尚未出现的未来需求提前建设。抽象会带来理解和维护成本；只有多个真实使用方存在稳定共性，且复用收益高于复杂度时，平台化才成立。

这一层记住四个词：权限、存量、底线、复用。

边界审查聚焦四类影响。

边界画得越晚，返工代价越大。

三、体验设计：不是更漂亮，而是更容易完成任务

进入体验设计后，讨论才落到页面、流程和交互。判断标准不是“更漂亮”，而是用户能否理解、完成并在出错后回来。

让系统状态可见

尼尔森可用性原则是一组检查界面是否易用的经验规则，其中第一条就是及时告诉用户系统正在发生什么。除加载、成功和失败，还要考虑空态、无结果、无权限、部分成功和异步处理中。

例如，工单提交后不能只弹一句“成功”，还要告诉用户工单编号、当前状态、下一步，以及失败时是否保留已填写内容。

符合用户的现实心智

“心智模型”是用户基于过去经验形成的操作预期。系统内部叫“鉴权令牌失效”，用户只需要看到“登录已过期，请重新登录”。同一种删除操作也不应在不同模块出现多套规则，否则用户每次都要重新猜。

防错，也允许恢复

Poka-yoke（防错设计）原本来自制造业，意思是让错误难以发生或能被及时发现。落到产品里，高风险操作既要有约束、默认值和必要确认，也要考虑撤销、回收站、版本记录或补偿机制。确认弹窗不是恢复方案。

让复杂度服从任务

席克定律讲的是：选择越多，做决定通常越慢。有限工作记忆则提醒我们，用户一次能处理的信息有限。但米勒的“7±2”研究的是短时记忆容量，不是菜单选项上限。

更稳妥的做法是按任务分组、渐进披露，只在当前步骤展示必要信息，而不是为了数字好看删除必要选项。

为高频操作缩短路径

菲茨定律说明，目标越大、距离越近，操作通常越快。因此高频动作要放在合理位置，并提供足够大的点击区域。面向熟练用户，还可以提供批量处理、快捷键、模板和默认值，但不要把新手路径堆满高级功能。

把可访问性当成基础质量

WCAG（Web 内容无障碍指南）要求内容可感知、可操作、可理解，并能被不同设备和辅助技术可靠识别。如果用户无法通过键盘完成任务，或读屏软件读不懂错误提示，这项功能对他们实际上并不存在。

这一层只用一个结果检验：用户能否在正常和异常情况下完成任务。

六条体验原则都指向任务完成。

所谓极简，也必须服务任务完成。

四、闭环验收：不是功能跑通，就算设计完成

验收动作通常落在交付后段，但验收标准必须在设计阶段出现。否则，“体验顺畅”“操作方便”“兼容旧版本”都无法直接判定。

完成必须可验证

BDD（行为驱动开发）是一种用行为描述需求的方法，常用 Given、When、Then 表达“在什么前提下，执行什么动作，应出现什么结果”。产品经理不必拘泥格式，但结果必须可观察、可判定。

正向与负向成对验收

正向验收证明理想条件下能工作，负向验收证明错误条件下不会失控。工单正常提交只是第一步；无权限、重复点击、网络超时、依赖失败、并发请求和安全重试也要覆盖。

这里常见的“幂等”，讲人话就是同一个请求重复执行，不能产生多份不该重复的数据。

兼容要验证存量价值

Google AIP-180是一份面向系统接口（API）的兼容设计指南，它把兼容拆成源码、通信和语义等层面。产品经理不必掌握协议细节，但要检查旧用户、旧数据、旧流程、旧客户端和上下游契约有没有被破坏。

功能正确不等于质量合格

ISO/IEC 25010是一套软件产品质量模型。它提醒我们，功能只是质量的一部分；性能、可靠性、安全、隐私、数据一致性和可访问性，也应按实际风险进入验收。

上线是最后一次验证

灰度发布是先向小范围用户释放版本，观察结果后再逐步扩大。上线前要明确看哪些指标、什么情况暂停、谁有权回退，以及如何确认回退有效。涉及数据迁移或不可逆操作时，还需要备份、补偿、恢复或向前修复方案。

把这些要求收束起来，就是五道验收关。

通过标准不是“都测过”，而是能判定、能止损、能恢复。

写在最后

回到“人人都是产品经理”。如果它只是说每个人都能感知问题、提出建议，我同意；如果它被理解为任何产品直觉都等同于专业判断，我不同意。

职业产品经理的价值，不是拥有最终解释权，而是把模糊意见变成可验证、可取舍、可交付的判断，并为后果负责。具体工作时，我会按这个顺序问自己：

1. 价值过滤：这件事该不该做？
2. 边界界定：做多少，会影响谁？
3. 体验设计：怎样让用户更容易完成任务？
4. 闭环验收：凭什么证明真的完成了？

理论名称可以忘，但判断顺序不能乱。人人都能表达偏好，产品经理必须形成判断；两者之间隔着的，正是被理论整理过的经验，以及被经验校正过的理论。