Open it when: something is built and you need to judge it. That covers design critique, technical audit, AI tells, accessibility, phones and other screens, and speed.
What we know
How to judge
- Judge the real rendered page, at the sizes it ships at. Never judge from one full-page thumbnail. [impeccable]
- Take a desktop shot at 1440 wide (full page) and a phone shot at 390 wide. Open each file to check it shows what its name says. [impeccable]
- Narrow targets get better results. One section looked at closely beats a whole page at a glance. [impeccable]
- Have a fresh agent do the final review. A reviewer that has read your whole conversation inherits your framing and your optimism. [impeccable]
- Report the verdict at its real size. "The reviewer scored all three fixes resolved" is fair. "No material issues remain" is not. [impeccable]
- If the user answers "ship it" with evidence that it's broken, their evidence beats your screenshots. Start a fresh full review instead of patching and approving it yourself. [impeccable]
- A clean result from a rule checker is a floor, not proof of quality. [impeccable]
- Check every answer with something rendered or in the source, never a bare "yes". [impeccable]
Critique: does it work for people?
- First question: does this feel made for this product, or could it belong to anyone in the category? [impeccable]
- Cover the name. Does it still read as a product of its category, and could someone do the task from it? [impeccable]
- impeccable scores against Nielsen's ten heuristics. A heuristic is a rule of thumb for judging whether a design is easy to use. [impeccable]
- 36 to 40: Excellent. 28 to 35: Good. 20 to 27: Acceptable. 12 to 19: Poor. 0 to 11: Critical.
- On marketing and portfolio pages, two of the ten may be marked "n/a". Then read the score as a percentage.
- impeccable says most real interfaces score 20 to 32 (asserted, no evidence shown).
- Mental load: at a decision point, four items or fewer is fine. Five to seven is pushing it. Eight or more is overload. [impeccable]
- One main action, one or two secondary ones, the rest in a menu. Keep top navigation to five items or fewer. [impeccable] impeccable bases the four-item limit on a 2001 study it names but doesn't show.
- Imagine named users, and report what broke for each. [impeccable]
- Alex, the impatient power user: can they finish the core task in under a minute?
- Jordan, the confused first-timer: is the first action clear within five seconds?
- Sam, on a screen reader or keyboard.
- Riley, the stress tester.
- Casey, distracted, one-handed on a phone: are actions in the bottom half, with targets at least 44 by 44?
- For a landing page, test with Jordan, Riley and Casey. For a dashboard, Alex and Sam. [impeccable]
Audit: does it work technically?
- An audit checks accessibility, performance, theming, responsiveness and whether the code holds together. It lists issues. It doesn't fix them. [impeccable]
- Each of the five scores 0 to 4, out of 20. 18 to 20 Excellent, 14 to 17 Good, 10 to 13 Acceptable, 6 to 9 Poor, 0 to 5 Critical. [impeccable]
- Rank every issue. [impeccable]
- P0 Blocking: fix now.
- P1 Major: real difficulty, or a failure of the WCAG AA accessibility standard. Fix before release.
- P2 Minor: a workaround exists.
- P3 Polish: no real impact.
- Unsure between two? Ask whether a user would contact support about it. If yes, it's at least P1. [impeccable]
- Keep P3s few. A long tail of small issues buries the ones that matter. [impeccable]
The tells of an AI-made page
Where the sources agree with our build
- Our build's list: a number on every section (01, 02…), a small capitals label above every section, a cream or beige background, gradient text, frosted glass for decoration, a coloured stripe down the side of cards, and rows of identical icon cards. [our build]
- Numbers belong only on a real sequence, like "how it works". [our build; impeccable]
- Let warmth come from the accent colour, the photos and the type. [our build]
- impeccable bans or flags every item on that list. It bans the small label above a heading outright: "no brief earns it back". [impeccable]
- frontend-design calls out overused fonts (Inter, Roboto, Arial, system fonts), purple gradients on white, and predictable layouts. [frontend-design]
More tells impeccable flags [impeccable]
- The hero-number template: big number, small label, supporting stats, accent.
- A tiny capitals label or pill sitting right above the main headline.
- Purple or violet gradients, and cyan on dark.
- Coloured glows: halos with no offset, radial glows on dark pages, a "spotlight" behind the hero.
- Pulsing status dots not tied to live data.
- A fake typing cursor in the hero.
- Content that scrolls by itself forever.
- A full-sentence headline set at display size.
- An oversized italic serif headline. Editorial pages may want it.
- A small rounded-square icon box above a heading.
- Hard offset shadows, decorative grid backgrounds, and stripe backgrounds.
- Writing tells: many em-dashes, three or more sections ending "X. No Y.", calling something "theater", and buzzwords.
What is asserted without evidence
- impeccable says these tells "show up again and again, across models and projects". It gives no data (asserted, no evidence shown).
- It calls the side stripe, and purple gradients with cyan on dark, "the most recognizable" tells (asserted, no evidence shown).
- It says every generator outputs the icon box above a heading (asserted, no evidence shown).
Where the sources clash
- awesome-design-md shows real brands using some of these on purpose: cream pages (Claude, Cursor, Oura), monospace section labels (xAI), and one hero gradient (Vercel, Stripe, Mistral). [awesome-design-md]
- impeccable says the brief wins. A brief that pins one of these keeps it. The tells are for when the look was left free. [impeccable]
- Our build avoided cream, section labels and gradient text. [our build]
Accessibility
- Body text needs 4.5 to 1 contrast. Large text, controls, icons and focus rings need 3 to 1. [impeccable]
- A grey chosen for elegance came out at about 2.5 to 1. Never lighten text for looks. [our build]
- The audit checks contrast, missing ARIA labels, keyboard traps, heading order, alt text and form labels. [impeccable]
- Heading levels must not skip, such as h1 then h3. [impeccable]
- Keyboard, touch and screen-reader order must match the visual order. [impeccable]
- Colour is never the only signal. [impeccable]
- Touch targets at least 44 by 44px. [impeccable]
- Automated checks catch only part of it. Astryx runs the axe checker on every change, and still says keyboard, focus and screen-reader behaviour need checking by hand. [Astryx]
- Astryx's README calls all its 150+ components accessible. Its own contributing guide says a green automated check doesn't prove that. [Astryx]
- Reduced motion is in Drawer 3.
Phones and other screens
- No sideways scrolling on a phone. Check at 375 pixels wide. Anything decorative or scaled up sits inside a box that hides overflow. [our build]
- Run the real copy at every breakpoint and fix what overflows. [impeccable]
- Flex and grid overflow: add
min-width: 0to the items. [impeccable] - Write phone styles first, then add
min-widthmedia queries. [impeccable] - Add a breakpoint where the design breaks. Three usually do: 640, 768 and 1024px. [impeccable]
- Also check common desktop widths, 1280 to 1600. [impeccable]
- Detect touch or mouse with the
pointerandhoverqueries, not screen size. [impeccable] - Use
srcsetandsizesfor image sizes, and<picture>when the crop must change. [impeccable] - Adapting is rethinking for the new screen, not scaling pixels. [impeccable]
- Print: page breaks in sensible places, no navigation, full URLs, page numbers. [impeccable]
- Email: at most 600px wide, one column, inline CSS, a table layout, nothing on hover. [impeccable]
- Handle phone notches with
env(safe-area-inset-*)andviewport-fit=cover. [impeccable] display: nonehides content but still downloads it. [impeccable]- Screenshots check layout, never a gesture. Test on at least one real iPhone and one real Android. [impeccable]
- Astryx themes can change values by screen width, pointer, contrast or motion setting. [Astryx]
Speed
- Measure before and after. Fix the biggest slowdown first. Don't speed up what isn't slow. [impeccable]
- Targets: largest content shown within 2.5 seconds (LCP), response to input within 200 ms (INP), layout shift under 0.1 (CLS). [impeccable]
- Generated images come out around 2,700 pixels wide and 2.5 MB each. [our build]
- Resizing to about 1,800 pixels took one site's images from 22 MB to 3.5 MB with no visible loss. Squeezing without resizing saved only about 7%. [our build]
- Serve the right size, not 3,000px for a 300px slot. Use WebP or AVIF. [impeccable]
- Lazy-load images below the first screen. Never lazy-load what's on the first screen. [impeccable]
- impeccable says 80 to 85% image quality is usually invisible (asserted, no evidence shown).
- Set image and video sizes, or use
aspect-ratio, so the page doesn't jump. [impeccable] - Read all layout values first, then write all changes, so the browser doesn't recalculate the page between each one. Use
content-visibility: autoon long lists. [impeccable] - Test on a cheap Android phone on slow 3G, not just a flagship. [impeccable]
Tools in this drawer
- Tool: design review with scores (impeccable critique). Pick it to judge whether the design works for people and feels made for this product.
- Tool: technical audit (impeccable audit). Pick it to list technical faults by severity before release.
- Tool: rule checker for AI tells (impeccable detect). Pick it for a quick, repeatable scan for AI tells and mechanical faults.
- Tool: final quality pass (impeccable polish). Pick it when the direction is right and you want the last details fixed.
- Fit other screens:
/impeccable adapt <target>. Pick it when the page breaks on phones, tablets, print or email. - Find the real slowdown:
/impeccable optimize <target>. Pick it when the page feels slow and you need to know why.