# Against systems - Kennedy's case vs our token machine

Digested from Erik D. Kennedy, [Why Beginning Designers Don't Need to Learn Grids, Type Scales, or Color Theory](https://www.learnui.design/blog/why-beginning-designers-dont-need-grids-type-scales-color-theory.html). This is the one article that argues *against* the shape of our system - captured honestly.

## His argument

1. **Grids** - built for fixed paper, broken on elastic screens (a 12-column grid on a 320px phone yields ~26px columns, below touch targets; widening the screen shouldn't widen every element proportionally). *Instead:* alignment. Content dictates its own width; on mobile, three rulers suffice (16px left, 16px right, center).
2. **Type scales / modular scales / golden ratio** - mathematically satisfying, practically hollow: a ratio that works on desktop yields absurd headlines on mobile, and "if you try this on a design that looks crappy, it will… still look crappy." *Instead:* corral attention - make differences that should read as different clearly different (10 vs 12pt is invisible; 50 vs 52pt more so), and stay consistent within a project.
3. **Color theory** - wheel-derived palettes don't build interfaces. *Instead:* one base color varied by saturation/brightness (see `color.md`).
4. **Personal style** - don't chase it; make good things and style follows.

**The diagnosis underneath: pick-a-number fatigue.** Design is a thousand number choices, and systems sell relief from choosing. His verdict: you can *outsource* the number-picking, or you can *learn the rationales*. Outsourcing gives brittle rule-following; rationales give judgment.

---

## Delta vs our system

**CONFIRMS**
- **Alignment over grids** - our baseline-alignment rule ("every element answers: what am I aligned to?") is precisely his replacement for grids. We never adopted a column grid; we adopted alignment. He endorses our choice.
- **Color: variation over palette theory** - full agreement (see `color.md`).
- **Consistency within a project** - his fallback position is exactly what our tokens enforce.

**ADDS**
- **The rationale test.** For each token in our system we should be able to say *why* - not "because 1.25" but "because a step must be visibly a step." The system doc mostly can; where it can't, the token is dogma by his definition.
- **Content dictates width** - a useful check against forcing every block into the same container when the content wants otherwise.

**TENSION - the honest one**
- **Kennedy rejects modular type scales; our system IS a modular scale (1.25 × 5 steps).** His critique lands on humans using a scale as a substitute for judgment, learned once and applied blindly across breakpoints. Our situation differs in kind: the "designer" here is a generator producing many pages across many sessions, and the scale is a *consistency contract* enforced by machine (token-audit.py), with the judgment layer kept separate (the 10-point Autocontrol, the squint/5-second test). We outsource number-picking *deliberately* so that judgment is spent on hierarchy and meaning, not on re-deriving 20px.
- **But his warning has teeth in two places:** (1) responsive behavior - a ratio tuned for desktop reading may need a flatter scale on mobile; our system doc is silent on breakpoints; (2) audit-passing ≠ good - a page can trace every value to a token and still have no hierarchy; the diagnosis that birthed our system said exactly this ("twenty font sizes and no hierarchy" was cured by the scale, but the scale alone doesn't create the hierarchy).
- **Resolution to propose to Frank:** keep the scale as law for consistency, adopt Kennedy's "corral attention" as the *criterion* the scale serves - differences must read as differences (our hierarchy-gaps-≥1-step rule already encodes this; name it as the rationale, not just the rule).