# UI design review with your agent

> Capture app screens from your agent, mark what matters on the pixels, and loop until a human approves — not when the model says it looks fine.

Page: https://revisemy.com/for/ui

## The problem

Agents ship UI fast but rarely wait for a human eye on hierarchy, spacing, or contrast. Feedback scattered in chat or Slack does not map back to regions on the screen, and there is no proof a fix landed.

## How ReviseMy fits

Your agent opens a review with `type: ui` so the checklist and vision lens focus on hierarchy, spacing, and affordances. Pick one ingest source per review — usually screenshots of the app — then mark, approve, or request changes until `next_action` says stop.

## What you get

- **Rectangle marks on the exact pixels** — Drag to outline a region or click for a point note. Each mark carries intent — must-fix, nice to have, question, or keep — so agents know what to change and what to leave alone.
- **Multi-pass with before/after evidence** — Request changes to open the next pass. Agents resolve marks with notes and optional after images so you can verify fixes without re-explaining the whole screen.
- **Second opinion hints, human marks win** — A free UI checklist runs immediately; optional vision models can add region hints. Suggestions never override your marks or flip approve / request-changes.
- **No account for reviewers** — Share the secret review link. Designers and devs mark and decide without signing up — the agent keeps the MCP handoff.

## Checklist

- Visual hierarchy: one clear primary action, not competing CTAs
- Text contrast on labels and buttons (WCAG AA)
- Spacing rhythm — uneven gaps and cramped edge clusters
- Mobile-tall frames: ~44×44px tap targets and thumb-zone actions
- Wide desktop: readable measure, content not stretched edge-to-edge

## Getting it in

Review type chooses the second-opinion lens. Ingest chooses how pixels get into the review. Use exactly one source per `create_review` call — and yes, sources overlap across types when that is what you have.

- **Screenshots** (`images`) — Best default for UI. Pass 1–5 HTTPS URLs, data URLs, or base64. Required for localhost and anything the capture server cannot reach — encode as data URLs, never `http://localhost…`.
- **Live URL capture** (`capture_url`) — Public staging or Storybook URL with `capture_url: true` + `page_url`. Still set `type: ui` if you want the UI lens instead of the website checklist.
- **HTML render** (`html`) — Rare for app UI, but useful for isolated component HTML. Pair with `type: ui` so hints stay hierarchy/spacing-focused rather than email CTA rules.
- **PDF pages** (`pdf`) — When the “UI” is a design export or multi-page PDF mock. Each page becomes a screenshot; keep `type: ui` for the app checklist.

## Ask your agent

- “Run a design checkup on these UI screenshots.”
- “Review this screen for hierarchy and spacing — I will mark feedback on the link.”
- “Address my UI feedback and attach after shots when you resolve each mark.”

## Questions

### How does my agent upload UI screenshots?

Pass images to `create_review` as HTTPS URLs, data URLs, or base64. Set `type` to `ui` (the default with images). Your agent can capture from a local build, Storybook, or a staging URL.

### Can I use a live URL for UI review?

Yes. Use `capture_url: true` with `page_url` and set `type: ui` so you still get the UI checklist. Or fall back to `images` data URLs when the page is localhost-only.

### Are second-opinion hints decisions?

No. Checklist and optional vision findings are labeled suggestions. Only your marks drive `next_action` and approve / request-changes.

### Do reviewers need an account?

No. Open the secret `/r/{token}` link from your agent. Connecting the agent takes one click on /connect.