The critique round

Every page passes 202 gate checks. That is the floor. This round asks the question no linter asks: is it any good to use, and would a designer look at it and want to build in that system?

the build contract still binds. Nothing here licenses breaking it — least of all §1, the token rule. What follows is what to do once the page is already correct.

The bar

A visitor opens this portfolio and scrolls twenty screens. The ones they remember are the ones where somebody clearly knew the domain and knew the system, and spent the boldness in one place instead of decorating everywhere. The ones they forget are correct, complete, and anonymous.

Your page is currently somewhere on that line. Your job is to find out where, honestly, and move it.

The failure mode of this round is homogenisation. Twenty pages critiqued against one rubric will drift toward one house style unless every reviewer resists it. Your page should end up more itself, not more like its neighbours. If a change you are considering would also improve four other pages in the portfolio, it is probably a generic improvement and probably not the one worth making. Run direction_check.py --compare against your two nearest neighbours before and after; the number must not go up.

1. Do the task, first, with no notes

Open the page. Be the user in the brief — the ward nurse at 07:00, the purchasing manager clearing a queue, the householder whose well may be contaminated. Complete the task the screen exists for. Only then start writing.

Everything you find after doing this is better than anything you would have found reading source.

2. Score it, honestly

references/interface-critique.md is the rubric. Read it. Then:

• The cognitive-load checklist, eight items, count the failures. 4+ failures is the finding that outranks everything else.
• The ten heuristics, 0–4 each. A 4 means genuinely excellent, not "nothing obviously wrong." If your page scores 40 you applied the rubric wrongly. Note the specific moment behind every score below 3.
• Severity-rate every finding: 0 taste · 1 cosmetic · 2 minor, they get through · 3 major, blocked or reliably wrong · 4 catastrophe. Severity is frequency × impact × persistence — a severity-2 hit every session outranks a severity-3 in a yearly flow, and doing that arithmetic explicitly is the part reviewers skip.

Put the scores in your report. A review that reports only fixes hides how much of the page you actually looked at.

3. The render pass — this is where the findings are

assets/review/<slug>-{phone,laptop,wide}-{light,dark}.png holds six full-page renders of your page: 390px, 1440px and 1920px, in both schemes. Regenerate with node tools/review-shots.mjs <slug>.

Look at all six. Everything below the first fold on these pages has so far only ever been read as source — the plate in the ledger is the top 900px, and every gate so far has measured rather than looked. Specific things that hide down there:

• The quality collapse. The first screen got the attention; section four is often a list of divs. Does the care hold to the bottom?
• The spec panel as an afterthought. It is the last thing on every page and it is the thing a designer reads most carefully, because it is where you explain your decisions. Is it composed, or is it a <dl> nobody styled?
• The wide viewport. At 1920 does the page hold, or is it a 1200px column with 700px of nothing beside it? A void is a decision; an accidental void is a defect. Editorial and document archetypes may absolutely leave space — the question is whether it reads as intended.
• The phone. Is 390px a design, or is it the desktop with the columns stacked? The Fiori split, the Cloudscape console and the Atlassian board each have to become something else at that width, not merely narrower.
• Rhythm. Print the six images side by side in your head: does the vertical spacing have a system, or does every section pick its own?

4. The states nobody has looked at

The gates check the page at rest. Drive it:

• Hover, focus-visible, active and disabled on every interactive kind — and check that hover and focus-visible are different, because a focus ring that merely reuses the hover fill tells a keyboard user nothing.
• Every menu, dialog, popover and disclosure open — clipped by a card, escaping the viewport, no way out with Escape, focus not returned.
• The second state the contract asked for. Is it a real state, or a paragraph claiming one? An empty table with a sentence in it is a state; a grey box saying "No results" is not.
• Keyboard only, first Tab to last. Where does focus go, is it always visible, does anything trap it, does the order match the reading order?
• Screenshot anything you find. A screenshot against a finding beats a paragraph.

5. What "great" looks like, by archetype

Not a checklist — a standard to measure your own page against.

• Index / table — the eye lands on the row that matters without reading. Numbers right-aligned on aligned decimals, one column primary, a real zero state, sorting that means something, and the table gets the width.
• Shell — the rail earns its 280px. Current location unmistakable. The well is the product, not a frame around a smaller product.
• Console — one question answered in one glance, no scroll, and the tile that is wrong is the one you see first.
• Board — the shape of the work reads before any card does.
• Feed — every unit is the same object; the sentence does the work; recency is legible without a timestamp per row.
• Document — typography carries it. Measure, leading, and one focal size. Nothing else is allowed to be interesting.
• Editorial spread — the rhythm changes on purpose and you can say why for each section.
• Canvas — the work is the viewport; the chrome is dismissible and comes back.
• Wizard — one decision, visible spine, back always, and the review step before commitment.
• Split — the two halves are genuinely coupled; selecting on the left is answered on the right, and both are readable at once.

6. Fix, then prove it

• Fix every finding at severity 2 and above, and every severity-1 that is cheap. Anything you leave is named in your report with the severity and the reason.
• Taste-only changes go last and are labelled as taste.
• Every gate stays green. bash tools/check.sh <slug> — which now includes unsafe_patterns.py, the browser probes and the a11y probe — plus the system's own lint. Re-run after the last edit, not before it.
• Regenerate node tools/review-shots.mjs <slug> and look again. The second look is what catches the fix that broke the thing beside it.

7. Report

1. The cognitive-load count and the ten heuristic scores, with the moment behind each below 3.
2. Findings, severity-sorted, each with the fix you made.
3. What you deliberately left, with severity and reason.
4. What was already working — specifically. The good decisions are the ones most likely to be destroyed by the next pass.
5. direction_check.py --compare against your two nearest neighbours, before and after, to show the page did not drift toward them.
6. Final gate output.