Konsistenz in Design und Software war immer ein Kompromiss. Kein Prinzip, keine Tugend – sondern die günstigste Lösung für ein Koordinationsproblem.
Das klingt provokant. Aber denk mal kurz nach, warum Design Systems überhaupt existieren.
#Das eigentliche Problem hinter jedem Style Guide
Wenn zehn Entwickler an einer Codebasis arbeiten, brauchen sie Regeln. Nicht weil einheitliche Button-Farben objektiv besser sind, sondern weil zehn Menschen ohne Regeln zehn verschiedene Entscheidungen treffen. Design Tokens, Component Libraries, Spacing-Systeme – all das ist Koordinations-Infrastruktur. Es löst das Problem, dass Abstimmung teuer ist.
Nicht mehr, nicht weniger.
Das heißt nicht, dass Konsistenz wertlos ist. Sie hat echte Vorteile: Nutzer erkennen Muster, Entwickler arbeiten schneller, Fehler entstehen seltener. Aber diese Vorteile waren immer sekundär. Der primäre Grund für Standards war Skalierung unter menschlichen Bedingungen.
Und genau diese Bedingungen ändern sich gerade.
#Was Christopher Butler konkret beschreibt
Butler schildert in seinem Essay, wie er mit einer Person und KI eine Software-Architektur maintained und erweitert, die Jahre gebraucht hat, um zu entstehen. Figma für das Design, Anima für die Übersetzung in HTML und CSS, Claude für Kompilierung, Refactoring und Implementierung.
Bestehende Templates, Stylesheets, Konfigurationsdateien – alles fließt in ein System, das in Stunden verarbeitet, wofür früher ein Team Wochen gebraucht hätte.
Das ist nicht Effizienzoptimierung. Das ist ein anderes Paradigma.
Wenn eine Person das leisten kann, was früher zehn erfordert haben, fällt die Grundannahme weg, auf der Konsistenz als Zwang basiert. Du brauchst keinen globalen Standard mehr, weil du nicht mehr global koordinieren musst.
#Der Shift, den ich selbst spüre
Früher war meine Standardfrage bei jeder Komponente: Passt das ins System? Gibt es schon etwas Ähnliches? Wie verhalte ich mich konform zu dem, was bereits existiert?
Heute frage ich: Ist das für diesen Kontext die beste Entscheidung?
Das klingt klein. Ist es aber nicht. Der erste Ansatz optimiert für Konsistenz. Der zweite optimiert für Qualität. Beides ist nicht dasselbe – und solange Koordination teuer war, musste man Konsistenz als Proxy für Qualität akzeptieren.
Jetzt muss man das nicht mehr.
Ich merke das konkret darin, wie ich Projekte angehe. Ich schneide Komponenten häufiger auf den spezifischen Anwendungsfall zu, statt sie in ein bestehendes System einzupassen. Das kostet mich weniger Zeit als früher, weil KI den Overhead übernimmt, der früher manuell war.
#Das Gegenargument, das ich ernst nehme
Hier kommt der einwand, den ich öfter höre: Aber Nutzer erwarten Konsistenz. Sie wollen, dass ein Button immer gleich aussieht. Vertraute Muster reduzieren kognitive Last.
Das stimmt. Aber dieser Einwand verwechselt zwei Ebenen.
Konsistenz innerhalb eines Produkts, für einen Nutzer, in einem Kontext – das bleibt wertvoll. Was wegfällt, ist die Notwendigkeit, dass alle Produkte nach denselben Regeln gebaut werden müssen, weil alle Teams dieselbe Infrastruktur teilen.
Ein maßgeschneidertes Interface kann für seinen Kontext vollkommen konsistent sein, ohne sich an ein übergreifendes Design System zu halten. Beides schließt sich nicht aus.
#Was das für Software insgesamt bedeutet
Butler zieht eine größere Linie: Software begann als Programm auf einer Disc. Dann wurde es als Service geliefert. Dann zentralisiert in der Cloud. Der nächste Schritt ist Software, die für jeden Nutzer individuell generiert wird.
Wenn KI Software-Architektur instantan maintainen und erweitern kann, ist der logische Endpunkt bespoke Software. Nicht ein Produkt für eine Million Nutzer, sondern eine Million leicht verschiedene Versionen für eine Million Kontexte.
Konsistenz als globaler Standard wird dann nicht nur unnötig – sie wird aktiv hinderlich. Wer starr an einem System festhält, das für Koordination gebaut wurde, verliert den Vorteil, den KI bietet.
#Drei konkrete Dinge, die du jetzt anders denken kannst
Frag nicht zuerst nach dem System. Wenn du eine neue Komponente baust, frag zuerst: Was ist hier die beste Lösung? Dann: Passt sie ins System? Die Reihenfolge macht den Unterschied.
Nutze KI für den Konsistenz-Overhead. Wenn du individuell gestaltest, entsteht Arbeit beim Abstimmen, Dokumentieren, Übertragen. Das ist genau die Arbeit, die Claude, Copilot oder ähnliche Tools übernehmen können. Du gestaltest, KI koordiniert.
Unterscheide zwischen Konsistenz als Mittel und als Ziel. Konsistenz, die dem Nutzer hilft, ist sinnvoll. Konsistenz, die existiert, weil das Team sie braucht, ist ein Kompromiss. Erkenne den Unterschied – und optimiere nur noch für ersteres.
Der Shift von Koordinations-Konsistenz zu kontextspezifischer Qualität ist keine Bedrohung für gutes Design. Er ist die Befreiung davon, Qualität immer dem Koordinationsaufwand unterzuordnen.
Wer das versteht, arbeitet schon anders. Alle anderen werden es noch merken.
Ausgeloest durch: Consistency is Primitive – Christopher Butler