| name | design-review |
| 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
For each issue, 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.
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: a component preview rendered bare looked
"so different than the site" because it wasn't shown inside the card it lives in).
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.
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.
