La maggior parte dei team pensa che un design system sia un file Figma e una libreria di componenti. Quelli sono artefatti di un design system, non il sistema stesso. Il sistema vero è l'insieme di decisioni — scala degli spazi, logica dei colori, regole del motion, quando usare quale pattern — che permettono a un prodotto di restare coerente man mano che più persone, in più team, lo toccano.
La modalità di fallimento che vediamo più spesso non è una libreria di componenti mancante. Sono componenti che esistono ma le cui decisioni sottostanti non sono mai state scritte, così ogni nuovo collaboratore reinventa il ragionamento da zero, e il sistema deriva un po' a ogni aggiunta.
Ciò che costruiamo per i clienti è invece un piccolo insieme di primitive con regole esplicite allegate — non solo com'è fatto il pulsante, ma quando useresti un pulsante rispetto a un link testuale rispetto a una CTA magnetizzata, e perché. I componenti contano meno delle regole che li hanno generati, perché le regole si generalizzano a casi che nessuno aveva progettato.
Il test di un buon design system non è se appare curato nel file. È se un nuovo ingegnere, tra sei mesi, può costruire una schermata che nessuno ha progettato e farla sembrare che appartenga al sistema.