# 5 · Check: in a real browser, at real widths, next to the design You can write "matches the design" as easily as you write the code. A front-end developer says it only after putting the build and the design side by side at several widths, filling it with real content and using it with a keyboard. Do the same, fix what you find, then report what you saw. This step comes on top of UI design's review (`5-review.md`) and Code craft's (`4-verify.md`); it doesn't replace them. --- ### K1 · Look at it next to the design, at every width **Rule:** Open the build in a real browser and take screenshots at 320, 375, 768 and 1280 wide (and wider, if the design has a wide frame). Put each one next to the design frame closest to it. Go through them part by part: spacing, alignment, type sizes, colours, the order of things, what wraps where. List each difference, then fix it or say why it's right (the design didn't cover that width, a rule here meant changing it). **Why:** The person who made the design will put them side by side within minutes. Every difference you didn't mention reads as a mistake, even the ones you made on purpose, and they stop trusting the rest. **Agent trap:** reading your own CSS and concluding it will match. Or looking only at the width the design was drawn for, where it matches because that's where you copied it from. **Check:** your report has screenshots or a list per width, and each difference you found is fixed or explained. If you can't open a browser, say so, and say what you couldn't check (UI design `5-review.md`, step 1). ### K2 · Run the checks at each width **Rule:** At 320, 375, 768 and 1280, run `checks/layout.js` in the browser console on the rendered page, plus UI design's `checks/spacing.js` and `checks/contrast.js` (and `checks/affordance.js` and `checks/stability.js` in Pro). Run them with real content, after animations have finished, in light and dark mode if both exist. Fix each result, or state why it's intentional. **Why:** The faults people hit first are the ones a screenshot hides: an element 6px too wide that makes the whole page scroll sideways, a 30px icon button a thumb misses, an image stretched by 8%. They're easy to measure and almost impossible to see. **Agent trap:** running the checks once at desktop width, where the tap targets aren't checked and nothing overflows, and reporting "checks clean". **Check:** your report names each check and the widths you ran it at, with the number of results and what you did about each. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - K3 · Break it with real content > - K4 · Use it with only a keyboard > - K5 · Weigh what people download ## Review: the build as the people who'll use it Before you report, go through each lens. Fix what you find **before** reporting, not after. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - Lens 1 · The designer > - Lens 2 · The person on a phone > - Lens 3 · The person with real content > - Lens 4 · The keyboard and screen reader user > - Lens 5 · The next developer ## Report honestly Your report to the person starts with the outcome, then: 1. **What you built**, in one or two sentences, in their words. 2. **How you checked it**: the widths you looked at, the checks you ran and what they found, the content you tried, the keyboard pass. 3. **Differences from the design**: each one, and why (a width the design didn't show, a rule here, a decision in D4). 4. **Assumed or not verified**: the states you decided without asking, anything you couldn't check (a real phone, a screen reader, a slow device). **Agent trap:** "Implemented the design, fully responsive." That sentence tells the person nothing they can check. Lead with what you saw and where; surface the gaps (Working with your human R1, R4).