Mmcp.market

steve-jobs-design-review skill

by wondelai·wondelai/skills·2.3k stars·MIT

Review designs, products, and features with Steve Jobs'' standards: ruthless simplicity, focus, and end-to-end excellence. Use when the user mentions "Steve Jobs review", "design review", "product review", "what would Steve do", "insanely great", "this feels too complicated", "too many features", "product taste", "saying no", or "is this good enough to ship". Also trigger when critiquing a UI, feature, or roadmap for focus and simplicity, cutting scope to the essential, or pressure-testing the whole experience from first run to daily use. Covers the simplicity audit, the no list, design-is-how-it-works, end-to-end ownership, demo culture, and a Jobs-style review protocol with binary verdicts. For visual design fundamentals, see refactoring-ui. For usability audits, see ux-heuristics. For detail polish, see microinteractions.

A100/100content scan

Is the steve-jobs-design-review skill safe?

Clean: nothing in its files matched our rules. We read 6 files in the folder on 2026-09-28.

No findings.

Install the steve-jobs-design-review skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/ux-design/skills/steve-jobs-design-review ~/.claude/skills/steve-jobs-design-review
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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

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:

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.

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:

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.

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:

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.

4. Own the Whole Experience

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:

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.

5. Demo or It Doesn't Exist

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:

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.

6. Taste and the Back of the Fence

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:

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers