← Studio library

Colour, one base varied by recipe

Reference notes. Source retained; historical claims may need rechecking.

Studio reference illustration

Color - one base color, varied by recipe

Digested from Erik D. Kennedy, Related Studio referenceColor in UI Design: A (Practical) Framework, Related Studio referenceThe HSB Color System: A Practitioner's Primer, and rule 2 of Related Studio reference7 Rules for Creating Gorgeous UI. Paraphrased in our vocabulary.

1. The core skill is variation, not palette theory

The fundamental color skill for interfaces is turning ONE base color into many usable variants - hover states, borders, tinted backgrounds, dark headers. Complementary-wheel palette theory does not produce interfaces; a base color plus a variation recipe does. (Facebook-blue in all its shades is one hue, systematically varied.)

2. The variation recipe (in HSB)

3. Black and white first

Design the page in grayscale until spacing, sizing, and hierarchy carry it alone; add color last and purposefully. One accent color over grayscale is already a complete system; a second color or a single-hue ramp is the ceiling for most pages. Too many colors in too many places is the fastest way to lose clean/simple.

4. Work in HSB, ship in hex

HSB matches how a painter thinks (what color, how rich, how bright); HSL's symmetric lightness axis does not. CSS speaks HSL/hex, so convert at the end.


Delta vs our system

CONFIRMS - Painter's palette. "One base color, varied" is exactly our painter's-palette discipline; Kennedy supplies the missing mechanics. - Black and white first = beauty-is-free / appetite. Restraint first, color as deliberate seasoning - same instinct as our scarce-emphasis and appetite rules. - Rejects palette-wheel theory - as do we; we never pick decorative palettes, we use project hex values.

ADDS - The darker/lighter recipe with directions. Our "painter's palette" names the goal but not the method. Concrete, adoptable: darker = B↓ S↑ (hue toward 0/120/240); lighter = B↑ S↓ (hue toward 60/180/300); never overlay black. - Luminosity inequality across hues - explains why token-equal colors don't look equal; contrast must be verified per pair, which his Accessible Color Generator does mechanically. - Grayscale-first as a working ORDER - our rules check the finished page; this dictates the sequence of making it.

TENSION - HSB vs our OKLch habit (feedback_html_output_rules.md uses OKLch). Not a real conflict - OKLch's perceptual lightness solves the same luminosity problem more rigorously than HSB eyeballing. Keep OKLch as the instrument; keep Kennedy's recipe as the intent (darker = richer, lighter = paler).

Source previewDownload original source