Du brauchst kein Designsystem
Die meisten Teams, die ein Designsystem ausliefern, spielen Reife nur nach. Die Wartungskosten überholen den Nutzen, KI-Generierung lässt die Rechnung kollabieren, und ein Stack aus Tokens, Primitives und Geschmack schlägt ein durchspezifiziertes System für 95 % der Organisationen.
Du brauchst wahrscheinlich kein Designsystem. Du brauchst ein paar Design Tokens, eine kleine Komponentenbibliothek und jemanden im Team mit Geschmack. Das Ding, über das dein liebster Design-Twitter-Account ständig postet, die Figma-Datei mit 400 veröffentlichten Komponenten und 12 Themes, ist ein Vollzeitprodukt, für das dein Acht-Personen-Startup bezahlt, ohne je etwas davon einzufahren.
Das ist die Meinung, von der die ganze Branche weiß, dass sie stimmt, und die keiner laut ausspricht. Die Wartungsrechnung ist real. Der Nutzen ist größtenteils eingebildet. KI-Generierung hat die Lücke zwischen beiden gerade noch größer gemacht.
Die 95 % der Teams, die ein Designsystem ausliefern, spielen Reife nur nach (LARP). Die 5 %, die wirklich eines brauchen, sind meist nicht die Teams, die die Frage stellen.
Ein Designsystem ist ein Produkt, kein Nebenquest
Ein echtes Designsystem hat seine eigene Roadmap, sein eigenes Changelog und seine eigenen Kunden. Diese Kunden sind die Engineers und Designer, die das eigentliche Produkt ausliefern. Wenn niemand dafür abgestellt ist, das System zu pflegen, ist es kein System. Es ist eine Momentaufnahme.
Schau dir an, wer Designsysteme gut ausliefert. Stripe hat ein dediziertes Design-Infra-Team. Shopify Polaris hat eine eigene Organisation. GitHub Primer hat ein öffentliches Repo mit versionierten Releases.
Atlassian investiert seit Jahren in ein System, dessen Umfang die meisten Teams nie erreichen werden. Jedes davon ist ein Produktteam, das Tooling für eine interne Kundschaft baut, die in die Tausende geht.
Jetzt schau dir die typische Version an. Eine Senior-Designerin hat sechs Wochen in Figma verbracht, 80 Komponenten veröffentlicht, eine Notion-Seite geschrieben, die kein Engineer liest, und zwei Themes ausgeliefert. Sechs Monate später ist die Hälfte der Komponenten veraltet, die Tokens driften vom Code weg, und das Team kopiert wieder Tailwind-Klassen. Das System ist nicht gescheitert. Das Team hat es nicht besetzt.
Die Wartungsrechnung, die keiner in die Folien packt
Der Nutzen-Pitch lautet: einmal bauen, ewig wiederverwenden. Die tatsächliche Rechnung: einmal bauen, dann ewig warten und manchmal einen Teil davon wiederverwenden.
Jeder existierende Design Token muss zwischen Figma und Code synchron gehalten werden. Jede Komponentenvariante muss getestet werden, wenn das Framework ein Upgrade bekommt. Jeder Breaking Change in Radix, React oder Tailwind zieht sich durch jedes abhängige Produkt. Dokumentation verrottet innerhalb eines Quartals.
Die Storybook-Instanz geht bei einem Dependency-Bump kaputt, und drei Wochen lang merkt es keiner. Die veröffentlichte Figma-Bibliothek hinkt dem Code um einen Release hinterher. Die Themes laufen auseinander. Die Komponenten im System sind nicht die Komponenten im Produkt.
Die ehrliche Buchhaltung sieht so aus. Ein „System" aus sechs Komponenten kann echte Zeit sparen. Ein System mit 200 Komponenten in einer Firma mit 12 Leuten ist eine Steuer. Die Nutzenstunden wachsen linear, die Wartungsstunden wachsen exponentiell, und irgendwann kreuzen sich die Linien. Die meisten Teams überschreiten diese Linien, ohne es zu merken, weil die Wartung als Slack-Nachricht am Freitagnachmittag auftaucht statt als Zeile in der GuV.
KI-Generierung hat die Rechnung gerade kollabieren lassen
Das ganze Argument für ein Designsystem ruhte auf einer einzigen Zahl: den Kosten, eine neue, gut gestylte Komponente herzustellen. Diese Zahl ist jetzt ein Rundungsfehler.
Ein Junior-Engineer kann tippen „gib mir eine Einstellungsseite mit Sidebar, drei Abschnitten und einer Speicherleiste, die dem Loading-State-Muster folgt" und liefert in zwanzig Minuten eine funktionierende Komponente aus. v0 erzeugt standardmäßig Output in Form von Shadcn. Cursor und Claude können einen ganzen Flow gegen bestehende Primitives refaktorieren. Der Nutzen, den ein Designsystem früher geliefert hat, nämlich schnelle Erzeugung konsistent aussehender UI, ist jetzt ein Gratisservice jeder IDE am Markt.
Die Systemsteuer hat sich nicht verändert. Der Nutzen ist eingebrochen. Das ist die ganze Geschichte. Teams, die 2022 Designsysteme gebaut haben, um schneller zu liefern, sind jetzt langsamer als Teams, die Shadcn plus Tailwind plus einen Prompt ausliefern, weil jedes KI-Tool auf Letzterem trainiert wurde und Ersteres ignoriert.
Die 5 %, die wirklich ein Designsystem brauchen
Ein echtes Designsystem zahlt sich nur aus, wenn eine bestimmte Reihe von Bedingungen allesamt erfüllt ist. Fehlt eine, fällt die Rechnung in sich zusammen.
- Mehrere Produkte mit einer gemeinsamen Identität. Atlassian hat Jira, Confluence, Trello und ein Dutzend mehr. Eine Identität, viele Oberflächen. Das System ist die Vereinheitlichungsschicht.
- Headcount in den Hunderten, nicht in den Dutzenden. Unter 50 Produkt-Engineers ist jede Komponente nur eine Slack-Nachricht von der Korrektur entfernt. Über 200 skaliert das nicht mehr, und ein System wird der einzige Weg.
- Ein besetztes Design-Ops- oder Design-Infra-Team. Ein Designsystem ohne Owner ist ein Friedhof. Der Owner muss eine echte Rolle sein, kein Projekt mit 20 % Zeitanteil.
- Externe Nutzer. Open-Source-Designsysteme wie GitHub Primer oder Shopify Polaris sind zugleich Produkte für Entwickler. Die Wartungskosten rechtfertigen sich durch externe Adoption.
- Eine regulierte oder barrierefreiheitslastige Domäne. Gesundheit, Finanzen, Behörden. Das System kodiert Compliance und Audit-Tauglichkeit, ein Nutzen, den kein einzelnes Team nachbauen kann.
Wenn ein Team alle fünf Punkte abhakt, ist ein Designsystem die richtige Entscheidung. Wenn ein Team einen oder zwei abhakt und ein Produkt mit 40 Engineers ausliefert, ist ein Designsystem Cosplay. Der Beitrag über das Anti-Dashboard behandelt ein verwandtes Muster: Infrastruktur für eine Organisationsgröße bauen, die man noch gar nicht hat.
Das minimal tragfähige visuelle System
Für die 95 % lautet die Antwort ein Stack aus drei Schichten, der fast nichts in der Wartung kostet und fast denselben Output liefert.
| Schicht | Was es ist | Tools | Wartungskosten |
|---|---|---|---|
| Tokens | Farbe, Typografie, Abstände, Radius, Schatten als Variablen | Tailwind-Config, CSS-Variablen, Figma-Variablen | Niedrig. Eine Datei. Quartalsweise aktualisiert. |
| Primitives | Headless oder gestylte Komponenten, standardmäßig barrierefrei | Shadcn, Radix, Headless UI, Cal.com-Primitives | Niedrig. Vendored, nicht gewartet. Update bei Bedarf. |
| Geschmack | Eine Person, die weiß, wann man die Regeln bricht | Eine Senior-Designerin oder ein designaffiner Engineer | Gratis, wenn du gut einstellst, unendlich, wenn nicht. |
Das ist der gesamte Stack. Tokens geben dir Konsistenz. Primitives geben dir Barrierefreiheit und Verhalten. Geschmack gibt dir die Schicht, die kein System kodieren kann: Urteilsvermögen darüber, wann sich die Regeln biegen sollten.
Die Teams, die 2026 die saubersten Produkte ausliefern, nutzen eine Version davon. Linear läuft auf einem winzigen Token-Set, eigenen Primitives und besessenem Geschmack. Vercel liefert eine umfangreiche Tailwind-Config plus eigene Primitives.
Cal.com veröffentlicht seine Primitives öffentlich. Resend und Loops liefern UI in Shadcn-Form mit hauseigenen Tokens obendrauf.
Notion läuft auf einem kleinen Set an Tokens und einem bewusst engen Komponentenvokabular. Keiner von ihnen hat ein „Designsystem" im Atlassian-Sinn. Alle haben einen Marketing-Site-Stack, der kohärenter aussieht als bei Firmen, die zehnmal so groß sind.
Warum Shadcn die Kategorie Designsystem auffrisst
Shadcn ist keine Komponentenbibliothek. Es ist ein Auslieferungsmechanismus für den neuen Standard. Die Primitives werden in die Codebasis vendored, mit Tailwind gestylt und sind barrierefrei, weil Radix darunter die Schwerarbeit erledigt. Die Nutzer besitzen die Komponenten, können sie frei editieren und werden nie von Upstream-Releases ausgebremst.
Das ist der Todesstoß für die meisten internen Designsysteme. Der Grund, warum Teams früher ihr eigenes bauten, war Kontrolle. Shadcn gibt die Kontrolle gratis. Der Grund, warum Teams früher Storybooks ausgeliefert haben, war Auffindbarkeit.
Shadcn veröffentlicht seine Docs öffentlich, und KI-Tools indexieren sie. Der Grund, warum Teams früher Figma-Bibliotheken veröffentlicht haben, war Konsistenz. Shadcn-Primitives sind konsistent genug, dass jeder Prompt dagegen Output erzeugt, den das Team schon zu bewerten weiß.
Shadcn plus Tailwind plus ein Token-Set ist der visuelle Standard-Stack von 2026. Das produziert jedes moderne KI-Codegen-Tool von Haus aus. Das liefert jedes neue Produktteam zuerst aus. Es ist das Modell Primitives plus Geschmack in zwei Repos und einer Config-Datei. Das Designsystem als eigenständiges Artefakt, mit eigener Publishing-Pipeline und eigenem Team, ist jetzt der Sonderfall.
Wann sich ein echtes System endlich rechnet
Die ehrliche Version der Frage „Brauchen wir ein Designsystem?" lautet: „Haben wir die Wartungsschwelle schon überschritten?"
| Signal | System nötig? |
|---|---|
| Zwei Engineers liefern in derselben Woche inkonsistente Buttons aus | Nein. Füge eine Token-Datei hinzu. |
| Drei Produkte teilen sich eine Marke und driften visuell auseinander | Vielleicht. Beginne mit gemeinsamen Tokens. |
| Mehrere Teams liefern dieselbe Komponente jedes Quartal anders aus | Ja. Zeit für gemeinsame Primitives. |
| Eine bestimmte Komponente wird in sechs Monaten von vier Teams neu gebaut | Ja. Befördere sie ins System. |
| Das Onboarding einer neuen Designerin dauert zwei Wochen, weil Konventionen Stammeswissen sind | Ja. Das System ist jetzt ein Gewinn. |
| Externe Entwickler nutzen deine Komponenten | Ja. Das System ist ein Produkt. |
| Compliance- oder Barrierefreiheits-Audits landen auf deiner Roadmap | Ja. Kodiere es einmal. |
Wenn ein Team drei oder mehr dieser Signale trifft, ist ein echtes System gerechtfertigt. Bei einem reicht eine Token-Datei. Dieselbe Logik zeigt sich darin, wie das Preisseiten-Problem und Onboarding ohne Onboarding Koordination auf Oberflächenebene statt auf Systemebene lösen.
Das Muster, dann die Pointe
Das Reife-Angeben steht auf dem Kopf. Die Teams, die 2026 die kohärentesten Produkte ausliefern, sind nicht die mit den größten Designsystemen. Es sind die mit der kleinsten visuellen Schuld. Knappes Token-Set, dünne Primitives-Schicht und eine Designerin mit Geschmack, die oft Nein sagt.
Echte Designsysteme sind Infrastruktur für Organisationen, die der Alternative entwachsen sind. Sie sind kein Meilenstein, den jedes Team erreichen sollte. Sie sind kein Statussymbol. Sie sind nicht die Antwort auf „Wir wollen professioneller aussehen."
Ein Team, das eines baut, bevor es sich das Wartungsbudget verdient hat, liefert dasselbe Produkt mit langsamerem Takt und schwererer Datei aus. Das Team, das Tokens plus Shadcn plus Geschmack ausliefert, liefert dasselbe Produkt mit schnellerem Takt aus und steckt die gesparte Zeit stattdessen in das Einstellungsseiten-Problem.
Die Frage lautet nicht „Haben wir ein Designsystem?" Sie lautet „Zahlen wir Wartung auf der richtigen Abstraktionsebene?"
FAQ
Was ist der Unterschied zwischen einem Designsystem und einer Komponentenbibliothek?
Eine Komponentenbibliothek ist eine Sammlung wiederverwendbarer UI-Teile. Ein Designsystem ist eine Komponentenbibliothek plus Tokens, plus Dokumentation, plus Governance, plus einen Owner, plus einen Release-Rhythmus. Die meisten Teams liefern eine Komponentenbibliothek aus und nennen sie System. Beides ist nicht dasselbe, und Letzteres hat Wartungskosten, die Ersteres nicht hat.
Ist Shadcn ein Designsystem?
Nein. Shadcn ist ein Auslieferungsmechanismus für Primitives. Komponenten werden in die Codebasis vendored und gehören dem Team. Es gibt keine zentrale Bibliothek, keinen Upstream-Releaseplan und keine Governance.
Genau das ist der Punkt. Es gibt dem Team den Nutzen eines Systems ohne die Wartungsrechnung.
Wann sollte ein Startup in ein Designsystem investieren?
Wenn mindestens drei davon zutreffen: mehrere Produkte mit gemeinsamer Identität, über fünfzig Engineers, die UI ausliefern, eine besetzte Design-Ops-Rolle, externe Nutzer der Komponenten oder eine regulierte Domäne. Unterhalb dieser Schwelle liefere Tokens plus Primitives plus Geschmack aus und steck die gesparten Stunden ins eigentliche Produkt.
CTA
Du willst ein Produkt, bei dem das visuelle System zur Teamgröße passt? Brainy liefert Tokens-plus-Primitives-Stacks für die 95 % und vollständige Designsysteme für die 5 %, abgestimmt auf das tatsächliche Wartungsbudget. Brainy beauftragen. Wir sagen dir, auf welcher Seite der Linie du stehst, bevor du ein Quartal in das falsche Artefakt steckst.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
