Back to Details

steve-jobs-design-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Steve Jobs Design Review

史蒂夫·乔布斯式设计评审

Run design and product reviews the way Steve Jobs ran them: start from the customer experience, subtract until only the essential remains, and refuse to call anything done that isn't insanely great.
以史蒂夫·乔布斯的方式开展设计与产品评审：从客户体验出发，不断精简直至仅剩核心要素，绝不将非“极致出色”的内容视为完成状态。

Core Principle

核心原则

"You've got to start with the customer experience and work backwards to the technology." Review every product from what a customer sees, feels, and accomplishes — never from the feature list, the org chart, or the technology that happened to be available. And remember the standard: "Design is not just what it looks like and feels like. Design is how it works."
“你必须从客户体验出发，反向推导技术实现。” 从客户的所见、所感及达成的成果来评审每一款产品——绝不要从功能列表、组织架构图或现成可用的技术出发。请牢记这一准则：“设计不只是外观和手感，设计是产品的运作方式。”

Scoring

评分标准

Goal: 10/10. Count how many of the 7 Quick Diagnostic rows the product passes, then map to 0-10: 7/7 = 10, 6/7 = 9, 5/7 = 7, 4/7 = 6, 3/7 = 4, ≤2/7 ≤ 3. Bands: 9-10 = insanely great, ships; 5-8 = real cuts and fixes required; ≤4 = not done, back to demos. There is no "pretty good"; state the score, the exact rows that failed, and the specific cuts or fixes required to reach 10/10.
目标：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分=未完成，重新进行Demo演示。不存在“还不错”的评级；需明确给出分数、未通过的具体条目，以及达到10/10分所需的具体精简或修复措施。

Framework

评审框架

1. Simplicity Is the Ultimate Sophistication

1. 简洁是终极的复杂

Core concept: Simplicity is not the absence of features — it is complexity conquered. Keep subtracting until removing one more thing would break the product's purpose.
Why it works: Every element a user must perceive, parse, or decide about taxes attention and erodes confidence. Simplicity that survives deep understanding of the problem feels inevitable; simplicity achieved by hiding things feels broken.
Key insights:
  • "It takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions"
  • The iPod shipped with no on/off switch — the need was designed away, not the button hidden
  • Measure steps-to-value: Jobs demanded any song in three presses; the original iDVD pitch was one window, drag video in, click "Burn"
  • Prefer one good default over a setting; every preference is a decision you failed to make
  • If you must explain it, redesign it — instructions are apologies
Review applications:
ContextApplicationExample
Feature auditCount steps to core value; cut anything off the main pathSignup → first value in 3 steps, not 9
UI critiqueRemove elements until the screen states one intentOne primary button per screen
Settings reviewReplace options with opinionated defaultsAuto-save always on; no toggle
Review prompts:
  • "What can we remove and have this still work better?"
  • "Why is this here? Who asked for it, and does the core user need it?"
  • "Explain this screen in one sentence. Can't? It's two screens — or none."
Ethical boundary: Simplify by solving complexity for the user, never by burying necessary controls or costs (pricing, privacy, cancellation) where they can't be found.
See references/simplicity-and-focus.md when running a simplicity audit — the 5-step subtraction method, steps-to-value measurement, and the surface-vs-deep simplicity table.
核心概念： 简洁并非缺少功能，而是征服了复杂。持续精简直至再移除一项内容就会破坏产品的核心目标。
为何有效： 用户必须感知、解析或决策的每一个元素都会消耗注意力并削弱信任感。基于对问题深度理解实现的简洁会显得理所当然；通过隐藏内容实现的简洁则会让产品显得残缺。
关键见解：
  • “要让事物变得简单需要付出大量努力，你必须真正理解潜在挑战并找到优雅的解决方案”
  • iPod没有设置开关机按钮——需求被设计消除，而非按钮被隐藏
  • 衡量“价值达成步骤数”：乔布斯要求仅需3次操作即可播放任意歌曲；最初的iDVD方案是一个窗口，拖拽视频进去，点击“Burn（刻录）”即可
  • 优先选择一个优质默认选项而非可设置项；每一个偏好设置都是你未能做出的决策
  • 如果你必须解释它，那就重新设计——使用说明是设计失误的道歉
评审应用场景：
场景应用方式示例
功能审计统计核心价值达成步骤；移除主流程外的所有内容注册→首次获得价值仅需3步，而非9步
UI评审移除元素直至屏幕仅传达一个核心意图每个屏幕仅保留一个主按钮
设置评审用明确的默认选项替代可配置项自动保存始终开启；无开关按钮
评审提问：
  • “我们可以移除什么内容，让产品运作得更好？”
  • “这个内容为什么存在？谁提出的需求，核心用户真的需要它吗？”
  • “用一句话解释这个屏幕。做不到？那它应该拆分成两个屏幕——或者直接移除。”
伦理边界： 为用户解决复杂问题以实现简洁，绝不要通过隐藏必要控制或成本（定价、隐私、取消流程）的方式来简化，这些内容必须让用户易于找到。
开展简洁性审计时，请参阅references/simplicity-and-focus.md——其中包含5步精简法、价值达成步骤测量，以及表面简洁与深度简洁对照表。

2. Focus Means Saying No

2. 聚焦意味着学会说不

Core concept: "Focusing is about saying no." Deciding what not to build is as important as deciding what to build — innovation is saying no to 1,000 things.
Why it works: Effort spread across many decent things produces nothing great. Killing good ideas concentrates the team's best people and attention on the few products that matter, and protects the product from becoming a committee's wish list.
Key insights:
  • In 1997 Jobs cut dozens of Apple products to a 2×2 matrix: consumer/pro × desktop/portable — focus saved the company
  • At retreats, the team's top-10 priority list got cut to three: "We can only do three"
  • "I'm as proud of the things we haven't done as the things we have done"
  • A roadmap with no recently killed items isn't focused, it's unexamined
  • Saying no includes features already shipped — deletion is a feature
Review applications:
ContextApplicationExample
Roadmap reviewForce-rank, then cut everything below #3Q3 plan: 3 bets, not 14 backlog items
Scope creepRequire a kill for every addNew dashboard widget = retire one
Product lineCollapse overlapping SKUs/tiersOne plan per customer type
Review prompts:
  • "If we could ship only one thing this quarter, which — and why isn't the rest cut?"
  • "What is this product deliberately bad at?"
  • "What did we say no to this cycle? Nothing? Then we said yes to mediocrity."
Ethical boundary: Say no to scope, never to evidence — killing a feature is strategy; ignoring user pain that contradicts your vision is vanity.
See references/review-protocol.md for the saying-no rituals — the force-rank-to-three exercise, the kill-for-every-add rule, and how to run a no list in a live review.
核心概念： “聚焦就是学会说不。” 决定不做什么和决定做什么同样重要——创新就是对1000件事说不。
为何有效： 精力分散在众多尚可的事物上，无法创造出卓越的成果。砍掉好的想法能让团队最优秀的人才和注意力集中在少数重要产品上，避免产品沦为多方诉求的集合体。
关键见解：
  • 1997年乔布斯砍掉了数十款苹果产品，仅保留一个2×2矩阵：消费级/专业级 × 台式机/便携机——聚焦拯救了公司
  • 在团队 retreat（务虚会）上，团队的Top10优先级列表被精简至3项：“我们只能做3件事”
  • “我为我们没做的事感到自豪，正如为我们做过的事感到自豪一样”
  • 近期没有砍掉任何项目的路线图不是聚焦，而是未经审视
  • 说不也包括已发布的功能——删除本身就是一种功能
评审应用场景：
场景应用方式示例
路线图评审强制排序，砍掉排名第3之后的所有项目Q3计划：仅3个核心目标，而非14个待办项
范围蔓延每新增一项功能必须砍掉一项现有功能新增仪表盘组件→淘汰一个现有组件
产品线合并重叠的SKU/层级每种客户类型仅对应一个方案
评审提问：
  • “如果我们本季度只能发布一件事，是哪一件——为什么不砍掉其他所有内容？”
  • “这款产品刻意在哪些方面做得不好？”
  • “本周期我们拒绝了什么需求？什么都没有？那我们就是接受了平庸。”
伦理边界： 对范围说不，绝不对证据说不——砍掉功能是策略；忽视与你的愿景相悖的用户痛点是自负。
了解“说不”的实操流程，请参阅references/review-protocol.md——其中包含强制精简至3项的练习、“新增必砍”规则，以及如何在现场评审中制定否决清单。

3. Design Is How It Works

3. 设计即功能运作方式

Core concept: Design is not a veneer applied at the end — it is the architecture of how the product behaves. Judge flows, speed, and failure states, not just the mockup's beauty.
Why it works: Users don't experience screenshots; they experience latency, errors, interruptions, and sequences. A beautiful product that stutters, loses work, or confuses on failure is badly designed no matter how it looks.
Key insights:
  • The iPhone keyboard succeeded through behavior (aggressive autocorrect), not visuals — engineering and design are one discipline
  • Review the slowest moment, not the happy path: cold start, empty state, offline, error recovery
  • "It just works" is a design spec: zero configuration, zero manual, zero ceremony
  • Beauty that fights function is decoration; reject it
  • Latency is a design property — a 2-second wait is a design flaw, wherever it lives in the stack
Review applications:
ContextApplicationExample
Mockup reviewDemand the interaction, not the stillClick through states, not slides
PerformanceSet experience budgets in the reviewFirst screen < 1s or it fails review
Failure designWalk error/empty/offline pathsPayment fails → user knows exactly what next
Review prompts:
  • "Show me what happens when it fails."
  • "How does this feel after the 100th use, not the demo?"
  • "Where does the user wait, and what did we do about it?"
See references/end-to-end-experience.md when reviewing behavior over visuals — the daily-use and failure/support stages cover how to walk the slow moments, error paths, and offline states most demos skip.
核心概念： 设计不是最后才添加的装饰，而是产品行为的架构。评判流程、速度和故障状态，而非仅评判原型的美观度。
为何有效： 用户体验的不是截图，而是延迟、错误、中断和操作序列。一款外观精美但卡顿、丢失数据或故障时让人困惑的产品，无论看起来多好看，都是设计糟糕的产品。
关键见解：
  • iPhone键盘的成功源于其行为（智能自动纠错），而非视觉——工程与设计是同一学科
  • 评审最慢的环节，而非顺畅路径：冷启动、空状态、离线、错误恢复
  • “它就是能正常运作”是设计规格：零配置、零手册、零繁琐流程
  • 与功能相悖的美观只是装饰；应予以拒绝
  • 延迟是设计属性——2秒等待是设计缺陷，无论它存在于技术栈的哪个环节
评审应用场景：
场景应用方式示例
原型评审要求展示交互过程，而非静态画面点击查看状态变化，而非仅看幻灯片
性能评审在评审中设定体验预算首屏加载时间<1秒，否则未通过评审
故障设计评审走查错误/空/离线路径支付失败→用户明确知道下一步操作
评审提问：
  • “展示它故障时的情况。”
  • 使用100次后，它的体验如何，而非演示时的体验？”
  • “用户在哪里需要等待，我们对此做了什么？”
评审行为而非视觉时，请参阅references/end-to-end-experience.md——其中包含日常使用和故障/支持阶段的内容，介绍如何走查大多数演示会跳过的缓慢环节、错误路径和离线状态。

4. Own the Whole Experience

4. 掌控完整体验

Core concept: The product is every touchpoint: discovery, purchase, unboxing or first run, onboarding, daily use, failure, support, billing, and leaving. Review the whole widget, not the app in isolation.
Why it works: Customers judge the experience as one thing. Apple built unboxing rituals, its own stores, and the Genius Bar because a great device sold badly or supported rudely becomes a bad product in memory.
Key insights:
  • Packaging got design-lab treatment at Apple — first impressions are part of the product
  • The first run is your unboxing: what users see at minute zero deserves hero-screen care
  • Support tickets, invoices, and cancellation flows are product surfaces — usually nobody designed them
  • Every handoff between teams (marketing → onboarding → product → support) is where experience seams show
  • Map the journey end to end; the worst touchpoint sets the perceived quality
Review applications:
ContextApplicationExample
Launch reviewAudit every touchpoint as one journeyAd promise matches first-run reality
OnboardingTreat first session as theaterFirst 60 seconds rehearsed like a keynote
LifecycleReview billing, support, offboardingCancellation takes one screen, keeps dignity
Review prompts:
  • "Walk me from hearing about this to recommending it — where does it crack?"
  • "Who designed the invoice? The error email? The cancel flow?"
  • "Does the experience keep its promise after the sale?"
Ethical boundary: Owning the whole experience means owning failures too — never design a polished entrance and a hostile exit.
See references/end-to-end-experience.md when mapping the journey — the 7-stage touchpoint map from discovery to offboarding, the worst-touchpoint rule, and the org seams that produce undesigned surfaces.
核心概念： 产品包含所有触点：发现、购买、拆箱或首次使用、引导、日常使用、故障、支持、计费和退订。评审完整的用户旅程，而非孤立的应用本身。
为何有效： 客户会将整个体验视为一个整体。苹果打造了拆箱仪式、自有门店和天才吧，因为一款出色的设备如果销售不佳或支持服务粗糙，在用户记忆中就会变成糟糕的产品。
关键见解：
  • 苹果的包装经过设计实验室的打磨——第一印象是产品的一部分
  • 首次使用就是你的“拆箱环节”：用户在第0分钟看到的内容值得像主屏幕一样精心设计
  • 支持工单、发票和退订流程都是产品界面——通常没人设计这些
  • 团队间的每一次交接（营销→引导→产品→支持）都是体验出现断层的地方
  • 绘制端到端的用户旅程；最糟糕的触点决定了用户感知的质量
评审应用场景：
场景应用方式示例
发布评审将每个触点视为一个完整旅程进行审计广告承诺与首次使用体验一致
引导流程评审将首次会话视为一场精心编排的展示前60秒像主题演讲一样经过彩排
生命周期评审评审计费、支持、退订流程退订仅需一个屏幕，保留用户尊严
评审提问：
  • “带我走一遍从听说这款产品到推荐它的全过程——哪里出现了断层？”
  • “谁设计了发票？错误邮件？退订流程？”
  • “销售后的体验是否符合承诺？”
伦理边界： 掌控完整体验意味着也要掌控失败——绝不要设计精美的入口和充满敌意的退出流程。
绘制用户旅程时，请参阅references/end-to-end-experience.md——其中包含从发现到退订的7阶段触点图、“最糟糕触点规则”，以及导致未设计界面出现的团队断层问题。

5. Demo or It Doesn't Exist

5. 要么演示，要么不存在

Core concept: Review working artifacts, not specs or slideware. Concrete demos expose truth that documents hide; decisions are made by a decider reacting to the real thing.
Why it works: Abstractions let everyone imagine a different product and agree on nothing. A demo at real size on the real device forces specific feedback, surfaces dealbreakers early, and converges by decision rather than committee drift.
Key insights:
  • Apple's software culture (Kocienda's "creative selection"): build a demo, show a decision-maker, get direct feedback, iterate — that loop is the process
  • The iPhone keyboard was chosen by a derby of competing working demos, not a requirements doc
  • Review on the target device at target data scale — a phone UI judged on a projector lies
  • Prototype the riskiest moment first; a demo of the easy 80% proves nothing
  • "Real artists ship": demos exist to force decisions, not to delay them
Review applications:
ContextApplicationExample
Design reviewBan slide-only reviewsFigma prototype or build, never static deck
Competing ideasRun a demo derby, pick oneTwo nav models built, one verdict
Stakeholder alignmentDemo to the decider weekly30-min demo replaces 3 status docs
Review prompts:
  • "Don't tell me — show me. On the device."
  • "Which of these two demos wins? Pick one; we're not shipping a compromise of both."
  • "What's the riskiest assumption, and where's the demo that tests it?"
Ethical boundary: Demos must show honest state — a staged demo that hides known breakage is a lie with a UI.
See references/demo-culture.md when setting up a demo-driven review — the creative-selection loop, how to run a demo derby, the decider role, and honest-demo rules.
核心概念： 评审可运行的成品，而非规格文档或幻灯片。具体的演示会暴露文档隐藏的真相；决策由决策者根据真实产品做出。
为何有效： 抽象概念会让每个人想象出不同的产品，最终无法达成共识。在真实设备上以真实尺寸进行演示，能获得具体反馈，提前暴露致命问题，并通过决策而非团队内耗达成一致。
关键见解：
  • 苹果的软件文化（Kocienda提出的“创意选择”）：制作演示、向决策者展示、获得直接反馈、迭代——这个循环就是流程
  • iPhone键盘是通过多个可运行演示的竞争选出的，而非基于需求文档
  • 在目标设备上以目标数据规模进行评审——在投影仪上评判手机UI是不真实的
  • 先原型化最具风险的环节；仅演示简单的80%内容毫无意义
  • “真正的艺术家会发布作品”：演示的目的是推动决策，而非拖延
评审应用场景：
场景应用方式示例
设计评审禁止仅用幻灯片进行评审使用Figma原型或可运行版本，绝不使用静态演示文稿
竞品方案评审开展演示对决，选出最优方案构建两个导航模型，做出二选一裁决
利益相关者对齐每周向决策者进行演示30分钟演示替代3份状态文档
评审提问：
  • “不要告诉我——展示给我看。在真实设备上。”
  • “这两个演示哪个更好？选一个；我们不会发布两者的折中方案。”
  • “最具风险的假设是什么，哪里有演示可以验证它？”
伦理边界： 演示必须展示真实状态——刻意隐藏已知问题的演示是带有UI的谎言。
设置演示驱动的评审时，请参阅references/demo-culture.md——其中包含创意选择循环、如何开展演示对决、决策者角色，以及真实演示规则。

6. Taste and the Back of the Fence

6. 品味与“柜背原则”

Core concept: A great carpenter doesn't use plywood on the back of the cabinet, even though nobody will see it. Care invested in unseen surfaces — and the taste of the people applying it — is what quality actually is.
Why it works: Users sense craft subliminally: aligned pixels, coherent copy, graceful edge cases add up to trust. Teams that cut corners where "nobody looks" train themselves to cut corners everywhere; excellence is a habit enforced by standards, not inspections.
Key insights:
  • The original Mac team signed the inside of the case; Jobs made engineers redo the circuit board layout for beauty no customer would see
  • "Technology alone is not enough" — products live at the intersection of technology and the liberal arts
  • Audit the back-of-fence surfaces: empty states, error copy, settings pages, loading screens, emails
  • "Be a yardstick of quality" — A-players raise each other; tolerated mediocrity compounds
  • Taste is trainable: study great products, articulate why they're great, apply the standard ruthlessly
Review applications:
ContextApplicationExample
Detail auditReview the screens nobody demos404 page held to homepage standard
Copy reviewRead every string aloudError messages sound human, specific
Team standardCritique to the best work, not the average"Is this the best you've ever done?"
Review prompts:
  • "Show me the ugliest screen in the product — that's our real quality bar."
  • "Would you sign your name inside this?"
  • "Where did we use plywood?"
See references/case-studies.md for worked examples of the standard in action — the original Mac circuit board redone for unseen beauty, the iMac's opinionated subtraction, plus the MobileMe and antenna-gate failure reviews and what each teaches a reviewer.
核心概念： 优秀的木匠不会在柜子背面使用胶合板，即使没人会看到。投入在看不见的细节上的用心——以及应用这种用心的人的品味——才是真正的品质。
为何有效： 用户会潜意识地感知到工艺：对齐的像素、连贯的文案、优雅的边缘情况会累积成信任感。在“没人看的地方”偷工减料的团队会养成处处偷工减料的习惯；卓越是由标准而非检查所强化的习惯。
关键见解：
  • 初代Mac团队在机箱内部签名；乔布斯让工程师重新设计电路板布局，只为了没人会看到的美观
  • “仅靠技术是不够的”——产品处于技术与人文艺术的交叉点
  • 审计“柜背”界面：空状态、错误文案、设置页面、加载屏幕、邮件
  • “成为品质的标尺”——顶尖人才会互相成就；容忍平庸会不断恶化
  • 品味是可训练的：研究优秀产品，阐明其出色之处，严格应用标准
评审应用场景：
场景应用方式示例
细节审计评审没人会演示的屏幕404页面需达到首页的标准
文案评审大声朗读每一段文字错误提示听起来人性化、具体
团队标准评审以最优作品而非平均水平进行批判“这是你能做到的最好水平吗？”
评审提问：
  • “展示产品中最丑的屏幕——那才是我们真正的品质标准。”
  • “你愿意在这个产品内部签下你的名字吗？”
  • “我们在哪里使用了‘胶合板’？”
查看标准应用的实际案例，请参阅references/case-studies.md——其中包含初代Mac为看不见的美观重新设计电路板、iMac的明确精简，以及MobileMe和天线门故障评审的案例，以及每个案例带给评审者的启示。

7. Running the Review

7. 开展评审

Core concept: Structure the review: experience the product cold as a customer, name the One Thing it must do, audit against principles 1-6, then deliver a binary verdict — insanely great, or not done — with a specific cut list and fix list.
Why it works: Reviews fail through vagueness and politeness. A fixed walkthrough order, brutal specificity, and a binary verdict prevent "good enough" from shipping while giving the team an exact path to 10/10. Products get judged against their own promise — "What is this supposed to do? Then why doesn't it do that?"
Key insights:
  • Always experience the product cold before the meeting — first impressions can't be re-run
  • Open with the promise: state what the product claims, then test only that
  • Feedback must be specific and actionable: "this is confusing" fails review too — say what, where, why, and the fix direction
  • End binary: ship-worthy or a ranked fix list; never "polish it a bit"
  • One decider owns the verdict; input is wide, decision is narrow
ALWAYS output reviews in this format:
undefined
核心概念： 结构化评审：以客户身份首次体验产品，明确产品必须实现的“核心目标”，对照原则1-6进行审计，然后给出二元裁决——极致出色，或未完成——并附上具体的精简清单和修复清单。
为何有效： 评审会因模糊和客气而失败。固定的走查顺序、极致的具体性和二元裁决，能避免“还不错”的产品发布，同时为团队提供达到10/10分的明确路径。产品会根据自身承诺被评判：“这款产品应该做什么？那它为什么做不到？”
关键见解：
  • 会议前务必以客户身份首次体验产品——第一印象无法重现
  • 从承诺开始：明确产品的宣称目标，然后仅针对该目标进行测试
  • 反馈必须具体且可执行：“这很令人困惑”也未通过评审——需说明是什么、在哪里、为什么，以及修复方向
  • 最终给出二元结果：可发布或按优先级排序的修复清单；绝不要说“再打磨一下”
  • 由一位决策者负责裁决；广泛收集意见，集中做出决策
评审输出必须采用以下格式：
undefined

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]

See [references/review-protocol.md](references/review-protocol.md) when running an actual review session — the timed 5-step agenda, the fix-item specificity test, the candor rules (brutal on work, decent on people), review cadence, and how to adapt the protocol for solo or async reviews.
裁决： 极致出色 / 未完成（得分X/10） 核心目标： [产品必须实现的目标] 是否符合承诺？ [是/否——证据] 精简清单： [需移除的内容] 修复清单： [按优先级排序，具体且包含修复方向] 柜背细节： [未达标准的看不见的界面]

开展实际评审会议时，请参阅[references/review-protocol.md](references/review-protocol.md)——其中包含定时5步议程、修复条目具体性测试、坦诚规则（对工作严苛，对人尊重）、评审节奏，以及如何调整流程以适应单人或异步评审。

Common Mistakes

常见误区

MistakeWhy It FailsFix
Reviewing only aestheticsDesign is how it works; pretty-but-clunky still fails usersWalk flows, latency, and failure states
Fixing problems by addingEach addition taxes attention and breeds more complexitySubtract first; additions need a kill
Consensus verdictsCommittees average ideas into mushOne decider, wide input, narrow decision
Reviewing specs and slidesAbstractions hide dealbreakers; everyone imagines a different productDemand working demos on the real device
"Good enough" verdictsMediocrity compounds into brand damageBinary: insanely great or not done
Skipping unseen surfacesUsers sense plywood; teams learn to cut cornersAudit empty/error/settings/email states
Cosplaying crueltyFear stops demos and candor, killing the feedback loopBe brutal about work, decent to people
误区失败原因解决方案
仅评审美学设计是产品的运作方式；美观但笨拙的产品仍会让用户失望走查流程、延迟和故障状态
通过添加内容解决问题每一项添加都会消耗注意力并滋生更多复杂问题先精简；新增内容必须对应砍掉一项现有内容
共识裁决团队会将想法平均化，导致结果平庸一位决策者，广泛收集意见，集中决策
评审规格文档和幻灯片抽象概念会隐藏致命问题；每个人都会想象出不同的产品要求在真实设备上展示可运行的演示
“还不错”的裁决平庸会累积成品牌损害二元裁决：极致出色或未完成
跳过看不见的界面用户会感知到偷工减料；团队会养成偷工减料的习惯审计空/错误/设置/邮件状态
模仿刻薄恐惧会阻止演示和坦诚，破坏反馈循环对工作严苛，对人尊重

Quick Diagnostic

快速诊断

QuestionIf NoAction
Can you state the One Thing this product must do in one sentence?No focus — everything is the priorityWrite it; cut what doesn't serve it
Does a new user reach core value in ≤3 steps?Complexity is unconqueredMap steps-to-value; remove, don't reorder
Did the reviewer experience it cold, as a customer?You reviewed the team's story, not the productUse it before the meeting, no walkthrough
Is there a working demo on the real device?You're approving an imagined productReschedule until there's a demo
Was anything removed this cycle?Roadmap is accreting, not focusingAdd a cut list to every review
Do error, empty, and edge states match hero-screen quality?Back of the fence is plywoodAudit and fix unseen surfaces
Would the team proudly use it daily and sign it?The bar is "acceptable", not "insanely great"Hold the binary verdict until pride is real
问题如果答案为否行动
你能用一句话说明这款产品必须实现的核心目标吗？缺乏聚焦——所有内容都是优先级写下核心目标；砍掉所有不服务于该目标的内容
新用户能在≤3步内达成核心价值吗？复杂问题未被解决绘制价值达成步骤；移除内容，而非重新排序
评审者是否以客户身份首次体验了产品？你评审的是团队的说辞，而非产品会议前自行使用产品，无需团队引导
是否有在真实设备上运行的演示？你批准的是想象中的产品重新安排会议，直到有演示可用
本周期是否砍掉了任何内容？路线图在不断累积，而非聚焦每次评审都添加精简清单
错误、空和边缘状态是否达到主屏幕的质量标准？“柜背”使用了“胶合板”审计并修复看不见的界面
团队是否愿意自豪地日常使用并为它签名？标准是“可接受”，而非“极致出色”坚持二元裁决，直到团队真正引以为傲

About the Author

关于作者

Steve Jobs (1955-2011) co-founded Apple and led it to create the Mac, iPod, iPhone, and iPad, building the most valuable company in the world on design-led product development. This skill distills his documented review practices and standards from Walter Isaacson's authorized biography, Ken Segall's Insanely Simple, and Ken Kocienda's Creative Selection.
史蒂夫·乔布斯（1955-2011）是苹果公司的联合创始人，带领公司创造了Mac、iPod、iPhone和iPad，凭借设计驱动的产品开发打造了全球最具价值的公司。本方法提炼自沃尔特·艾萨克森的官方传记、肯·西格尔的《Insanely Simple》以及肯·科钦达的《Creative Selection》中记录的乔布斯评审实践与标准。

Further Reading

延伸阅读

This skill is based on documented accounts of Steve Jobs' product and design review practices:
本方法基于史蒂夫·乔布斯产品与设计评审实践的记录资料：