| name | design-review |
| preloaded | true |
| description | Run a product design review on a feature or site. Answers 13 design questions, runs Nielsen Norman heuristic evaluation, builds before/after visual fixes, and deploys a shareable report to Surge. Use when asked to review a design, audit UX, do a design review, or analyze a product's user experience. |
Design Review
Run a full product design review. Walk through the product as a first-time user, answer 13 design questions, run a heuristic evaluation, and deploy a shareable before/after report to Surge.
Inputs
| Parameter | Required | Description |
|---|
| URL or feature | Yes | A live URL, local HTML file, or description of the feature to review |
| Context | No | Any additional context about the product, audience, or goals |
Start immediately with defaults. Do not ask clarifying questions. Make your best assumptions for anything you don't know.
Workflow
1. Walk Through as a New User
Open the URL in the browser. Navigate screen by screen, taking screenshots. React to what you see out loud:
- What am I being asked to do?
- Is it clear WHY I'd do it?
- Where would I get confused or frustrated?
- What would I expect to happen next?
Pay special attention to:
- Time to wow: How quickly does a new user think "this is why I came here"?
- Dead ends: Places where the user finishes something and there's no clear next step.
- Empty states: Screens that look broken when there's no data yet.
2. Answer the 13 Design Questions
For each question, provide a specific answer based on what you observed. Do not ask the user. Make your best assumption.
- What is the objective of this feature? What problem does it solve? What outcome does it drive?
- Who is this for? Specific user persona, not "everyone."
- When and why would they use it? The trigger moment. What just happened that brings them here?
- What are they thinking about? Their mental state, concerns, expectations when they arrive.
- How did they get here? The previous step in their journey. What screen or action preceded this?
- What do we want users to feel? The emotional response we're designing for.
- What would they do without this feature? The alternative. Manual workaround, competitor, nothing?
- What do they do next? The next step after using this feature. Is it clear?
- Are we confident this is better than what already exists? Compared to the current state or competitors.
- What can we remove to have it work just as well? Strip to the essential. What's decorative vs functional?
- If we throw away our constraints, would we still design it this way? Imagine unlimited time and resources.
- Will most users realize the value of this feature? Is the benefit obvious or hidden?
- Is this for user growth, engagement, or retention? Which metric does this primarily serve?
Use ASCII diagrams to visualize the user journey where it helps paint the picture.
3. Nielsen Norman Heuristic Evaluation
Evaluate against all 10 heuristics. For each one, give a pass/fail with specific evidence:
- Visibility of system status — Does the user always know what's happening?
- Match between system and real world — Does it use language and concepts the user knows?
- User control and freedom — Can users undo, go back, escape?
- Consistency and standards — Does it follow platform conventions?
- Error prevention — Does it prevent mistakes before they happen?
- Recognition rather than recall — Are options visible, not memorized?
- Flexibility and efficiency of use — Are there shortcuts for power users?
- Aesthetic and minimalist design — Is every element earning its place?
- Help users recognize, diagnose, and recover from errors — Are error messages useful?
- Help and documentation — Is guidance available when needed?
4. Identify Top 3 Issues
From the walkthrough and heuristic evaluation, pick the 3 highest-impact issues. For each:
- What to fix: Plain language description.
- Why it matters: Tie it back to a specific heuristic violation or design question answer.
- Expected impact: What changes if you fix this.
5. Build the Before/After Report
First decide whether before/after is even the right format. If the target is a
visually mature, professionally designed production site (Oura, Apple, Stripe, a
funded consumer app), do NOT build rebuilt-in-HTML "after" mockups: a one-shot
mockup looks strictly worse than their real pixels, so the comparison misleads the
user and your fixes read as downgrades (real correction: "the after's are all worse
than the before's... do the dogfood skill instead"). For polished sites, run the
dogfood or adversarial-ux-test skill instead (real screenshots + repro), and
describe/annotate fixes in prose over the real screenshot. Before/after in code is
for rough/early/internal surfaces or your own app where you have the real CSS, and
even then render the "after" inside real chrome. Full rationale and the
audit-false-positive lesson: references/before-after-vs-dogfood.md.
FIRST, pick the right method (this gate carries real weight). Hand-built "after"
HTML next to a polished real product almost always looks WORSE than the original,
and the user reads the whole review as weaker because of it. Real correction
(Oura review, 2026-06): "The after's are all worse than the before's. Maybe
instead of graphic audit, you can do the dogfood skill instead?" The crude mockup
flattered the very thing it was supposed to critique.
Decide before building anything:
- Reviewing a site/app you CAN'T control or rebuild faithfully (a third-party
live site, a competitor, any surface whose real CSS you can't pull verbatim):
do NOT fabricate "after" mockups. Run a behavioral pass instead — load the
dogfood skill, capture REAL screenshots of REAL issues, verify each in the DOM,
and report fixes as prose + the real evidence. No invented "after" state to
flatter the original. See references/third-party-site-review.md.
- Reviewing your own surface where you can pull the real CSS/chrome: build the
before/after IN CONTEXT per
references/in-context-preview.md (real stylesheet,
real chrome, real transform, real content, option switcher). Never bare mockups.
Only when in-context faithful rendering is genuinely available do you build two
HTML renders side by side:
- Before: Recreate the current state of the problem area in code.
- After: Show the visual fix in code.
These are rebuilt in HTML, not screenshots. Both versions should be crisp and consistent.
Exception, and it's a big one: do NOT fabricate "after" mockups when the target is a polished, live third-party product. A hand-built HTML "after" rendered next to the real site's actual pixels almost always looks WORSE than the original, so the comparison silently flatters the thing you're critiquing and the review reads as wrong. Real correction (Oura review, 2026-06): "The after's are all worse than the before's." When the subject is a real shipping site/app you don't own, switch methods: run the dogfood or adversarial-ux-test skill instead — real screenshots of real bugs, repro videos, every finding verified in-DOM (not vision-only) and tied to a specific NN heuristic. Fabricated before/after is only safe for YOUR OWN surface where you can render the fix in real chrome (see references/in-context-preview.md) and for genuinely low-fidelity originals. Full rationale and the method-selection rule: references/reviewing-live-products.md.
Render the fix INSIDE the real page chrome, not the component bare. If the
preview exists so the user can choose how a change looks on a real product surface,
a stripped-down component render is wrong — it looks nothing like the live site and
the user can't judge it (real correction: "the memo UX wasn't inside of the card,
that's why it's so different than the site"). Pull the app's actual CSS verbatim,
reproduce the surrounding chrome (container, nav, breadcrumb, the component's own
card wrapper), run the app's real client-side transform, and feed it real fixture
content. For multiple options, build ONE in-context page with a fixed option
switcher (radio groups toggling body data-attributes) plus a "Current" baseline,
so the user flips variants live against the real surface. Full recipe, the
exec-don't-regex helper-decode pitfall, and the pre-deploy verify step:
references/in-context-preview.md.
Package everything into a single Surge page:
┌─────────────────────────────────┐
│ [Product Name] Design Review │
│ Date · URL │
├─────────────────────────────────┤
│ Summary │
│ 13 Design Questions (answered) │
│ Heuristic Scorecard │
│ Issue 1: Before / After │
│ Issue 2: Before / After │
│ Issue 3: Before / After │
└─────────────────────────────────┘
6. Deploy
npx surge . [product-name]-design-review.surge.sh
Share the URL with the user. If npx surge fails with ECONNREFUSED 192.241.214.148:443, surge's upload server is down (not your network): fall back to
GitHub Pages. Real-screenshot before/after captures (Before = live site, After =
mockup), the accessible-label-vs-visible-text accuracy check, and the full
Pages-fallback recipe with its git-guard pitfalls:
references/screenshot-before-after-and-deploy-fallback.md.
If surge fails to deploy (ECONNREFUSED to surge's upload IP = surge's server
is down, not your network), don't retry forever. After 2-3 attempts, fall back to
GitHub Pages and hand the user a working URL. Full guard-safe recipe (gh-pages
branch since main push may be blocked, per-account token, trash-not-rm):
references/surge-down-gh-pages-fallback.md. If surge fails with ECONNREFUSED ...:443, surge's
deploy host may be down independently of your network: diagnose, send the file
directly, and launch a background retry loop instead of spinning. Recipe:
references/surge-deploy-down-fallback.md.
Output
A single shareable URL containing:
- Design question answers with user journey visualization
- Heuristic evaluation scorecard
- Before/after visual comparisons for the top 3 issues
- Specific, actionable recommendations tied to evidence
Notes
- Make your best assumptions. Do not ask the user to answer the 13 questions. You answer them based on observation.
- Be specific and constructive. Not "improve onboarding" but "add a welcome screen that asks what the user wants to accomplish."
- The report should be presentation-ready. A PM could send it to stakeholders without explanation.
- For local HTML files, open them in the browser. Do not read source code.
Reviewing a third-party site or app (you don't control it)
When the target is a live site/app you can't rebuild faithfully, do NOT fabricate
"after" mockups. See references/third-party-site-review.md for the behavioral
method (dogfood + DOM-verified findings), the "don't report bot-block artifacts"
rule, and the App-Store-app-can't-run-on-simulator constraint plus the honest
listing-analysis path.
Multi-lens prototypes & reconstructing a deployed Surge page
When the ask is a richer product-design exploration (not just a review), stack design
lenses on ONE interactive prototype rather than running this skill alone, and when the
target is a deployed Surge page with no local source, rebuild from the live HTML rather
than from scratch. Full workflow, skill-stacking order (design-system → design-mode →
design-review → Apple HIG check → another-perspective → final UI-polish pass), the
council-via-delegate_task note, and the surge edge-cache / dangling-fragment pitfalls:
references/multi-lens-prototype-and-surge-reconstruct.md.
