steve-jobs-design-review

Steve Jobs 设计评审

像 Steve Jobs 一样开展设计和产品评审：从客户体验出发，不断删减，直到只剩下精髓；凡是还没有做到极致出色的东西，都不能称为完成。

核心原则

“你必须从客户体验出发，再反向推导技术。” 评审每款产品时，都要从客户看到什么、感受到什么、能完成什么出发——而不是从功能列表、组织架构图，或恰好现成可用的技术出发。还要记住这个标准：“设计不只是外观和感受。设计关乎它如何运作。”

评分

目标：10/10。 统计产品通过了多少项快速诊断的 7 条标准，再映射到 0-10 分：7/7 = 10，6/7 = 9，5/7 = 7，4/7 = 6，3/7 = 4，≤2/7 ≤ 3。分数区间：9-10 = 极致出色，可以发布；5-8 = 必须进行实质性删减和修复；≤4 = 尚未完成，回到演示阶段。没有“还不错”这一说；要明确给出分数、未通过的具体标准，以及达到 10/10 所需的具体删减或修复。

框架

1. 简约是复杂的极致

核心概念： 简约不是没有功能，而是征服了复杂性。不断删减，直到再去掉任何东西都会破坏产品的目的。

为何有效： 用户必须感知、理解或判断的每个元素，都会消耗注意力、削弱信心。深入理解问题后实现的简约，会让人觉得理所当然；靠隐藏东西实现的简约，则会让人觉得产品出了问题。

关键见解：

• “要把东西做简单，需要付出大量艰苦努力，真正理解底层的挑战，并想出优雅的解决方案。”
• iPod 没有配备开关——它是通过设计消除了需求，而不是把按钮藏起来
• 衡量达到价值所需的步骤：Jobs 要求三次按键就能播放任意歌曲；最初的 iDVD 方案是打开一个窗口、拖入视频、点击“刻录”
• 一个好的默认选项胜过一个设置；每一项偏好设置，都意味着你没有替用户做出决定
• 如果必须解释，就重新设计——说明书就是道歉

评审应用：

场景	应用方式	示例
功能审查	统计用户获得核心价值所需的步骤；删掉主流程之外的一切	注册 → 3 步内获得首次价值，而不是 9 步
UI 评审	移除元素，直到屏幕只表达一个意图	每个屏幕只设一个主按钮
设置审查	用有主见的默认选项取代各种选项	始终自动保存；不提供切换开关

评审提示：

• “我们可以删掉什么，同时让它运行得更好吗？”
• “这个东西为什么在这里？谁要求的？核心用户需要它吗？”
• “用一句话解释这个屏幕。做不到？那它应该拆成两个屏幕——或者干脆不要。”

道德边界： 通过替用户解决复杂问题来实现简化，绝不能把必要的控件或费用（定价、隐私、取消）藏到用户找不到的地方。

进行简约审查时，请参阅 references/simplicity-and-focus.md，了解 5 步删减法、达到价值所需步骤的衡量方法，以及表层简约与深层简约对照表。

2. 专注意味着说不

核心概念：“专注就是要说不。”决定不做什么，与决定要做什么同样重要——创新就是对 1,000 件事说不。

**为何有效：**把精力分散在许多还不错的事情上，最终一件了不起的事也做不成。砍掉好的创意，才能让团队最优秀的人才把注意力集中在少数重要的产品上，并避免产品变成委员会的愿望清单。

关键洞见：

• 1997 年，Jobs 将 Apple 的数十款产品砍到只剩一个 2×2 矩阵：消费级/专业级 × 台式/便携式——专注拯救了公司
• 在休整会上，团队的十大优先事项被砍到只剩三个：“我们只能做三件事”
• “对于我们没做的事情，我和已做的事情一样自豪”
• 如果路线图上没有最近砍掉的项目，那就不是专注，而是未经审视
• 说不也包括已经发布的功能——删除也是一种功能

评审应用：

场景	应用方式	示例
路线图评审	强制排序，然后砍掉排名第 3 之后的所有项目	Q3 计划：3 个重点，而不是 14 个待办事项
范围蔓延	每增加一项，都必须砍掉一项	新增一个仪表板小组件 = 淘汰一个
产品线	合并重叠的 SKU/层级	每种客户类型只保留一个方案

评审提示：

• “如果本季度只能发布一件事，应该是哪件？为什么其他项目还没砍掉？”
• “这个产品刻意在哪方面做得不好？”
• “这个周期我们拒绝了什么？什么都没有？那我们就是在接受平庸。”

**伦理边界：**对范围说不，绝不对证据说不——砍掉功能是战略；无视与愿景相悖的用户痛点，则是自负。

有关说不的惯例，请参见 references/review-protocol.md——强制排序并精简至三项的练习、每增加一项就必须砍掉一项的规则，以及如何在现场评审中列出拒绝清单。

3. 设计关乎产品如何运作

**核心概念：**设计不是最后才加上的表面修饰——它决定了产品的行为架构。评判流程、速度和故障状态，而不只是样稿是否美观。

**为何有效：**用户体验到的不是截图，而是延迟、错误、中断和操作流程。无论外观多好看，如果产品运行卡顿、丢失工作内容，或在出错时让人不知所措，那就是糟糕的设计。

关键洞见：

• iPhone 键盘的成功靠的是行为（激进的自动更正），而不是视觉效果——工程和设计是一门学科
• 评审最慢的时刻，而不是顺畅流程：冷启动、空状态、离线、错误恢复
• “就是能用”是一项设计规范：零配置、零手册、零繁文缛节
• 与功能相冲突的美感只是装饰，应当拒绝
• 延迟是一种设计属性——等待 2 秒就是设计缺陷，无论它发生在技术栈的哪一层

评审应用：

场景	应用方式	示例
样稿评审	要求展示交互，而不是静态画面	逐一点击查看状态，而不是翻阅幻灯片
性能	在评审中设定体验指标预算	首屏耗时 < 1 秒，否则评审不通过
故障设计	逐一检查错误/空状态/离线路径	支付失败 → 用户清楚知道接下来该怎么做

评审提示：

• “给我看看出错时会发生什么。”
• “用到第 100 次时，感觉如何？而不是演示时。”
• “用户要在哪里等待？我们对此做了什么？”

评审行为而非视觉效果时，请参见 references/end-to-end-experience.md——日常使用和故障/支持阶段会讲解如何检查演示中常被跳过的缓慢环节、错误路径和离线状态。

4. 掌控完整体验

核心概念： 产品涵盖每个接触点：发现、购买、开箱或首次运行、引导、日常使用、故障、支持、账单和离开。审视完整体验，不要孤立地看应用。

为何有效： 客户会把体验视为一个整体。Apple 打造开箱仪式、自营门店和 Genius Bar，是因为再好的设备，如果卖得不好或支持态度粗鲁，留在记忆中的也会是糟糕的产品。

关键见解：

• Apple 的包装经过设计实验室级别的打磨——第一印象也是产品的一部分
• 首次运行就是你的开箱体验：用户在第 0 分钟看到的内容，值得像主屏幕一样精心设计
• 支持工单、发票和取消流程都是产品界面——通常却无人设计
• 团队之间的每次交接（营销 → 引导 → 产品 → 支持）都是体验断层显露之处
• 端到端梳理整个旅程；最糟糕的接触点决定感知质量

评审应用：

场景	应用方式	示例
发布评审	将每个接触点作为一段完整旅程进行审查	广告承诺与首次运行的实际体验相符
引导	把首次使用当作一场演出	像主题演讲一样排练前 60 秒
生命周期	审查账单、支持和退出流程	取消只需一个屏幕，并维护用户尊严

评审提示：

• “带我走一遍，从听说这个产品到愿意推荐它——哪里会出问题？”
• “发票是谁设计的？错误邮件呢？取消流程呢？”
• “售出之后，体验是否仍兑现承诺？”

伦理边界： 掌控完整体验也意味着对失败负责——绝不要设计精致的入口，却设置充满敌意的出口。

梳理用户旅程时，请参阅 references/end-to-end-experience.md——其中介绍了从发现到退出的 7 阶段接触点地图、最差接触点原则，以及导致界面无人设计的组织断层。

5. 没有演示，就等于不存在

核心概念： 评审可运行的成果，而不是规格说明或幻灯片。具体演示能揭示文档掩盖的真相；由决策者对真实产品作出反应，进而推动决策。

为何有效： 抽象描述会让每个人想象出不同的产品，最终无法达成共识。以真实尺寸在真实设备上演示，会促使反馈具体明确、及早暴露致命问题，并通过决策而非委员会式拖延达成共识。

关键见解：

• Apple 的软件文化（Kocienda 所说的“创意筛选”）：制作演示，展示给决策者，获得直接反馈，再迭代——这个循环就是流程
• iPhone 键盘是通过多个可运行方案的角逐选出的，而不是依据需求文档
• 在目标设备上、以目标数据规模进行评审——在投影仪上评判手机 UI，会歪曲实际效果
• 首先为风险最高的环节制作原型；只演示轻松完成的 80%，毫无证明作用
• “真正的艺术家会交付”：演示的目的是推动决策，而不是拖延决策

评审应用：

场景	应用方式	示例
设计评审	禁止只看幻灯片的评审	使用 Figma 原型或实际构建版本，绝不只看静态演示文稿
竞争方案	举办演示角逐，选出一个	构建两个导航模型，作出一个结论
利益相关方达成共识	每周向决策者演示	用 30 分钟演示取代 3 份状态文档

评审提示：

• “别说给我听——演示给我看。就在设备上。”
• “这两个演示哪个更好？选一个；我们不会发布两者折中的方案。”
• “风险最高的假设是什么？验证它的演示在哪里？”

伦理边界： 演示必须呈现真实状态——隐藏已知故障的摆拍演示，就是披着 UI 外衣的谎言。

制定演示驱动的评审流程时，请参阅 references/demo-culture.md——其中介绍了创意筛选循环、如何举办演示角逐、决策者的职责，以及诚实演示规则。

6. 品味与围栏背面

核心概念： 优秀的木匠不会在柜子背面使用胶合板，即使没人看得到。投入心力打磨看不见的表面，以及打磨者的品味，才是真正的品质。

为什么有效： 用户会在潜意识中感受到匠心：像素对齐、文案连贯、边界情况处理得体，这些都会累积成信任。团队如果在“没人看的地方”偷工减料，就会让自己养成处处偷工减料的习惯；卓越是一种由标准来约束、而非靠检查来保证的习惯。

关键见解：

• 最初的 Mac 团队会在机箱内部签名；Jobs 曾要求工程师重新设计电路板布局，只为追求顾客看不到的美感
• “光有技术还不够”——产品诞生于技术与人文艺术的交汇处
• 审查围栏背面这些不起眼的地方：空状态、错误文案、设置页面、加载画面、电子邮件
• “要成为品质的标杆”——优秀的人才会彼此提升；纵容平庸会让问题不断累积
• 品味可以培养：研究优秀的产品，阐明它们优秀的原因，并毫不妥协地贯彻标准

评审应用：

情境	应用方式	示例
细节审查	检查那些没人会演示的界面	404 页面也要达到首页的标准
文案审查	把每一条文案都大声读出来	错误消息听起来自然、具体
团队标准	以最佳作品为标准，而非平均水平	“这是你做过最好的作品吗？”

评审提示：

• “给我看看产品里最难看的界面——那才是我们真正的品质底线。”
• “你愿意在里面签上自己的名字吗？”
• “我们在哪些地方用了胶合板？”

参见 references/case-studies.md，了解这一标准的实际案例：为打造无人可见的美感而重新设计最初 Mac 的电路板、iMac 大胆做减法的设计取舍，以及 MobileMe 和天线门事件的失败复盘，以及这些案例分别能教给评审者什么。

7. 开展评审

核心概念： 让评审有章可循：像客户一样，在没有预先了解的情况下体验产品，指出它必须完成的唯一要事，根据原则 1-6 逐项审查，然后给出二元结论——优秀至极，或尚未完成——并列出具体的删减项和修复项。

为什么有效： 评审常因含糊和客气而失效。固定的演示顺序、毫不留情的具体意见和二元结论，能防止“差不多就行”的产品上线，同时为团队提供一条通往 10/10 的明确路径。产品应根据自身承诺来评判——“它应该做什么？那它为什么没有做到？”

关键见解：

• 开会前一定要在没有预先了解的情况下体验产品——第一印象无法重来
• 以承诺开场：说清产品声称能做什么，然后只测试这一点
• 反馈必须具体且可执行：“这让人困惑”这种意见也无法通过评审——要说清是什么、在哪里、为什么，以及修复方向
• 以二元结论收尾：要么值得发布，要么列出按优先级排序的修复项；绝不要说“稍微润色一下”
• 由一位决策者负责最终结论；广泛听取意见，集中做出决策

始终按以下格式输出评审：

# Design Review: [Product/Feature]
**Verdict:** INSANELY GREAT / NOT DONE (score X/10)
**The One Thing:** [what this must do]
**Keeps its promise?** [yes/no — evidence]
**Cut list:** [what to remove]
**Fix list:** [ranked, specific, with fix direction]
**Back of the fence:** [unseen surfaces that fail the bar]

实际开展评审会议时，参见 references/review-protocol.md，了解限时的 5 步议程、修复项具体性测试、坦诚规则（对工作严厉，对人尊重）、评审节奏，以及如何将该流程调整用于个人或异步评审。

常见错误

错误	为什么行不通	修正方法
只评审美观	设计关乎产品如何运作；好看却笨拙，用户照样不买账	走查工作流、延迟和故障状态
通过增加内容来解决问题	每次增加都会占用注意力，还会滋生更多复杂性	先做减法；新增内容必须有明确的删除项
以共识作为结论	委员会会把想法折中得平庸无奇	由一人拍板，广泛听取意见，谨慎做决定
评审规格说明和幻灯片	抽象内容会掩盖致命缺陷；每个人想象中的产品都不一样	要求在真实设备上提供可运行的演示
给出“还不错”的结论	平庸会不断累积，最终损害品牌	非此即彼：极其出色，否则就不算完成
忽略不显眼的界面	用户能感受到粗制滥造；团队也会学着偷工减料	检查空状态、错误状态、设置和邮件状态
假装严厉	恐惧会让人不敢演示、不敢坦诚，从而扼杀反馈循环	对工作成果严厉，对人友善

快速诊断

问题	如果答案是否	行动
你能用一句话说清这个产品必须做好的唯一一件事吗？	缺乏重点——所有事情都成了优先事项	写下来；删掉不服务于这件事的内容
新用户能否在 ≤3 步内体验到核心价值？	复杂性尚未攻克	梳理实现价值所需的步骤；删减，而非调整顺序
评审者是否像客户一样，在没有预先介绍的情况下亲自体验了产品？	你评审的是团队讲述的故事，而不是产品	会前先亲自使用，不要安排讲解
是否有在真实设备上运行的演示？	你批准的是想象中的产品	重新安排评审，直到有演示为止
本轮是否删掉了任何内容？	路线图在不断堆积，而非聚焦	每次评审都加入一份删减清单
错误、空白和边缘状态是否与主屏幕一样出色？	围栏背面只是粗制滥造的夹板	检查并修复不显眼的界面
团队是否会自豪地每天使用这个产品，并署上自己的名字？	标准是“过得去”，而非“极其出色”	等到团队真正感到自豪，再给出非此即彼的结论

作者简介

Steve Jobs（1955-2011）与他人共同创立了 Apple，并带领公司打造了 Mac、iPod、iPhone 和 iPad，通过以设计为主导的产品开发，将公司发展为全球最具价值的企业。这项技能提炼了他在 Walter Isaacson 的授权传记、Ken Segall 的 Insanely Simple 和 Ken Kocienda 的 Creative Selection 中记载的评审实践与标准。

延伸阅读

这项技能基于 Steve Jobs 产品与设计评审实践的记录：

• "Steve Jobs"，Walter Isaacson 著
• "Insanely Simple: The Obsession That Drives Apple's Success"，Ken Segall 著
• "Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs"，Ken Kocienda 著