steve-jobs-design-review

# 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.** When reviewing a design, product, feature, or roadmap, rate it 0-10 against the principles below. State the current score, exactly what fails, and the specific cuts or fixes required to reach 10/10. There is no "pretty good" — anything below 10 is not done yet.

## Framework

### 1. Simplicity Is the Ultimate Sophistication

**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:**

| Context | Application | Example |
|---------|-------------|---------|
| Feature audit | Count steps to core value; cut anything off the main path | Signup → first value in 3 steps, not 9 |
| UI critique | Remove elements until the screen states one intent | One primary button per screen |
| Settings review | Replace options with opinionated defaults | Auto-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](references/simplicity-and-focus.md)

### 2. Focus Means Saying No

**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:**

| Context | Application | Example |
|---------|-------------|---------|
| Roadmap review | Force-rank, then cut everything below #3 | Q3 plan: 3 bets, not 14 backlog items |
| Scope creep | Require a kill for every add | New dashboard widget = retire one |
| Product line | Collapse overlapping SKUs/tiers | One 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](references/review-protocol.md)

### 3. Design Is How It Works

**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:**

| Context | Application | Example |
|---------|-------------|---------|
| Mockup review | Demand the interaction, not the still | Click through states, not slides |
| Performance | Set experience budgets in the review | First screen < 1s or it fails review |
| Failure design | Walk error/empty/offline paths | Payment 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