用乔布斯标准做产品与设计评审：从客户体验倒推、做减法…

当你需要评审一个设计、产品或功能是否足够简单、聚焦且端到端卓越时，用乔布斯式评审协议给出可执行的删减清单与修复清单。

适用场景

解决思路

1. 从客户体验出发倒推技术与功能：评审任何产品都从用户看到、感受到、能完成什么开始，而不是从功能列表、组织架构或现成技术出发；牢记“设计不只是外观和手感，设计是它如何运作”。
2. 按 7 项快速诊断打分：统计产品通过几行，7/7=10、6/7=9、5/7=7、4/7=6、3/7=4、≤2/7≤3；9-10 分=insanely great 可发布，5-8 分=需要真正的删减与修复，≤4 分=未完成、退回做 demo；没有“还不错”，必须给出分数、失败的具体行、以及达到 10/10 所需的具体删减或修复。
3. 做简单性审计：持续做减法，直到再删一个元素就会破坏产品目的；衡量“到达核心价值的步数”（如注册→首次价值 3 步而非 9 步）；优先用一个好的默认值替代设置项；如果必须解释才能懂，就重新设计；每个屏幕只表达一个意图、只留一个主按钮。
4. 执行“说不”的聚焦仪式：对路线图强制排序后砍掉第 3 名以下的一切；每新增一个功能就必须砍掉一个（kill-for-every-add）；合并重叠的 SKU/套餐；承认已发布的功能也可以删除，删除本身就是功能；每个周期都要有明确说“不”的清单。
5. 把设计当作“它如何运作”来评审：要求看交互而非静态稿，点击走通各个状态；评审最慢的时刻（冷启动、空状态、离线、错误恢复）而非只走顺利路径；设定体验预算（如首屏 <1s，否则评审不通过）；把延迟当作设计缺陷；拒绝与功能对抗的装饰性美感。
6. 端到端拥有整个体验：把发现、购买、首次运行/开箱、上手、日常使用、失败、支持、账单、离开都当作产品界面来评审；把首次 60 秒当作主题演讲般排练；审查发票、错误邮件、取消流程这些通常没人设计的表面；用最差触点决定感知质量。
7. 用 demo 而非规格或幻灯片评审：禁止纯幻灯片评审，要求 Figma 原型或真实构建；在目标设备、目标数据规模上评审；先原型化风险最高的时刻；对竞争方案跑 demo derby 并只选一个；每周向决策者做 30 分钟 demo 取代状态文档；demo 必须展示真实状态，隐藏已知问题的演示等于带 UI 的谎言。
8. 守住“栅栏背面”的品味标准：审查没人演示的界面（404、空状态、错误文案、设置页、加载页、邮件），把它们提升到首页标准；大声朗读每一条文案；用团队最好的作品而非平均水平来批评；问“你会在里面签上自己的名字吗？”；把品味当作可训练的能力，研究伟大产品并说出它们为何伟大。
9. 按固定协议运行评审：会前先以客户身份冷启动体验产品（第一印象无法重来）；开场先陈述产品承诺，然后只测试这个承诺；反馈必须具体可执行（说清是什么、在哪里、为什么、修复方向），“这很让人困惑”本身也不通过评审；结尾给二元结论——可发布，或一份排序的修复清单，绝不说“再打磨一下”；由一个决策者拥有结论，输入可以广泛但决策必须收窄。
10. 始终按固定格式输出评审：# Design Review: [产品/功能]；**Verdict:** INSANELY GREAT / NOT DONE (score X/10)；**The One Thing:** [它必须做到的一件事]；**Keeps its promise?** [是/否 + 证据]；**Cut list:** [要删除什么]；**Fix list:** [排序、具体、带修复方向]；**Back of the fence:** [未达标的不可见表面]。
11. 避免常见错误：不只评审美学（要走过流程、延迟和失败状态）；不用增加功能来解决问题（先做减法，新增必须伴随删除）；不做共识式结论（委员会会把想法平均成糊状）；不评审规格和幻灯片；不给“足够好”的结论；不跳过不可见表面；不扮演残酷（对工作残酷，对人体面）。
12. 用快速诊断逐项检查：能否一句话说出这个产品必须做的那件事？新用户能否在 ≤3 步内到达核心价值？评审者是否以客户身份冷启动体验过？是否有真实设备上的可运行 demo？本周期是否删掉了什么？错误、空、边界状态是否达到主屏质量？团队是否愿意每天自豪地使用并在上面签名？任何一项为否，就按对应行动处理。

适用边界 · 注意事项

• 不适用于纯视觉设计基础评审（如配色、排版规范），那应参考 refactoring-ui 之类的技能。
• 不适用于可用性启发式审计，那应参考 ux-heuristics 之类的技能。
• 不适用于微交互细节打磨，那应参考 microinteractions 之类的技能。