AgentAlley

Skills · Design & UI

Brutal Design Review Of Your Product

Unverified●26/40

Describe your product or app and how customers use it; get back a blunt verdict with an exact list of what to cut and what to fix first.

Originally by wondelai · MIT

Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor◐PartialPlain prose you can paste in — but no Cursor rules file
Codex◐PartialPlain prose you can paste in — but no AGENTS.md
Gemini CLI◐PartialPlain prose you can paste in
Copilot◐PartialPlain prose you can paste in — but no Copilot instructions file
npx agentalley add steve-jobs-design-review

This command does not work yet — the CLI is still being built. Until then, use Raw in the reader below to take the file.

Who is stuck, and on what

You've built something but you can't tell if it's actually good or just good enough, and everyone around you is too polite to say. You need someone to look at it the way a demanding customer would and tell you plainly what's wrong and what to fix first.

What it gives you

A one-page review that scores your product, states the one job it must do, and gives you a ranked list of what to remove and what to fix.

When NOT to use it

It reviews the experience you describe in words; it will not open your app, test it live, or redesign the screens for you.

The whole source

No sign-in, no blur, nothing truncated
steve-jobs-design-review/SKILL.md262 lines17.6 KBRawView on GitHub
Frontmatter — 4 properties
namesteve-jobs-design-review
descriptionReview 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.
licenseMIT
metadata author: wondelai version: "1.2.0
1---
2name: steve-jobs-design-review
3description: '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.'B1 — Line is 851 characters — unreadable by eye
4license: MIT
5metadata:
6 author: wondelai
7 version: "1.2.0"
8---A5 — No allowed-tools declared — no way to tell what this skill may touch
9 
10# Steve Jobs Design Review
11 
12Run 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.
13 
14## Core Principle
15 
16**"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."
17 
18## Scoring
19 
20**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.
21 
22## Framework
23 
24### 1. Simplicity Is the Ultimate Sophistication
25 
26**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.
27 
28**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.
29 
30**Key insights:**
31- "It takes a lot of hard work to make something simple, to truly understand the underlying challenges and come up with elegant solutions"
32- The iPod shipped with no on/off switch — the need was designed away, not the button hidden
33- Measure steps-to-value: Jobs demanded any song in three presses; the original iDVD pitch was one window, drag video in, click "Burn"
34- Prefer one good default over a setting; every preference is a decision you failed to make
35- If you must explain it, redesign it — instructions are apologies
36 
37**Review applications:**
38 
39| Context | Application | Example |
40|---------|-------------|---------|
41| Feature audit | Count steps to core value; cut anything off the main path | Signup → first value in 3 steps, not 9 |
42| UI critique | Remove elements until the screen states one intent | One primary button per screen |
43| Settings review | Replace options with opinionated defaults | Auto-save always on; no toggle |
44 
45**Review prompts:**
46- "What can we remove and have this still work better?"
47- "Why is this here? Who asked for it, and does the core user need it?"
48- "Explain this screen in one sentence. Can't? It's two screens — or none."
49 
50**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.
51 
52See [references/simplicity-and-focus.md](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.
53 
54### 2. Focus Means Saying No
55 
56**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.
57 
58**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.
59 
60**Key insights:**
61- In 1997 Jobs cut dozens of Apple products to a 2×2 matrix: consumer/pro × desktop/portable — focus saved the company
62- At retreats, the team's top-10 priority list got cut to three: "We can only do three"
63- "I'm as proud of the things we haven't done as the things we have done"
64- A roadmap with no recently killed items isn't focused, it's unexamined
65- Saying no includes features already shipped — deletion is a feature
66 
67**Review applications:**
68 
69| Context | Application | Example |
70|---------|-------------|---------|
71| Roadmap review | Force-rank, then cut everything below #3 | Q3 plan: 3 bets, not 14 backlog items |
72| Scope creep | Require a kill for every add | New dashboard widget = retire one |
73| Product line | Collapse overlapping SKUs/tiers | One plan per customer type |
74 
75**Review prompts:**
76- "If we could ship only one thing this quarter, which — and why isn't the rest cut?"
77- "What is this product deliberately bad at?"
78- "What did we say no to this cycle? Nothing? Then we said yes to mediocrity."
79 
80**Ethical boundary:** Say no to scope, never to evidence — killing a feature is strategy; ignoring user pain that contradicts your vision is vanity.
81 
82See [references/review-protocol.md](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.
83 
84### 3. Design Is How It Works
85 
86**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.
87 
88**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.
89 
90**Key insights:**
91- The iPhone keyboard succeeded through behavior (aggressive autocorrect), not visuals — engineering and design are one discipline
92- Review the slowest moment, not the happy path: cold start, empty state, offline, error recovery
93- "It just works" is a design spec: zero configuration, zero manual, zero ceremony
94- Beauty that fights function is decoration; reject it
95- Latency is a design property — a 2-second wait is a design flaw, wherever it lives in the stack
96 
97**Review applications:**
98 
99| Context | Application | Example |
100|---------|-------------|---------|
101| Mockup review | Demand the interaction, not the still | Click through states, not slides |
102| Performance | Set experience budgets in the review | First screen < 1s or it fails review |
103| Failure design | Walk error/empty/offline paths | Payment fails → user knows exactly what next |
104 
105**Review prompts:**
106- "Show me what happens when it fails."
107- "How does this feel after the 100th use, not the demo?"
108- "Where does the user wait, and what did we do about it?"
109 
110See [references/end-to-end-experience.md](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.
111 
112### 4. Own the Whole Experience
113 
114**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.
115 
116**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.
117 
118**Key insights:**
119- Packaging got design-lab treatment at Apple — first impressions are part of the product
120- The first run is your unboxing: what users see at minute zero deserves hero-screen care
121- Support tickets, invoices, and cancellation flows are product surfaces — usually nobody designed them
122- Every handoff between teams (marketing → onboarding → product → support) is where experience seams show
123- Map the journey end to end; the worst touchpoint sets the perceived quality
124 
125**Review applications:**
126 
127| Context | Application | Example |
128|---------|-------------|---------|
129| Launch review | Audit every touchpoint as one journey | Ad promise matches first-run reality |
130| Onboarding | Treat first session as theater | First 60 seconds rehearsed like a keynote |
131| Lifecycle | Review billing, support, offboarding | Cancellation takes one screen, keeps dignity |
132 
133**Review prompts:**
134- "Walk me from hearing about this to recommending it — where does it crack?"
135- "Who designed the invoice? The error email? The cancel flow?"
136- "Does the experience keep its promise after the sale?"
137 
138**Ethical boundary:** Owning the whole experience means owning failures too — never design a polished entrance and a hostile exit.
139 
140See [references/end-to-end-experience.md](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.
141 
142### 5. Demo or It Doesn't Exist
143 
144**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.
145 
146**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.
147 
148**Key insights:**
149- Apple's software culture (Kocienda's "creative selection"): build a demo, show a decision-maker, get direct feedback, iterate — that loop is the process
150- The iPhone keyboard was chosen by a derby of competing working demos, not a requirements doc
151- Review on the target device at target data scale — a phone UI judged on a projector lies
152- Prototype the riskiest moment first; a demo of the easy 80% proves nothing
153- "Real artists ship": demos exist to force decisions, not to delay them
154 
155**Review applications:**
156 
157| Context | Application | Example |
158|---------|-------------|---------|
159| Design review | Ban slide-only reviews | Figma prototype or build, never static deck |
160| Competing ideas | Run a demo derby, pick one | Two nav models built, one verdict |
161| Stakeholder alignment | Demo to the decider weekly | 30-min demo replaces 3 status docs |
162 
163**Review prompts:**
164- "Don't tell me — show me. On the device."
165- "Which of these two demos wins? Pick one; we're not shipping a compromise of both."
166- "What's the riskiest assumption, and where's the demo that tests it?"
167 
168**Ethical boundary:** Demos must show honest state — a staged demo that hides known breakage is a lie with a UI.
169 
170See [references/demo-culture.md](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.
171 
172### 6. Taste and the Back of the Fence
173 
174**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.
175 
176**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.
177 
178**Key insights:**
179- The original Mac team signed the inside of the case; Jobs made engineers redo the circuit board layout for beauty no customer would see
180- "Technology alone is not enough" — products live at the intersection of technology and the liberal arts
181- Audit the back-of-fence surfaces: empty states, error copy, settings pages, loading screens, emails
182- "Be a yardstick of quality" — A-players raise each other; tolerated mediocrity compounds
183- Taste is trainable: study great products, articulate why they're great, apply the standard ruthlessly
184 
185**Review applications:**
186 
187| Context | Application | Example |
188|---------|-------------|---------|
189| Detail audit | Review the screens nobody demos | 404 page held to homepage standard |
190| Copy review | Read every string aloud | Error messages sound human, specific |
191| Team standard | Critique to the best work, not the average | "Is this the best you've ever done?" |
192 
193**Review prompts:**
194- "Show me the ugliest screen in the product — that's our real quality bar."
195- "Would you sign your name inside this?"
196- "Where did we use plywood?"
197 
198See [references/case-studies.md](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.
199 
200### 7. Running the Review
201 
202**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.
203 
204**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?"
205 
206**Key insights:**
207- Always experience the product cold before the meeting — first impressions can't be re-run
208- Open with the promise: state what the product claims, then test only that
209- Feedback must be specific and actionable: "this is confusing" fails review too — say what, where, why, and the fix direction
210- End binary: ship-worthy or a ranked fix list; never "polish it a bit"
211- One decider owns the verdict; input is wide, decision is narrow
212 
213ALWAYS output reviews in this format:
214 
215```
216# Design Review: [Product/Feature]
217**Verdict:** INSANELY GREAT / NOT DONE (score X/10)
218**The One Thing:** [what this must do]
219**Keeps its promise?** [yes/no — evidence]
220**Cut list:** [what to remove]
221**Fix list:** [ranked, specific, with fix direction]
222**Back of the fence:** [unseen surfaces that fail the bar]
223```
224 
225See [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.
226 
227## Common Mistakes
228 
229| Mistake | Why It Fails | Fix |
230|---------|-------------|-----|
231| Reviewing only aesthetics | Design is how it works; pretty-but-clunky still fails users | Walk flows, latency, and failure states |
232| Fixing problems by adding | Each addition taxes attention and breeds more complexity | Subtract first; additions need a kill |
233| Consensus verdicts | Committees average ideas into mush | One decider, wide input, narrow decision |
234| Reviewing specs and slides | Abstractions hide dealbreakers; everyone imagines a different product | Demand working demos on the real device |
235| "Good enough" verdicts | Mediocrity compounds into brand damage | Binary: insanely great or not done |
236| Skipping unseen surfaces | Users sense plywood; teams learn to cut corners | Audit empty/error/settings/email states |
237| Cosplaying cruelty | Fear stops demos and candor, killing the feedback loop | Be brutal about work, decent to people |
238 
239## Quick Diagnostic
240 
241| Question | If No | Action |
242|----------|-------|--------|
243| Can you state the One Thing this product must do in one sentence? | No focus — everything is the priority | Write it; cut what doesn't serve it |
244| Does a new user reach core value in ≤3 steps? | Complexity is unconquered | Map steps-to-value; remove, don't reorder |
245| Did the reviewer experience it cold, as a customer? | You reviewed the team's story, not the product | Use it before the meeting, no walkthrough |
246| Is there a working demo on the real device? | You're approving an imagined product | Reschedule until there's a demo |
247| Was anything removed this cycle? | Roadmap is accreting, not focusing | Add a cut list to every review |
248| Do error, empty, and edge states match hero-screen quality? | Back of the fence is plywood | Audit and fix unseen surfaces |
249| 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 |
250 
251## About the Author
252 
253Steve 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*.
254 
255## Further Reading
256 
257This skill is based on documented accounts of Steve Jobs' product and design review practices:
258 
259- [*"Steve Jobs"*](https://www.amazon.com/Steve-Jobs-Walter-Isaacson/dp/1451648537?tag=wondelai00-20) by Walter Isaacson
260- [*"Insanely Simple: The Obsession That Drives Apple's Success"*](https://www.amazon.com/Insanely-Simple-Obsession-Drives-Success/dp/1591846218?tag=wondelai00-20) by Ken Segall
261- [*"Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs"*](https://www.amazon.com/Creative-Selection-Inside-Apples-Process/dp/1250194466?tag=wondelai00-20) by Ken Kocienda
262 

Reviews

Installed this one?Write the first review and take the Trailblazer badge.

Reviews only open after a real install, so this is empty — and we leave it empty rather than invent one.

Alternatives

Also in Design & UI
Brand Protection — Amazon 🛡️Amazon brand protection toolkit. Detect hijackers, counterfeits, and unauthorized sellers. Includes MAP violation monitoring, trademark abuse detection, complaint templates for Brand Registry, and test buy evidence collection guides. No API key required.Design & UI · MIT◐····●35/40Brand Protection — eBay 🛡️eBay brand protection toolkit. Detect unauthorized sellers, counterfeits, and VeRO violations. Includes price monitoring, trademark abuse detection, VeRO complaint templates, and enforcement guides. No API key required.Design & UI · MIT◐····●35/40Brand Protection — Shopify/DTC 🛡️Shopify/DTC brand protection toolkit. Detect counterfeit stores, unauthorized resellers, and trademark violations. Includes DMCA takedown templates, domain monitoring, and social media infringement detection. No API key required.Design & UI · MIT◐····●35/40Brand Protection — TikTok Shop 🛡️TikTok Shop brand protection toolkit. Detect unauthorized sellers, counterfeit products, and affiliate abuse. Includes TikTok IP Protection reporting, influencer misuse detection, and complaint templates. No API key required.Design & UI · MIT◐····●35/40