steve-jobs-design-review

---
name: steve-jobs-design-review
description: Use when reviewing a design, product, or roadmap for ruthless simplicity and focus, cutting scope to the essential, or deciding if something is good enough to ship.
category: Design
version: 1.0.0
tools: []
---

# 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.

## Framework

### 1. Simplicity Is the Ultimate Sophistication

Simplicity is not the absence of features — it is complexity conquered. Keep subtracting until removing one more thing would break the product's purpose. Every element a user must perceive, parse, or decide about taxes attention and erodes confidence. "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:** count steps to core value and cut anything off the main path (signup → first value in 3 steps, not 9); remove UI elements until the screen states one intent (one primary button per screen); replace settings 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?" / "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.

### 2. Focus Means Saying No

"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. 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. 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.

**Review applications:** force-rank the roadmap, then cut everything below #3 (Q3 plan: 3 bets, not 14 backlog items); require a kill for every add (new dashboard widget = retire one); collapse overlapping SKUs/tiers into 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.

### 3. Design Is How It Works

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. Users don't experience screenshots; they experience latency, errors, interruptions, and sequences. 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:** demand the interaction, not the still (click through states, not slides); set experience budgets in the review (first screen < 1s or it fails review); walk error/empty/offline paths (payment fails → user knows exactly what's 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?"

### 4. Own the Whole Experience

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 — 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. 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. Map the journey end to end; the worst touchpoint sets the perceived quality.

**Review applications:** audit every touchpoint as one journey (ad promise matches first-run reality); treat the first session as theater (first 60 seconds rehearsed like a keynote); review billing, support, and offboarding (cancellation 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.

### 5. Demo or It Doesn't Exist

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. Apple's software culture (Ken 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:** ban slide-only reviews (Figma prototype or build, never static deck); run a demo derby for competing ideas (two nav models built, one verdict); demo to the decider weekly (30-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.

### 6. Taste and the Back of the Fence

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. 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. 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. "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:** review the screens nobody demos (404 page held to homepage standard); read every string aloud (error messages sound human, specific); critique 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?"

### 7. Running the Review

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. Reviews fail through vagueness and politeness; a fixed walkthrough order, brutal specificity, and a binary verdict prevent "good enough" from shipping. 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:

```
# 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]
```