Measure the Design, Don't Eyeball It

None required, this lesson stands on its own. Recommended if you have time: Package Your First Skill, because the least-privilege and success-condition habits there are what keep a workflow like this honest.

Most AI design work fails the same way: you show the AI a site you like, it builds something that is roughly in the neighborhood, and everyone nods because nobody measured. 'Looks premium' is not a fact. It is a hope. The fix is to stop describing design and start measuring it.

Three things are measurable, and once you measure them the guessing stops. First, design tokens: the actual colors, fonts, spacing steps, corner radii, and shadows a real site uses. These are not opinions. A browser computes them for every element on the page, and you can read them out by real usage frequency, so you get the brand's true #1A1A1A text color and 8px spacing rhythm, not a screenshot you squint at. Second, faithfulness: when the AI rebuilds a screen, you can render your version at the target's exact dimensions and compare them pixel by pixel, which gives you a single difference number instead of 'close enough' (0 means identical, so a low number is the goal; some tools report the mirror image, a faithfulness percent where 100 means identical, which is the same fact read from the other side). Third, motion: animation can be scored against a fixed rubric (duration, easing, purpose, reduced-motion support, performance) so 'tasteful' becomes a checklist score, not a matter of taste.

Here is the before and after: the old way, you tell the AI 'match stripe.com' and accept whatever comes back. The measured way, you first extract Stripe's real tokens (the exact purples, the Inter type scale, the spacing steps), hand those numbers to the AI as the brief, then rebuild a section and measure the diff. On a simple page a faithful rebuild lands at or near 0 percent difference. That zero is the whole point: it is verification, not a feeling.

We built this into an internal design skill that does exactly this, and it earned the rule the hard way. The token reader was proven live on real sites with thousands of elements. The pixel comparison was proven by rebuilding a real third-party page from measured values, not copied code, and landing at or near 0 percent on a simple system-font page. Honest limit: full-pixel comparison is strict and works cleanly on simple pages (system fonts, few images). Image-heavy or custom-font pages need a looser regional check, not a single percentage, because one font swap can move every pixel. Measure what you can, and say plainly where the number stops being trustworthy.

The skeptic's objection is fair: why bother measuring when you can just look? Because your eye agrees with whatever you already expected. A number does not. The first time the AI's 'pixel-perfect' rebuild measures 14 percent off, you stop trusting the eye for good.

I want to rebuild a section of a website I admire and measure how close my version actually is, instead of guessing. The reference site is [paste a URL you like, e.g. a clean landing page]. Do this in order: (1) List the real design tokens this site uses: its main text and background colors as hex values, its font family and the sizes it uses for headings versus body, its spacing steps in pixels, and its corner-radius and shadow values. Pull the actual computed values, not approximations. (2) Using ONLY those exact values, write a single self-contained HTML file that rebuilds the site's hero section (headline, subtext, one button). (3) Tell me, in one number, your honest estimate of how faithfully this matches the original and what specifically would still differ if I rendered both side by side. (4) List anything you could not measure precisely (custom fonts, background images) and why those make a single match percentage unreliable.

Extracted tokens for a clean reference landing page:

Colors (by usage): text #0A0A0A, background #FFFFFF, surface #F5F5F5, accent #2563EB.
Type: Inter. Headline 48px / 700. Body 16px / 400. Caption 13px / 400.
Spacing steps in use: 4, 8, 16, 24, 48px. Corner radius: 8px on buttons, 12px on cards.
Shadow: 0 1px 3px rgba(0,0,0,0.10).

Rebuilt hero (single HTML file) uses those exact values, e.g. the button is #2563EB, 8px radius, 16px Inter, 12px/24px padding pulled straight from the spacing steps above.

Honest faithfulness estimate: roughly 95 percent faithful, which is about 5 percent difference, on layout and color. The 5 percent gap is real: the original loads Inter from a font CDN and I fell back to the system stack, so letter widths shift slightly, and the original hero has a faint gradient background image I could not reproduce from values alone.

What I could not measure precisely: the gradient image (it is a raster asset, not a token) and the exact web-font rendering. For pages like this, trust the color and spacing match as numbers, but treat the overall percentage as an estimate, not a verified 0 percent, because the font and image differences move pixels everywhere.

What good looks like

• The AI returned concrete values (real hex codes, pixel sizes, named fonts), not vague words like 'a dark color' or 'modern font'
• The rebuilt HTML uses those exact extracted values, so you can point at any color or spacing step and trace it back to the source
• You got a single faithfulness number, plus a specific list of what would still differ, not just 'this looks great'
• The AI told you honestly where the measurement breaks down (custom fonts, imagery) instead of claiming a perfect match

Now score a piece of motion instead of a static layout. Pick any animation: a button hover, a page transition, or a scroll effect on a site you like (or one the AI proposes for a project of yours). Score it against this 5-rule rubric and give each rule a pass or fail with one sentence of reasoning: (1) Duration is between 150 and 500ms for UI feedback, not slower. (2) Easing is a natural curve (ease-out or similar), not linear. (3) The motion has a clear purpose (guides attention, shows a state change), it is not decoration. (4) It respects a reduced-motion preference, so a user who disables animation still gets a usable result. (5) It performs smoothly by animating only transform and opacity, not layout properties that cause jank. Then give a final score out of 5 and name the single highest-impact fix.

Motion score for a 'card flips and bounces on hover' effect:

Rule 1 (duration): FAIL. The flip runs 900ms, far past the 150-500ms window, so hover feels laggy.
Rule 2 (easing): PASS. Uses ease-out, which decelerates naturally.
Rule 3 (purpose): FAIL. The flip reveals nothing new, it is decoration, so it adds delay without information.
Rule 4 (reduced-motion): FAIL. No prefers-reduced-motion fallback, so motion-sensitive users get the full spin.
Rule 5 (performance): PASS. Animates transform only, so it stays smooth.

Final score: 2/5.
Highest-impact fix: cut the duration to 200ms and drop the flip for a simple lift (translateY plus a soft shadow). That keeps the feedback, removes the gimmick, and the reduced-motion fallback becomes trivial.

What good looks like

• Every rule got an explicit pass or fail, not a soft 'it's pretty good'
• The final score is a number out of 5, so 'tasteful' became measurable
• The AI named one specific highest-impact fix, not a list of vague polish ideas
• You can explain why a 5/5 animation is restrained, not impressive, the goal is to serve the user, not flex technique