Deconstructing great interfaces.

This opens a new series: design taste for AI engineers. The premise is simple. Taste is not a gift, it is pattern recognition, and pattern recognition is trained the same way everything else is trained: on labeled examples, with attention. Engineers who ship AI products need this training most, because the model has stopped being the moat. Every team has API access to the same frontier models; the interface is where products now win or lose, and most engineer-built interfaces lose on sight.

The fastest training method we know is deconstruction. Not browsing galleries and nodding, but picking one site that works and taking it apart with devtools until you can say, in numbers, why it works. This post is the full method: five layers, exact steps, and a checklist you can rerun on a new site every week.

Why deconstruction, and why now

Designers train this way already. Type designers redraw classic faces; art students copy paintings stroke by stroke. The exercise is not forgery, it is forced attention: you cannot copy what you have not seen, so copying makes you see. Engineers have a better instrument for the same exercise than any art student ever had. Every production interface ships with its source attached. Devtools is a dissection kit that designers of the print era would have killed for, and most engineers only use it to debug flexbox.

One pass through this method takes about an hour. Do it weekly for two months and something shifts: you stop seeing "clean" and start seeing "one family, two weights, 8px grid, single accent." Once you can see the numbers, you can ship the numbers. That is the whole series in one sentence.

Step 0: pick one site that has already been judged

Do not audit a random site; audit one that has survived curation. Three galleries do the filtering for you:

• Godly: astronomically good web design, heavy on the dark, confident, motion-rich style engineers tend to want anyway.
• siteinspire: the broadest catalog, filterable by style and industry, strong on restrained editorial layouts.
• Land-book: landing pages specifically, which is the page type most product engineers ship.

Pick one site, not five. Criteria: it should be close to something you will build (a product landing page, a docs site, a portfolio), and it should look inevitable, the kind of page where nothing seems movable. Inevitability is the tell of a tight system, and tight systems yield clean measurements. Our resources page keeps a longer list of galleries and picks worth your hour.

Layer 1: count the typefaces and sizes

Open the site in Chrome. Open devtools (Cmd+Opt+I, or F12), open the command menu (Cmd+Shift+P), type css overview, and hit enter. Click "Capture overview." The Fonts section now lists every font-family on the page with every size, weight, and line-height in use. Firefox users: the Fonts tab in the Inspector does the same job and shows "All Fonts on Page."

For a version you can paste into notes, run this in the console:

const type = new Set();
document.querySelectorAll('body *').forEach(el => {
  if (!el.innerText || !el.innerText.trim()) return;
  const s = getComputedStyle(el);
  type.add(`${s.fontFamily.split(',')[0]} ${s.fontSize} / ${s.fontWeight}`);
});
console.log([...type].sort().join('\n'));

Now count. A gallery-grade site almost always lands at one or two families and five to seven distinct sizes. When you see two families, they have separated jobs: one for display, one for UI text, sometimes a mono for labels and data. Check the ratio between adjacent sizes; you will usually find a rough scale, each step 1.2 to 1.5 times the last, not sizes chosen ad hoc per component. Then look at what is missing: no size used exactly once, no third family that shows up for a single button. The discipline is in the absences.

Record three numbers: families, sizes, weights. The typical result for a strong page reads like 2 families · 6 sizes · 3 weights. Compare that to the last app you shipped. Most engineer-built products carry a dozen sizes because every component chose its own; that alone explains much of the "something is off" feeling. This layer gets its own deep treatment in Typography for engineers.

Layer 2: measure the spacing rhythm

Spacing is where amateur and professional pages diverge most, and it is invisible until you measure it. In the Elements panel, click through the page's major sections and read the box model diagram at the bottom of the Computed tab: padding-top, padding-bottom, and the gaps between siblings. Or collect them all at once:

const gaps = new Set();
document.querySelectorAll('section, main > *, header, footer').forEach(el => {
  const s = getComputedStyle(el);
  [s.paddingTop, s.paddingBottom, s.marginTop, s.marginBottom, s.rowGap]
    .forEach(v => { if (v && v !== '0px' && v !== 'normal') gaps.add(parseFloat(v)); });
});
console.log([...gaps].sort((a, b) => a - b));

Look at the sorted list. On a disciplined site it snaps to a unit: everything is a multiple of 4 or 8, and the multiples are few. [8, 16, 24, 32, 64, 96, 160] is a rhythm; [7, 11, 13, 18, 23, 25, 31, 37] is noise. Two more things to read from the measurements: spacing grows with hierarchy, so the gap between sections is a clear multiple of the gap between paragraphs; and the page is emptier than you would ever dare. Hero sections on curated sites routinely carry 120 to 200px of vertical padding. Whitespace is the cheapest signal of confidence there is, and it costs zero bytes.

Layer 3: extract the color count

CSS Overview already captured this: its Colors section groups every background, text, and border color on the page. The console version:

const colors = new Set();
document.querySelectorAll('body *').forEach(el => {
  const s = getComputedStyle(el);
  [s.color, s.backgroundColor, s.borderTopColor].forEach(c => {
    if (c && c !== 'rgba(0, 0, 0, 0)') colors.add(c);
  });
});
console.log(colors.size, [...colors].sort());

The raw count will surprise you by being small. Strong pages typically resolve to a background, two or three neutrals for text at different emphasis levels, a border tone, and one accent. Under ten values doing every job on the page. Now check what the accent is allowed to touch. On disciplined sites it appears only on things you can act on: links, buttons, active states. The moment an accent decorates headings, icons, and dividers alike, it stops meaning anything. Scarcity is what makes it read as a signal.

Layer 4: map the visual hierarchy

Hierarchy is the order the page wants your eye to move in, and there is a crude, effective way to expose it. In the console:

document.documentElement.style.filter = 'grayscale(1) blur(6px)';

The page is now unreadable, which is the point. Whatever still stands out is the true hierarchy: the shapes and contrasts that survive when the words are gone. Note the order in which blocks pull your eye, then remove the filter and check the order against the content. On a great page they match: the biggest, highest-contrast block is the one claim that matters, and each step down in visual weight is a step down in importance. On a weak page the blur test surfaces a carousel arrow or a cookie banner first. Grayscale alone is also worth a pass: if the page still has clear hierarchy without color, color was reinforcement, not a crutch.

Layer 5: name the one move

Every site worth deconstructing has one dominant decision the others serve. Oversized type on a strict grid. A single warm accent on a cold gray field. Extreme whitespace with tiny mono labels. One continuous scroll animation that everything else stays quiet for. Write the move down in one sentence. This is the step engineers skip, and it is the one that builds taste rather than a spreadsheet: the numbers tell you what was done, the sentence tells you why. If you cannot write the sentence, run the layers again; the move is in the measurements somewhere, usually in whichever number is most extreme.

Now rebuild one section

Reading measurements trains recognition. Building from them trains judgment. Take the hero, or one content section, and rebuild it from scratch: one HTML file, one style block, no framework, no peeking at the source's CSS beyond what you measured. Start by writing the tokens you extracted:

:root {
  --bg: #0a0a0b;
  --text: #ececf1;
  --dim: #9a9aa3;
  --accent: #5b6cff;

  --size-1: 14px;  --size-2: 16px;  --size-3: 20px;
  --size-4: 28px;  --size-5: 44px;  --size-6: 72px;

  --unit: 8px;   /* every gap is a multiple of this */
}

Then build the section using only those values. The constraint is the exercise: every time you reach for a 13px font or an 18px margin and the tokens refuse, you feel exactly where your defaults differ from the target's discipline. Your rebuild will be visibly worse than the original, and the gap is the curriculum. Put them side by side and diff: their heading is tighter (check letter-spacing and line-height, the two properties engineers never set), their gaps are bigger, their grays are closer together than yours. Fix your copy until the diff shrinks. An hour of this teaches more than a month of gallery scrolling.

The checklist

Run this on one new site each week. It fits in an hour, and the numbers go in a notes file so sites become comparable over time.

Where the series goes next

Each layer in this teardown gets its own tutorial. Typography for engineers covers choosing families and building a scale instead of measuring someone else's. Spacing, color, and hierarchy turns layers two through four into systems you can ship. Motion and microinteractions handles the layer devtools cannot freeze. Presentation design for engineers applies all of it to the slides your work gets judged through. The resources page collects the galleries, tools, and references the whole series draws on.

The through-line does not change: taste is trainable, the training is measurement plus rebuilding, and the engineers who put in the hours will ship products that look like someone chose every pixel. Because by then, someone did.