PROCESS
Polish Is a Feature
Eight rounds against the live site
After we rebuilt this site as one design system, we did something most small teams skip: we treated the finished site as the starting line. Over eight consecutive rounds we audited the production pages — not the local build — at 1440px and 390px, in light and dark, in English and Chinese, with the keyboard, with JavaScript switched off, and with an accessibility scanner running against every page.
Each round produced a short list of specific defects, each defect was checked against the reference system we measure ourselves by, fixed, deployed, and re-verified online before the next round began. Twenty-six fixes in total.
What the walkthroughs actually found
None of it was dramatic, which is the point. A reveal animation that could leave content permanently invisible in printed pages. Muted text in dark mode that measured 3.97:1 contrast when the standard asks 4.5:1. A heading that skipped a level. Two analytics beacons where there should be one. A hero image the browser discovered too late. Four render-blocking requests where one would do. Links in legal text distinguishable only by color. No RSS feed for a studio that says it builds in the open.
Every one of these survived a careful rebuild. They only fall to repetition: load the real page, on the real network, the way a reader would, and look again.
Why we budget for this
Polish is usually described as the last coat of paint. We think that gets it backwards. The difference between a tool that feels trustworthy and one that feels almost right lives in exactly these details — contrast ratios, focus order, load priorities, honest metadata. They are invisible when correct and corrosive when wrong.
So we treat polish as a feature with a budget: recurring rounds, measured against a benchmark, with evidence attached. The site you are reading is round-verified — and when it stops being that, the next round will catch it.
Written by the Zalize studio
-- zalize.com