Design Review

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

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.

1. What is the objective of this feature? What problem does it solve? What outcome does it drive?
2. Who is this for? Specific user persona, not "everyone."
3. When and why would they use it? The trigger moment. What just happened that brings them here?
4. What are they thinking about? Their mental state, concerns, expectations when they arrive.
5. How did they get here? The previous step in their journey. What screen or action preceded this?
6. What do we want users to feel? The emotional response we're designing for.
7. What would they do without this feature? The alternative. Manual workaround, competitor, nothing?
8. What do they do next? The next step after using this feature. Is it clear?
9. Are we confident this is better than what already exists? Compared to the current state or competitors.
10. What can we remove to have it work just as well? Strip to the essential. What's decorative vs functional?
11. If we throw away our constraints, would we still design it this way? Imagine unlimited time and resources.
12. Will most users realize the value of this feature? Is the benefit obvious or hidden?
13. 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:

1. Visibility of system status — Does the user always know what's happening?
2. Match between system and real world — Does it use language and concepts the user knows?
3. User control and freedom — Can users undo, go back, escape?
4. Consistency and standards — Does it follow platform conventions?
5. Error prevention — Does it prevent mistakes before they happen?
6. Recognition rather than recall — Are options visible, not memorized?
7. Flexibility and efficiency of use — Are there shortcuts for power users?
8. Aesthetic and minimalist design — Is every element earning its place?
9. Help users recognize, diagnose, and recover from errors — Are error messages useful?
10. 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.