/goaldesignlow riskintermediatesafety C · 55Forward Futurepre-dates current gate · under review

Score every screen on a real task

Complete a real user task, score each meaningful screen with one checklist, fix the weak spots, and retest end to end.

prompt
→ Claude
Improve [user flow, such as signup] at [URL] until [completion criterion]. In a real browser, start each pass from fresh state—no saved login, cookies, or site data. Capture meaningful screens at the agreed sizes and modes, score them with one checklist, and improve the weakest safe area. Rerun the whole flow and keep only regression-free changes. Stop on success, two full passes with no gain, blocked access, or required approval. Return scores, screenshots, changes, and stop reason.
claude-code · codex

Use this when

Use this for a real task such as signup, login, onboarding, checkout, sharing, or creating and editing an item when the entire experience can be exercised in a browser and scored consistently.

How it runs

  1. Choose the user task, starting URL, success target, browser, clean-session rule, screen sizes, light or dark modes, screens to capture, and anything the agent must not change.
  2. Complete the task once without editing; capture normal screens plus meaningful loading, error, recovery, and success states, then score each with the same user-focused rubric.
  3. Improve the weakest safe area, start a new clean browser session, and repeat the entire task under the same conditions so before-and-after scores are comparable.
  4. Keep only changes that improve the target without hurting another important screen; stop on success, two passes with no gain, blocked access, or required approval.

Done when

The complete user task scores better without making another important screen worse. The final dashboard shows the same entry point, fresh browser state, screen sizes, modes, scoring rubric, screenshots, score changes, and stop reason for every retained improvement.

Why it works

A clean browser session exposes problems that saved logins, cookies, and remembered settings can hide. Repeating the same task with the same scoring rubric makes the result comparable instead of relying on a vague impression that the interface feels better.

Implementation note

A flow means a user goal, such as signing up or checking out—not a guessed web address. A screen size is sometimes called a viewport; a mode may be light or dark. Judge what the user can see and do, not hidden console output.

Source: Forward Future

More design loops

Design a thumbnail that earns clicks

Generate ten concepts, score the top three against a real channel, and sharpen the winner without misleading viewers.

prompt
→ Claude
For [video], use [approved assets] to make ten thumbnail concepts. Score each at real YouTube sizes against [inspiration channel] for clarity, curiosity, emotional pull, contrast, and accuracy. Take the top three, improve each one's weakest dimension, and rescore them under the same rubric. Keep iterating the strongest concept until it clears [quality threshold] or [budget] ends. Reject anything the video cannot deliver. Return the winner, two runners-up, previews, final scores, and rationale.
designlow risk

Rebuild a page pixel-for-pixel

Capture a real page, build a static mirror and a live version, then repair the weakest fidelity signals until they match.

prompt
→ Claude
Point War Loops at an authorized URL or image. Capture it with a genuine browser and record the layout, styles, content, motion, and responsive behavior. Build a static Pencil mirror and a moving Forge version. Compare both with the source at desktop, tablet, and mobile sizes; repair only the weakest fidelity signals. Stop when every gate passes, progress stalls, or capture is blocked. Finish with the builds, spec, renders, scores, and remaining gaps.
designlow risk

Delete dead CSS, pixel-safe

Remove one unused or redundant style at a time and keep it gone only when every tested screen looks identical.

prompt
→ Claude
Reduce the CSS styling code [site] sends to users without changing tested screens. First capture representative pages, sizes, themes, and interactions, and record the built CSS size. Treat coverage reports only as suggestions. Remove one declaration or rule, rebuild, and rerun screenshots and project checks. Keep it only if every screenshot is pixel-identical and built CSS is smaller; otherwise revert. Stop when no supported candidate remains, progress stalls, or approval is required. Return reduction, evidence, and untested states.
designlow risk