When a build appears, designers put it beside the composition and look for differences. Then they send a list: “this gap is 2px too wide”, “the text is 1px small”, “this grey is slightly dark”. The review is diligent, and it never ends — because the same class of difference reappears on the next screen.
The same note written two ways
Write one difference in both styles and the distinction becomes obvious.
Pixel notes turn the designer into the measuring instrument. Somebody has to keep holding a ruler up to the screen, and that job stops scaling as soon as there are more screens. Rule notes do the opposite: the rules become the instrument, and a list does the checking instead of a person.
An order for reviewing
Not every difference weighs the same. Working down this order surfaces the important ones first.
The bottom line does not disappear; it simply waits its turn. Debating letter-spacing while the empty state is unimplemented means the thing visitors meet after release is not the letter-spacing.
Which screens to review
Reviewing side by side with the composition has a trap: you only examine the screens you drew. Looking at the screens that were never in the file first catches far more — a list with one item, the item with the longest title, an item with no image, a filtered view returning nothing.
The same logic applies to real devices. Mobile seen by narrowing a browser window and mobile seen on an actual phone differ in text size, scrolling and touch targets.
How to write the review up
Group the review by rule rather than by screen and the developer can handle it in one pass. “Bottom padding is off-scale across the whole card component” is shorter and more accurate than “2px on the listing, the detail page and the related posts”.
Then finish with the places where the rules were missing. If the developer had no choice but to invent something, that is not an implementation error but a gap in the handoff. Filling that gap is where the next project starts.
Our review and verification steps are published in order on the process page, and related articles are collected in the development workflow archive.
Next part
One part remains. We close the series with a design QA checklist that runs everything above in one pass, just before release.