Designsysteme: Warum gute Interfaces zuerst aus Regeln, Bausteinen und Sprache bestehen
- Benjamin Metzig
- vor 7 Stunden
- 9 Min. Lesezeit
Wer an digitale Oberflächen denkt, denkt oft zuerst an das Sichtbare: an Buttons, Menüs, Karten, Formulare, Animationen. Das ist verständlich. Interfaces treten uns als Bilder entgegen. Aber genau darin steckt ein Denkfehler, der in vielen Unternehmen, Behörden und Produktteams erstaunlich hartnäckig ist: Sie behandeln Oberflächen als Ansammlung einzelner Screens, nicht als Ergebnis eines Systems.
Deshalb sehen viele Produkte nach ein paar Jahren so aus, wie große Wohnungen aussehen, in denen zu viele Menschen ohne gemeinsamen Grundriss umgebaut haben. Hier ein neuer Buttonstil, dort ein anderes Raster, an einer dritten Stelle plötzlich andere Abstände, andere Begriffe, andere Fehlermeldungen, andere Prioritäten. Die Oberfläche funktioniert dann vielleicht noch irgendwie. Aber sie erklärt sich nicht mehr. Sie wirkt nicht wie ein zusammenhängendes Werkzeug, sondern wie ein Ort mit widersprüchlichen Regeln.
Genau an dieser Stelle kommen Designsysteme ins Spiel. Und zwar nicht als modisches Extra für große Tech-Firmen, sondern als sehr nüchterne Antwort auf ein reales Problem: Wie sorgt man dafür, dass digitale Produkte nicht nur hübsch, sondern konsistent, verständlich, zugänglich und skalierbar werden?
Die kurze Antwort lautet: nicht, indem man zuerst schöne Screens malt. Sondern indem man zuerst Regeln, Bausteine und Sprache ordnet.
Ein Designsystem ist keine UI-Kiste
Der Begriff Designsystem wird oft so benutzt, als sei er nur die edlere Version von „Komponentenbibliothek“. Das greift viel zu kurz.
Ein gutes Designsystem besteht aus mehreren Ebenen. Atlassian trennt in seinem eigenen System ausdrücklich zwischen Foundations, Components und Patterns: Foundations sind Grundregeln wie Farbe, Typografie, Abstände und Tokens; Components sind wiederverwendbare Bausteine; Patterns verbinden diese Bausteine zu konsistenten Lösungen für konkrete Nutzungssituationen (Atlassian Design System). Genau diese Trennung ist entscheidend, weil sie zeigt, dass ein Designsystem nicht bei fertigen UI-Elementen beginnt.
Es beginnt bei Entscheidungen, die vor jedem einzelnen Screen liegen.
Welche Schriftgrößen gelten als primär, sekundär, unterstützend? Wie eng oder locker darf eine Oberfläche werden? Welche Farben sind rein dekorativ, welche tragen Bedeutung? Wann ist ein Banner eine Warnung, wann nur ein Hinweis? Wie klingt ein Bestätigungstext? Was steht auf einem Button, wenn eine Aktion nicht einfach „abschicken“, sondern tatsächlich „Konto erstellen“ bedeutet?
Solche Fragen klingen kleiner, als sie sind. In Wahrheit definieren sie, wie viel kognitive Arbeit ein Interface seinen Nutzern abnimmt oder aufbürdet.
Kernidee: Gute Interfaces entstehen selten zuerst aus Formen.
Sie entstehen aus gut geregelten Entscheidungen darüber, wie Form, Verhalten und Sprache zusammenspielen.
Regeln sind kein Bürokratismus, sondern eingefrorene Erfahrung
Viele Menschen hören das Wort Regeln und denken sofort an Einschränkung. Im Designkontext ist das ein Missverständnis. Regeln sind hier keine Feinde der Kreativität, sondern Speicher für bereits gelöste Probleme.
Wenn ein Team einmal sauber herausgefunden hat, welche Abstände auf mobilen Oberflächen gut lesbar bleiben, welche Kontrastwerte robust sind, welche Formularfehlermeldungen Menschen wirklich weiterhelfen oder welche Hierarchien auf kleinen Screens schnell erfassbar sind, dann wäre es irrational, dieses Wissen bei jeder neuen Seite neu zu verhandeln.
Genau hier setzen Design Tokens an. Die W3C-nahe Spezifikation des Design Tokens Community Group beschreibt Tokens als Methode, Designentscheidungen plattformagnostisch auszudrücken, damit sie über Disziplinen, Tools und Technologien hinweg geteilt werden können (Design Tokens Format Module). Microsoft formuliert denselben Gedanken im Fluent-System sehr praktisch: Tokens sind gespeicherte Werte für Farbe, Typografie, Abstände oder Elevation und schaffen eine gemeinsame Sprache über Plattformen und Rollen hinweg (Fluent 2 – Design tokens).
Das klingt technisch, hat aber einen sehr menschlichen Kern. Ein Token ist im Grunde die Aussage: „Wir möchten nicht jedes Mal wieder darüber streiten, wie unser Primärtext aussieht. Wir möchten diese Entscheidung benennen, verständlich machen und verlässlich wiederverwenden.“
Damit verändert sich auch die Art, wie Teams arbeiten. Statt auf zehn Screens jeweils leicht verschiedene Grautöne, Radiuswerte oder Einrückungen einzeln zu pflegen, werden diese Entscheidungen in ein System überführt. Aus Geschmack wird Infrastruktur.
Komponenten sparen nicht nur Zeit, sondern Streit
Der sichtbarste Teil eines Designsystems sind seine Komponenten. Buttons, Dialoge, Tabs, Formulare, Navigationsleisten, Banner, Akkordeons. Sie sind wichtig, aber nicht deshalb, weil man mit ihnen schneller klickbare Prototypen zusammenstellt. Ihr tieferer Wert liegt darin, dass sie Diskussionen mit niedriger Erkenntnisrendite verkürzen.
Denn jedes Team kennt diese Meetings: Soll der Primärbutton rund oder rechteckig sein? Muss die Fehlermeldung direkt unter dem Feld stehen oder oben im Formular? Wie verhalten sich Tabs mobil? Braucht der Bestätigungsdialog einen zweiten Fluchtweg? Welche Abstände gelten zwischen Überschrift und Hilfetext?
Wenn diese Fragen jedes Mal neu gestellt werden, ist das kein Zeichen von Sorgfalt, sondern oft von fehlender Systembildung. Ein gutes Designsystem erledigt solche Grundsatzentscheidungen vorab und macht sie transparent. Das entlastet Teams, damit sie sich auf die Fragen konzentrieren können, die wirklich neu sind: Was braucht der Nutzer hier? Welche Information fehlt? Welche Handlung ist riskant? Wo braucht es mehr Kontext?
Komponenten sind deshalb nicht einfach Wiederverwendungsobjekte. Sie sind geronnene Einigung.
Aber Bausteine allein lösen noch keine Aufgaben
Wer nur einen Katalog von Komponenten pflegt, hat noch kein starkes Designsystem. Denn Menschen benutzen keine Buttons und Inputfelder als Selbstzweck. Sie erledigen Aufgaben: ein Konto anlegen, eine Buchung prüfen, einen Antrag abschicken, einen Fehler korrigieren, einen Status verstehen.
Das GOV.UK Design System beschreibt Patterns deshalb als Best-Practice-Lösungen für konkrete, nutzerzentrierte Aufgaben und Seitentypen. Diese Patterns nutzen Komponenten, erklären aber zusätzlich, wie sie im jeweiligen Kontext kombiniert und angepasst werden sollen (GOV.UK Patterns).
Das ist ein fundamentaler Unterschied. Ein Textfeld ist ein Bauteil. Ein gut gestalteter Ablauf zur Eingabe persönlicher Daten ist ein Muster. Ein Fehlerbanner ist ein Bauteil. Eine robuste Strategie, wie Menschen nach einer Validierungspanne wieder in den Prozess finden, ist ein Muster.
Viele Produkte scheitern nicht an schlechten Einzelteilen, sondern an schlechter Choreografie. Alles ist technisch vorhanden, aber die Reihenfolge, Gewichtung und Verständlichkeit der Interaktionen stimmen nicht. Genau deshalb sind Patterns so wertvoll: Sie übersetzen Bauteile in wiederkehrende Problemlösungen.
Sprache ist kein Etikett auf dem Interface, sondern sein Material
Vielleicht der meistunterschätzte Teil eines Designsystems ist Sprache. In vielen Teams wird sie noch immer behandelt, als käme sie ganz am Ende: wenn die Screens fertig sind, die Abstände sitzen und „nur noch die Texte reinmüssen“.
Das ist ungefähr so, als würde man in der Architektur sagen, die Statik sei der spannende Teil und die Türen könnten später irgendwer beschriften.
In Wirklichkeit besteht ein großer Teil digitaler Nutzbarkeit aus Wörtern. Microsofts Fluent-System sagt das ziemlich direkt: Content Design ist die Frage, wie Menschen genau dann die Information bekommen, die sie brauchen, wenn sie sie brauchen. Es fordert einfache Sprache, klare Überschriften, beschreibende Linktexte und eine direkte, menschliche Ansprache (Fluent 2 – Content design). Auch Atlassian behandelt Content nicht als Nebenfach, sondern als Teil der Foundations des Systems (Atlassian – Content foundations).
Das hat Folgen.
Ein Button mit der Aufschrift „Weiter“ ist oft schwächer als „Konto erstellen“, „Adresse prüfen“ oder „Zahlung bestätigen“. Eine Fehlermeldung wie „Eingabe ungültig“ ist schlechter als „Bitte geben Sie eine E-Mail-Adresse im Format name@beispiel.de ein“. Ein Link mit „Mehr erfahren“ hilft Suchmaschinen wenig und Menschen mit Screenreader oft ebenso wenig, wenn aus dem Kontext nicht klar wird, wohin er führt.
Sprache ist also nicht Dekoration, sondern Interface-Verhalten in Textform.
Definition: Content Design
Content Design meint nicht bloß schönes Schreiben. Gemeint ist die systematische Gestaltung von Benennungen, Hinweisen, Fehlermeldungen, Linktexten, Tonfall und Verständlichkeit innerhalb eines Produkts.
Gerade für SEO ist das entscheidend. Denn Suchmaschinen bevorzugen längst nicht nur Keywords, sondern Strukturen, die menschliche Suchintentionen sauber beantworten. Wer Designsysteme erklärt, indem er bloß zwanzigmal „Designsystem“ in einen Text streut, schreibt keinen guten Beitrag. Wer aber präzise erklärt, was Tokens, Komponenten, Patterns, Accessibility und Content Design leisten, beantwortet reale Suchfragen. Und genau das ist langfristig sichtbarer.
Barrierefreiheit ist systemisch, aber nie automatisch
Ein gutes Designsystem kann die Baseline eines Produkts massiv verbessern. Es kann Kontraste standardisieren, Fokuszustände sauber definieren, semantische Komponenten vorbereiten, Alt-Text-Regeln festhalten, Zoom-Verhalten berücksichtigen und responsives Reflowing absichern.
Fluent macht genau diese Punkte explizit: Fokusführung, Kontrast, sinnvolle Textgestaltung, semantischer Code, Alt-Texte und Layouts, die sich bis zu kleinen Breakpoints ohne horizontales Scrollen neu ordnen, gehören dort zur Accessibility-Praxis (Fluent 2 – Accessibility).
Das ist die gute Nachricht.
Die nüchterne Nachricht liefert GOV.UK: Die Verwendung eines Designsystems macht einen Service nicht automatisch barrierefrei. Zusätzliche Forschung, Entwicklung und Tests bleiben nötig, selbst wenn bereits zugängliche Komponenten und Muster genutzt werden (GOV.UK Accessibility).
Dieser Satz ist wichtig, weil er zwei Extreme korrigiert.
Das erste Extrem lautet: „Wir haben ein Designsystem, also ist Accessibility erledigt.“ Das ist falsch. Denn kein System kann im Voraus alle Inhalte, Kontexte, Ausnahmefälle, Redaktionsfehler, Interaktionspfade und technischen Einbettungen absichern.
Das zweite Extrem lautet: „Systeme bringen eh nichts, man muss sowieso alles individuell testen.“ Auch das ist falsch. Denn ohne System beginnt jedes Team wieder bei Null, und genau dann reproduzieren sich dieselben Barrieren dutzendfach.
Die Wahrheit ist unglamouröser und nützlicher: Ein Designsystem macht Barrierefreiheit wahrscheinlicher, billiger und konsistenter. Aber es entbindet niemanden von Verantwortung im konkreten Produkt.
Designsysteme sind auch Machtfragen
Spätestens hier wird klar, warum Designsysteme weit mehr sind als Designhandwerk. Sie ordnen nicht nur Flächen, sondern Zuständigkeiten. Wer entscheidet, welche Komponente offiziell ist? Wer darf Ausnahmen definieren? Wer priorisiert Accessibility-Schulden gegen Lieferdruck? Wer sorgt dafür, dass ein gutes Pattern aus einem Team später allen hilft? Wer verhindert, dass aus jeder Produktgruppe ein gestalterisches Fürstentum wird?
Atlassian formuliert das bemerkenswert offen: Ein Designsystem braucht nicht nur Bausteine, sondern auch Dokumentation, Support, Wartung und Prozesse, die Teams in die gemeinsame Arbeit einbinden (About the Atlassian Design System). Mit anderen Worten: Ein System lebt nicht nur von Assets, sondern von Governance.
Das ist meist der Moment, an dem viele Designsystem-Initiativen kippen. Der Figma-Bestand steht, die ersten Komponenten sind gebaut, die Launch-Folie ist hübsch, aber danach beginnt die eigentliche Arbeit erst:
Wer pflegt die Standards?
Wie werden neue Bedürfnisse aufgenommen?
Welche Komponente wird erweitert, welche bewusst nicht?
Was gilt als Systemproblem und was als lokaler Sonderfall?
Wie verhindert man, dass Teams am System vorbei bauen, weil es langsamer wirkt als Copy-paste?
Ein Designsystem ist also auch eine soziale Architektur. Es funktioniert nur, wenn es Vertrauen stiftet: zwischen Design, Entwicklung, Redaktion, Produktmanagement und oft auch Recht, Compliance oder Barrierefreiheitsverantwortlichen.
Die große Verwechslung: Konsistenz ist nicht Gleichförmigkeit
Eine häufige Sorge lautet, Designsysteme würden alles gleich machen. Tatsächlich ist das Gegenteil das Ziel. Gute Systeme standardisieren das, was standardisiert werden sollte, damit dort, wo Kontext zählt, mehr geistige Energie frei wird.
Niemand beschwert sich ernsthaft darüber, dass in einer Stadt Verkehrsregeln standardisiert sind. Gerade weil Ampeln, Fahrtrichtungen und Vorfahrtslogiken geregelt sind, können sich Menschen sicher und flexibel durch sehr unterschiedliche Räume bewegen. Designsysteme leisten in digitalen Produkten etwas Ähnliches.
Sie sorgen dafür, dass nicht jede Interaktion neu entziffert werden muss. Dadurch bleibt mehr Aufmerksamkeit für Inhalt, Entscheidung und Aufgabe.
Konsistenz bedeutet also nicht, dass jede Oberfläche gleich aussieht. Sie bedeutet, dass Gleiches ähnlich funktioniert und Wichtiges zuverlässig lesbar bleibt.
Das ist ein Unterschied mit enormer Wirkung. Wer schon einmal zwischen drei Behördenportalen, vier Unternehmens-Dashboards oder fünf Shop-Checkouts gewechselt ist, weiß intuitiv, wie anstrengend inkonsistente Interfaces sind. Die Reibung entsteht selten aus spektakulär schlechten Einzelentscheidungen. Sie entsteht aus tausend kleinen Abweichungen, die zusammen mentale Kosten erzeugen.
Warum gerade jetzt so viele Teams über Designsysteme neu nachdenken
Es gibt dafür mehrere Gründe.
Erstens wachsen digitale Produkte heute schneller und über mehr Kanäle als früher. Eine Oberfläche lebt nicht mehr nur auf einem Desktop-Screen, sondern auf Mobilgeräten, Tablets, in eingebetteten Widgets, manchmal sogar in Sprach-, KI- oder Assistenzkontexten. Ohne systemische Regeln explodiert die Zahl der Sonderfälle.
Zweitens sind die Anforderungen an Barrierefreiheit, Lokalisierung und Wartbarkeit gestiegen. Ein isoliert schönes Mockup ist heute viel weniger wert als ein robustes, semantisch und sprachlich tragfähiges System.
Drittens verschiebt sich der Wettbewerb. Viele digitale Produkte konkurrieren nicht mehr primär über exotische visuelle Effekte, sondern über Klarheit, Verlässlichkeit und Reibungsarmut. Das Interface muss nicht ständig überraschen. Es muss oft einfach nur deutlich besser funktionieren.
Und viertens haben Unternehmen verstanden, dass technische Schulden nicht nur im Backend entstehen. Eine ungepflegte Oberfläche erzeugt ebenfalls Schulden: in Supporttickets, in Onboarding-Zeit, in Fehleingaben, in inkonsistenter Markenwahrnehmung, in unnötigen Diskussionen zwischen Teams.
Woran man ein gutes Designsystem erkennt
Ein gutes Designsystem erkennt man nicht daran, dass es beeindruckende Showcase-Seiten hat. Sondern daran, dass es im Alltag etwas vereinfacht, ohne die Komplexität zu verleugnen.
Es beantwortet Fragen wie:
Sind Gestaltungsentscheidungen benannt und maschinenlesbar?
Gibt es mehr als Komponenten, also auch Patterns, Content-Regeln und Accessibility-Vorgaben?
Löst das System echte Nutzerprobleme oder vor allem interne Design-Eitelkeiten?
Können Teams verstehen, wann sie Standardbausteine nutzen und wann sie begründet abweichen dürfen?
Ist Sprache Teil des Systems?
Werden neue Erkenntnisse aus Forschung, Support und Nutzung in das System zurückgeführt?
Wenn diese Fragen mit Ja beantwortet werden, dann ist ein Designsystem kein Schaufenster mehr, sondern Infrastruktur.
Der eigentliche Punkt
Die wichtigste Einsicht über Designsysteme ist vielleicht diese: Sie sind nicht dazu da, Oberflächen hübscher zu machen. Sie sind dazu da, digitale Produkte verständlicher zu machen, während sie wachsen.
Sie schaffen ein Vokabular für Entscheidungen. Sie machen aus einzelnen Designakten eine lernfähige Praxis. Sie verbinden Gestaltung mit Sprache, Technik mit Semantik, Effizienz mit Verantwortung.
Deshalb entstehen gute Interfaces eben oft zuerst aus Regeln, Bausteinen und Sprache. Nicht weil das romantischer wäre. Sondern weil Menschen sich in digitalen Räumen nur dann gut bewegen können, wenn diese Räume eine innere Ordnung besitzen.
Wer das für langweilige Hintergrundarbeit hält, verwechselt das Spektakuläre mit dem Wichtigen.
Wer tiefer in die politische und technische Seite solcher Standards einsteigen will, findet bei Wissenschaftswelle bereits passende Anschlussstücke: etwa zu Open Standards gegen Lock-in, zum Design von Warnsystemen oder zum Unboxing-Design. Gerade an solchen Themen sieht man: Gestaltung ist nie nur Oberfläche. Sie ist immer auch Entscheidung darüber, wie Menschen Informationen wahrnehmen, deuten und nutzen können.
