Die meisten Teams denken, ein Designsystem sei eine Figma-Datei und eine Komponentenbibliothek. Das sind Artefakte eines Designsystems, nicht das System selbst. Das eigentliche System ist die Summe der Entscheidungen — Abstandsskala, Farblogik, Bewegungsregeln, wann welches Muster verwendet wird —, die ein Produkt kohärent halten, während mehr Menschen in mehr Teams mehr davon anfassen.
Das Fehlermuster, das wir am häufigsten sehen, ist nicht eine fehlende Komponentenbibliothek. Es sind Komponenten, die existieren, deren zugrunde liegende Entscheidungen aber nie festgehalten wurden, sodass jeder neue Mitwirkende die Argumentation von Grund auf neu erfindet und das System mit jeder Ergänzung ein wenig abdriftet.
Was wir stattdessen für Kunden bauen, ist ein kleiner Satz von Grundbausteinen mit expliziten, dazugehörigen Regeln — nicht nur, wie der Button aussieht, sondern wann man zu einem Button greift statt zu einem Textlink oder einem magnetisierten CTA, und warum. Die Komponenten sind weniger wichtig als die Regeln, die sie hervorgebracht haben, weil Regeln auch auf Fälle verallgemeinern, für die niemand designt hat.
Der Test für ein gutes Designsystem ist nicht, ob es in der Datei poliert aussieht. Es ist, ob ein neuer Ingenieur in sechs Monaten einen Screen bauen kann, den noch niemand entworfen hat, und ob dieser sich zugehörig anfühlt.