Taste Check
Reviews generated interface against design criteria you can count, instead of "looks fine".
When to reach for it
When an interface has come back and your only reaction is that it seems okay — before that becomes the version everyone gets used to.
What changes
- You get a defect list with file and line locations rather than an overall verdict.
- Countable findings: how many distinct spacing values, type sizes, and colours are in play, and which interaction states are missing entirely.
- Every layout is looked at with the longest realistic string, the empty state, and at a narrow width — not just the happy path.
- Values nobody can justify get replaced with ones from the existing scale, and the swap is listed.
Pairs with
- Accessibility PassCatches the accessibility failures generated interfaces produce almost every time.
- Spot the SlopNames the specific tells of generic machine-made code and design, so you can delete them.
- Read Your Own DiffMakes the agent review the change as a stranger would, before it tells you the work is done.
Taste Check
"Looks fine" is not a review. Run the checks, report defects with locations.
1. Look at it under real conditions
Before judging anything: the longest realistic string in every label, the empty state, the error state, a slow load, and the narrowest supported width. Most defects only exist in one of these.
2. Hierarchy
Name the single element the eye lands on first. If that is not the most important thing on screen, the hierarchy is the defect — not the colour, not the spacing.
3. Rhythm
Count the distinct spacing values in the code. More than about six and there is no scale. Then check the relationship: things that belong together must be closer than things that do not. Uniform gaps mean no grouping.
4. Type
Count the distinct font sizes and weights. Above five sizes it is not a scale, it is a collection. Check line height on the longest paragraph and measure line length — very long lines are hard to track.
5. Alignment
Pick a vertical edge and follow it down the screen. Note every element that breaks it without meaning to. Repeat for one horizontal baseline.
6. Colour
Count the distinct colours. For each, say what it means — brand, danger, muted text, surface. Any colour without a job is a defect. Check contrast on the smallest text and on placeholder text.
7. Motion
List everything that animates. For each, say what it communicates. Note anything over 300ms, anything that animates on first paint, and anything that moves without a reason.
8. States
For each interactive element, check hover, focus, active, disabled, loading, empty, and error. List which are missing. Generated interfaces routinely ship only the default state.
9. Write the verdict as defects
One line each: what is wrong, where it is, what to change it to. Then fix them.
Rules
- Do not report a conclusion without the counts. "Spacing is inconsistent" is an opinion; "eleven distinct gap values, four of them used once" is a finding.
- Do not fix by adding. Most fixes remove a border, a shadow, a colour, or a font size.
- Do not judge from a single screenshot of the ideal case.
- Do not accept a value that cannot be explained. If nothing justifies 13px or that particular grey, replace it with the nearest value from the scale that already exists.