Studio
Earlier this month I wrote about how to judge a design system without a designer's eye, and I ended on its limit. A rule anyone can check prevents nothing. A team in a hurry can skip "no colour outside these six" as easily as "make it feel premium". The one thing that changes is that skipping it becomes a choice somebody made, on the record.
On Monday we launched the new mistaek.com, rebuilt from scratch, and it gave us the first chance to test that limit on our own work. We sell standing decisions: rules a person who wasn't in the room can check a screen against without asking anyone. So before building a single page, we wrote down what our own site had to be. Then we asked which of those rules something other than a person could check.
Decided before anyone asked
Every Mistaek project opens with the same short list of house decisions, the things we don't ship without. Our site got that list too: text contrast at WCAG's AAA level and on a stricter perceptual measure called APCA, colour never carrying meaning on its own, everything usable by keyboard, and a weight budget for every page.
A few decisions were specific to this site. It uses no cookies, so it has no cookie banner. The analytics count visits without them, and the only thing the site keeps in your browser is whether you pressed Pause motion. That button exists because anything moving on its own for more than five seconds should be stoppable, and the site also follows the reduced-motion setting on your device. There's one typeface, Atkinson Hyperlegible Next, from a family designed for people with low vision.
Nobody asked for any of this. The people who would notice it missing are mostly people we haven't met yet, which is exactly why it had to be decided early.
Checked by something other than a person
A written rule lasts as long as someone remembers it. So we moved three rules out of the documentation and into the build, the step that turns our code into the live site.
A link to a page that doesn't exist stops the build. If the site's design tokens, the named colours and spacing everything else is built from, stop matching the file where they're defined, the change can't go live. And if any line of text ends on a single word, at any of five screen widths from a small phone to a wide desktop, the change fails as well.
The first two will look familiar to anyone who has run a build pipeline. The third is the strictest of the three, and I'd defend it on the grounds that it's also the smallest. One word alone on the last line of a paragraph harms nobody, which makes it the first rule anyone would let slide on a busy afternoon. Small rules wear away a line at a time, and you only notice once a page is full of them.
The limit still holds, and I'd rather say so. A line that genuinely needs to end on one word can be marked so the check skips it. That mark sits in the code, where anyone can search for it. Following the rule became the quickest path, and going around it became something a person did on purpose.
Where we fell short
Two of our own decisions didn't hold on this site. Both are recorded as exceptions, with a name and a reason.
The first is a grey. Our house decision asks body text to reach Lc 75 on APCA. The grey that met it sat so close to the white that on screen you couldn't tell the two apart. So the site uses a darker grey, #B4B4BC. It passes WCAG's AAA contrast at 8.94 to 1 and reaches Lc 61 on APCA, below our own target. When a device asks for more contrast, that grey turns white and the light weight turns regular.
The second is page weight. Content pages are meant to stay under 500 KB. Our two cases are built from real project photography, one of them with thirteen images, and they can go over.
There's also a number I'd rather state than round. On launch day the site scored 94 for performance on mobile, short of 100. The cause is known: the stylesheets load before the page can start drawing. The fix is scheduled.
For anyone who wants the rest, measured on launch day: PageSpeed Insights gave 100 on all four scores on desktop, and 100 on everything except performance on mobile. securityheaders.com gives the site an A+. Website Carbon gives it an A+ too, cleaner than 96% of the pages it has tested. An automated accessibility scan found zero violations across 14 page types, and automated scans only catch part of what accessibility covers.
What carries over to a product
A marketing site is the easy case. A product has more screens, more people working on it and better reasons to go around a rule. The question still works there: of the rules your team has agreed on, how many does anything other than a person check? I don't know what the usual answer is. I haven't put it to anyone's product but ours yet, and it's the first thing I'd ask.
If you'd like to ask it of your own product, the discovery call is free. I'll tell you whether a program makes sense for where you are, including when it doesn't.
