/wireframe-reviewer

name: wireframe-reviewer
description: Use when reviewing or critiquing an existing website wireframe, landing page, or page structure for any niche or business — when you need structured feedback on narrative flow, visual hierarchy, clarity, and conversion path, plus concrete fixes per section. For building a new page structure from scratch, use wireframe-writer.

Wireframe Reviewer

• Reviewing a page = checking whether it tells a clear story that pulls one scroll toward one action.
• Critique against five axes, then return structured findings + a concrete fix for each.
• Built on the six levers — see **storytelling-hooks**. Recap: 1. Curiosity gap · 2. Emotional mirror · 3. Conflict engine · 4. Relatability · 5. Pattern + surprise · 6. Three-act.

When to Use

• Reviewing a wireframe, mockup, or live landing/sales/home page.
• Diagnosing low conversion, confusing flow, or "it just feels off".
• Giving a designer/marketer structured, actionable feedback.
• Any niche or business. To build a new structure, use **wireframe-writer**.

The Five Review Axes (Quick Reference)

| Axis | Question | Common failure | |------|----------|----------------| | Narrative flow | Does each section earn the next scroll? | Sections in random order; no loop | | Visual hierarchy | Does the eye land on what matters first? | Everything equal weight; buried CTA | | Clarity | Is the message understood in 5 seconds? | Vague hero; jargon; feature dump | | Conversion path | Is there one obvious next action? | Many/competing CTAs; no CTA above fold | | Friction | What makes a visitor hesitate or leave? | Unanswered objections; cognitive load |

Intake (Before Reviewing)

• A review without context grades against guesses. Know before reviewing: the page's **one conversion goal**, the target visitor in a sentence, and the main traffic source.
• If these are inferable from the request (a freelancer's services page → goal is inquiries), state your assumptions inline and proceed; only ask first when the goal is genuinely undecidable — don't block a review on intake theater.

Review Process

1. **5-second test:** Look only at the hero. Can you state what it offers and what to do next? If not, that's finding #1. 2. **Scroll the arc:** Does it move hook → problem → solution → proof → offer → objections → CTA? Note any missing or out-of-order section. 3. **Score each axis** per section (works / weak / missing) — an internal diagnostic pass, not a grid to render in the output. 4. **Trace the eye:** Is hierarchy guiding to headline → value → CTA? Or competing for attention? 5. **Find the friction:** List every reason a visitor hesitates (unanswered question, weak proof, too many choices). 6. **Write findings:** For each issue — what's wrong, why it hurts, the fix.

Findings Format

• For each issue, return:
• **Section** — where it is.
• **Severity** — critical (blocks conversion) / major (leaks conversions) / minor (polish).
• **Issue** — what's wrong.
• **Why it matters** — impact on flow/conversion.
• **Fix** — concrete change (and which lever it restores, where one applies — pure-polish fixes don't need a lever tag).
• Order by **severity first**, position second (hero/CTA issues usually are the critical ones, but a critical mid-page issue outranks a minor hero one). Cap the list at the ~5–8 findings that matter; a 20-item list buries the critical three. Missing objection-handling before the CTA is usually worth a slot — don't let polish findings crowd it out.
• End with the single change you'd make first if only one were allowed.

What to Flag

• **Hero:** no curiosity gap or promise; CTA missing above the fold; headline about the company, not the visitor.
• **Problem:** doesn't mirror the visitor's pain → no relatability, no conflict.
• **Proof:** absent, generic, or placed far from the claims it supports.
• **Benefits:** feature lists instead of outcomes/feelings.
• **Objections:** common "buts" left unaddressed before the CTA.
• **CTA:** multiple competing actions; vague labels; high friction.
• **Hierarchy:** uniform weight, no focal point, CTA visually lost.
• **Flow:** a section that closes a loop without opening the next (dead end where users drop).
• **Bookend:** ending doesn't echo the opening promise.

Review Checklist

• [ ] Passes the 5-second hero test?
• [ ] Sections follow a deliberate narrative arc?
• [ ] Clear visual focal point per section guiding to the CTA?
• [ ] One primary action, obvious and repeated?
• [ ] Proof sits beside its claims?
• [ ] Top objections handled before the final CTA?
• [ ] Every finding paired with a concrete fix (+ the lever it restores, where applicable)?

Related

• **wireframe-writer** — build the structure this skill critiques.
• **storytelling-hooks** — the six levers (read for depth).