# Design Review

> Adversarial art-direction, UX, copy, SEO, accessibility, and implementation review for emisar marketing website pages. Use before shipping public marketing pages, after LLM-generated redesigns, when a page feels generic or overdesigned, or when rendered screenshots need critique against an agency-quality bar.

- Skill: `andrewdryga/design-review` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add andrewdryga/design-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andrewdryga/design-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: AndrewDryga (https://skillmd.com/u/andrewdryga)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/andrewdryga/design-review

---


# Design Review

Review the rendered marketing page like a strict design director and conversion
reviewer. Lead with concrete issues that make the page generic, unclear,
untrustworthy, inaccessible, slow, or hard to act on. Do not rewrite the whole
page unless the concept is fundamentally wrong.

## Inputs

Prefer all of these:

- The creative brief and chosen direction from `design-creative-director`.
- The rendered URL or static HTML.
- Desktop and mobile screenshots.
- The changed files or diff.
- The target conversion goal and SEO intent.

If screenshots are missing and the site can run locally, ensure the review has
a claimed task (create a basic one when needed), then render it and capture into
that task's `screenshots/` directory before judging — the viewports and sections
to capture are in `references/screenshot-checklist.md`. If rendering is blocked,
say so and review the code with lower confidence.

## Review Passes

1. **Template smoke test.**
   Use `references/quality-rubric.md`. Flag any split hero, generic feature grid,
   decorative gradient/blob, fake dashboard, vague SaaS copy, stock metaphor, or
   one-note palette.

2. **First-viewport test.**
   In five seconds, can a buyer tell that emisar lets an infrastructure agent keep
   working inside explicit bounds, why that is safer than the alternative, and what
   to do next? The first viewport must also feel specific to this product. Treat
   approvals and audit as proof of control, not the headline outcome.

3. **Narrative and conversion test.**
   Check the page argument: claim, mechanism, proof, comparison, objections,
   trust/security, and CTA. Identify missing proof and weak transitions.

4. **Visual craft test.**
   Inspect hierarchy, alignment, rhythm, typography, image treatment, spacing,
   responsive behavior, and whether the art direction is carried through every
   section. Then run the `design-interface-polish` micro-craft pass for the
   small details that read as unfinished, checked against design-system §3.

5. **Usability and accessibility test.**
   Check scan path, CTA clarity, keyboard/focus states, contrast, reduced motion,
   text fit, alt text, mobile ergonomics, and no horizontal overflow.

6. **SEO and performance test.**
   Check initial HTML content, one H1, title/meta, semantic sections, internal
   links, schema candidates, image weight/dimensions, layout shift, and whether
   motion/visuals hurt load or comprehension.

7. **Implementation fit.**
   Check the code matches existing Phoenix/HEEx/Tailwind patterns, keeps marketing
   pages server-rendered, avoids unnecessary dependencies, and remains maintainable.

## Severity

- BLOCKER: generic concept, false/security-risk claim, broken responsive layout,
  inaccessible primary action, SEO/crawl breakage, or page cannot ship.
- MAJOR: weak proof, confusing narrative, visible layout/craft failure, poor mobile
  experience, heavy asset/motion problem, or likely conversion loss.
- MINOR: polish issue, copy tightening, inconsistent detail, missing secondary
  state, or small SEO/accessibility improvement.
- NIT: optional refinement that does not materially affect clarity or trust.

## Output

```
Verdict: SHIP | SHIP-AFTER-FIXES | RETHINK
Summary: <2-3 sentences>

Findings:
- SEVERITY file:line or viewport - issue - why it matters - concrete fix

Scores:
- Distinctiveness: 1-5
- Clarity: 1-5
- Trust/proof: 1-5
- Visual craft: 1-5
- UX/accessibility: 1-5
- SEO/performance: 1-5

Fix order:
1. <highest leverage fix>
2. <next>
```

Keep the critique tied to rendered evidence. If the page is clean, say so and list
only residual risks worth acting on.