Product pages led by specifications

AHA’s Smart Locks page had a 2,037 px block of bullets and not one specification. The datasheet existed only inside the PDF.

What a full-page capture showed

We diagnosed before designing, and the problem wasn’t styling:

• A “Why it matters” block 2,037 px tall: one dense paragraph and three bullet lists, 26 items in all.
• The bullets repeated facts already given in the rows above and in the printed catalogue below. Three formats, one set of facts.
• No specification anywhere on the page.
• No link to a sibling product.

All ten product pages followed the pattern, with 4 to 32 bullets each.

A layout led by specifications

On 9 September all ten pages moved to one order: hero, a masthead with the headline facts and the download, story rows with alternating images, specification, what it runs with, why it matters, compatibility, the experience centre, contact. In plain terms: what it is, how it works, what it’s made of, what it works with, why that matters, come and see it.

Two shared templates read one data file, the same one the PDF catalogue renders from, so page and catalogue can’t drift apart:

• The spec table replaced the hand-written feature bullets, with 4 to 20 rows per product in the same ruled layout as the printed sheet.
• “What it runs with” added 37 internal links, 3 to 6 per page, each with a line on why that product matters to this one. The build throws on a product name with no page, so a dead card can’t ship.

Built with Claude Code, then checked at 390 and 1440 px on all ten: 0 px of sideways overflow.

Nothing deleted on trust

Every bullet was checked against the specification data before it was removed. That found one fact that lived only in the bullets (unlocking a bedroom lock can trigger a scene), and it went into the data first. It also found a claim the product documentation didn’t support, RGB support on the lighting drivers, which left with the bullets.

Where a spec isn’t confirmed, the sheet says so: the Aroma Diffuser’s sheet states that capacity, refill type, room coverage and power source aren’t published yet, rather than padding it with plausible numbers. Product prices stay off every sheet.

Catalogues: lighter, and behind the form

The StarLight catalogue was 5.4 MB. It’s now 1.5 MB, and most of the other catalogues shrank with it.

The cause was pixel count, not file size. Chrome decodes each image and re-encodes it into the PDF, so StarLight’s two source images, only 283 KB on the CDN, went in at 2.1 and 3.1 megapixels. Each image now has a print-sized copy, sized from what it actually renders at: about 1.6× its placed size gives 150 dpi on A4. The first attempt, a blanket 1,200 px, left the StarLight hero carrying nearly twice the pixels its layout could show.

On 10 September, at my request, the catalogues went behind the lead form. A download click remembers which catalogue was asked for, scrolls to the form and relabels the button “Get the catalogue”. One submission unlocks every catalogue in that browser, and the thank-you page lists all ten with the requested one first. Three new dataLayer events (gate, unlock, download) shipped for Tag Manager, unwired at launch. It’s a soft gate: the files stay public at their own addresses.

Every image on the CDN, enforced by the build

The same day I set a hard rule: every image comes from the image CDN, never from the repo. An audit of the built site found about 1,750 image references, 332 of them pointing at 18 local files, among them the favicon, the home-screen icon, the share image and print-sized catalogue copies.

They were moved to the CDN or repointed at CDN copies, and a guard now runs after every build and fails it on any image reference that isn’t a CDN URL. It was proven both ways: a normal build passes, and a self-test with a fake offender fails. Its first run caught the 404 page’s own favicon, which no template edit had reached. By 21 September the live site had zero off-CDN images.

One limit, found later: the guard checks the host, not whether the file exists.

Rules I’d keep

1. Capture the whole page before redesigning it. The fault was structure, not styling.
2. One data file for the page and the PDF, so they can’t disagree.
3. Delete nothing on trust. Check each bullet against the data first.
4. Size images by the pixels they render at, not by file size.
5. Make the build enforce the rule, and prove the guard can fail.