Weißt du, was das größte Missverständnis in unserer Branche ist? Dass wir glauben, wir würden Bildschirme gestalten. Das tun wir nicht. Wir gestalten Beziehungen. Wir definieren Logiken. Wir bauen Infrastruktur. Wenn du als UX-Experte heute noch glaubst, dein Job sei getan, wenn das Figma File pixelperfekt ist, dann muss ich dich enttäuschen. Das ist erst der Anfang. Das eigentliche Design passiert dort, wo es wehtut. Im Code. In der Architektur. In der Art und Weise, wie eine Variable namens primary-action-background-hover durch deine Applikation fließt.
Lass uns tief eintauchen. Vergiss für einen Moment die hübschen UI-Kits und die Diskussionen über runde Ecken. Lass uns über das Rückgrat erfolgreicher SaaS Produkte sprechen. Lass uns über semantische Architektur, Governance Modelle und die brutale Realität von Skalierung sprechen. Denn genau hier entscheidet sich, ob dein Produkt ein fragiles Kartenhaus bleibt oder zu einer robusten Plattform wird, die den Markt dominiert.
Das Problem mit der Komponentenfalle
Wir haben uns alle in Komponenten verliebt. Brad Frost hat uns mit Atomic Design eine Sprache gegeben, die wir dringend brauchten. Wir bauen Atome, Moleküle und Organismen. Wir fühlen uns gut dabei. Aber in vielen SaaS Teams beobachte ich ein gefährliches Phänomen. Sie bauen Komponenten Bibliotheken, keine Design Systeme. Der Unterschied ist gigantisch. Eine Bibliothek ist ein Eimer voller Legosteine. Ein System ist die Anleitung, wie diese Steine zusammenhalten, wie sie interagieren und vor allem, wie sie sich verändern lassen, ohne dass das ganze Schloss einstürzt.
Wenn du eine Komponente baust, sagen wir ein Dropdown Menü, und du definierst die Farben darin als feste Hex Werte oder einfache Referenzen wie blue-500, dann hast du gerade technische Schulden produziert. Du hast Designentscheidungen hart codiert. Wenn das Rebranding kommt oder du einen Dark Mode einführen willst, musst du jede einzelne Komponente anfassen. Das ist schlecht.
Die Lösung liegt eine Ebene tiefer. Wir müssen aufhören, in Farben und Abständen zu denken, und anfangen, in deren Bedeutung zu denken. Wir brauchen Design Tokens.
Semantik ist der Schlüssel zur Agilität
Ein Design Token ist mehr als eine Variable. Es ist eine Entscheidung, verpackt in einen Namen. Es ist der Vertrag zwischen Design und Entwicklung. Statt FF0000 sagen wir error-color. Aber selbst das ist oft noch zu flach. Ein wirklich robustes System nutzt mehrere Ebenen der Abstraktion.
Da haben wir zunächst die primitiven Tokens. Das sind deine Rohstoffe. blue-60 ist einfach nur eine Farbe aus deiner Palette. Diese Ebene sollte im Code der Komponenten aber niemals auftauchen. Niemals. Darauf aufbauend definieren wir semantische Tokens. Hier weisen wir dem Rohstoff eine Funktion zu. color-action-primary verweist auf blue-60. Das ist schon besser. Wenn wir die Markenfarbe ändern, ändern wir nur die Zuweisung an dieser Stelle.
Aber für komplexe SaaS Anwendungen reicht auch das oft nicht. Wir brauchen komponentenspezifische Tokens. button-primary-background verweist auf color-action-primary. Warum dieser Wahnsinn? Warum drei Ebenen der Indirektion? Weil es dir maximale Flexibilität gibt. Wenn du entscheidest, dass der Primär Button auf dunklen Hintergründen anders aussehen muss als der Link Text, obwohl beide bisher dieselbe Farbe nutzen, kannst du das tun. Ohne Regression Testing der gesamten App. Ohne Angstschweiß.
Das ist Architektur. Das ist UX-Arbeit. Du gestaltest nicht den Button. Du gestaltest die Logik des Buttons. Salesforce macht das mit ihrem Lightning Design System meisterhaft vor. Sie haben tausende von Tokens, die genau steuern, wie sich die Dichte der Informationen ändert, wenn ein Nutzer vom Desktop auf Mobile wechselt. Das passiert nicht zufällig. Das ist harte, trockene Systemarbeit, die am Ende magisch wirkt.
Die Schnittstelle zwischen Designer und Entwickler neu denken
Viele UX-Teams werfen ihre Designs über den Zaun und hoffen, dass die Entwickler sie fangen. Das funktioniert nicht. Du musst verstehen, wie deine Entwickler arbeiten. Du musst ihre Sprache sprechen. Und nein, du musst nicht React lernen, aber du musst verstehen, was Props sind.
Eine Komponente in Figma sollte dieselbe API haben wie die Komponente im Code. Wenn dein Button in Figma eine Property „Type“ mit den Werten „Primary“ und „Secondary“ hat, im Code aber zwei verschiedene Komponenten namens <PrimaryButton> und <SecondaryButton> existieren, dann habt ihr ein Problem. Ihr sprecht verschiedene Dialekte. Das führt zu Missverständnissen, Bugs und Frust.
Wir müssen unsere Denkweise ändern. Wir müssen unsere Komponenten so gestalten, dass sie restriktiv genug sind, um Konsistenz zu garantieren, aber flexibel genug, um edge cases abzudecken. Das ist der Slot Ansatz. Erlaube Entwicklern, Inhalte in definierte Bereiche deiner Komponente zu injizieren, ohne die Struktur der Komponente zu brechen. Gib ihnen Werkzeuge an die Hand, nicht Fesseln.
Bei Shopify und ihrem Polaris System sehen wir das exzellent umgesetzt. Die Dokumentation dort spricht Designer und Entwickler gleichermaßen an. Die Namenskonventionen sind identisch. Die mentalen Modelle sind synchronisiert. Das Ergebnis ist eine Geschwindigkeit in der Entwicklung, von der andere nur träumen können. Wenn Design und Code dieselbe Sprache sprechen, verschwindet die Übersetzungsarbeit. Und Übersetzungsarbeit ist Verschwendung.
Governance oder: Wie wir Wildwuchs verhindern
Vielleicht kennst du das. Dein System steht. Es ist sauber. Und dann kommt ein neues Feature Team und sagt, sie brauchen einen ganz speziellen Datepicker. Einen, den es so im System nicht gibt. Was tust du?
Es gibt zwei schlechte Antworten. Die erste ist der Diktator Ansatz: Nein, nimm, was da ist. Das führt dazu, dass das Team das System umgeht und eigenen Code schreibt. Wir nennen das „Detaching“ in Figma und „Hacking“ im Code. Die zweite schlechte Antwort ist der Anarchie Ansatz: Klar, bau was du willst, wir packen es ins System. Das führt dazu, dass dein System in sechs Monaten platzt, weil es fünf verschiedene Datepicker enthält.
Die richtige Antwort ist ein Föderationsmodell. Erlaube dem Team, ihren speziellen Datepicker zu bauen. Aber – und das ist das große Aber – er muss den Regeln des Systems folgen. Er muss die Tokens nutzen. Er muss die Accessibility Guidelines erfüllen. Aber er kommt erst einmal nicht in den Core. Er bleibt ein „Snowflake“. Eine Einzellösung.
Erst wenn ein zweites oder drittes Team denselben Bedarf anmeldet, starten wir den Prozess der Promotion. Wir schauen uns die Lösung an. Wir abstrahieren sie. Wir machen sie generisch. Und dann nehmen wir sie in den Core auf. Das ist organische Governance. Das System wächst mit den Anforderungen, aber kontrolliert.
Atlassian hat dieses Modell perfektioniert. Bei der schieren Größe ihrer Produktpalette – Jira, Confluence, Trello – wäre ein zentralistischer Ansatz der Tod der Innovation. Sie erlauben lokale Experimente, aber sie bestehen auf globalen Standards bei den Grundlagen wie Farbe, Typografie und Spacing.
Accessibility ist keine Checkliste am Ende
Lass uns über Barrierefreiheit sprechen. Nicht als ethische Verpflichtung, obwohl sie das ist, sondern als Qualitätsmerkmal von Softwarearchitektur. In vielen Prozessen ist a11y (Accessibility) der letzte Schritt vor dem Launch. Ein Overlay. Ein Nachgedanke. Das ist teuer und ineffizient.
In einem professionellen Design System ist Accessibility eingebaut. In die Tokens. In die Komponenten. Wenn ich einen Token für Textfarbe definiere, dann stelle ich sicher, dass er auf dem definierten Hintergrund Token genug Kontrast hat. Automatisiert. Systemisch.
Ein UX-Experte muss hier tief in die ARIA-Specs eintauchen. Du musst verstehen, wie ein Screenreader durch deine Navigation geht. Du musst Focus States nicht nur designen, sondern ihre Logik definieren. Wann springt der Fokus wohin? Wie verhält sich das Modal beim Schließen?
Wenn du das im System löst, löst du es für jedes Produkt, das dieses System nutzt. Das ist der Hebel, den wir suchen. Einmal richtig gelöst, tausendfach richtig angewendet. Das senkt das rechtliche Risiko für dein SaaS Unternehmen massiv und öffnet deinen Markt für Nutzer, die auf assistive Technologien angewiesen sind.
Der ROI von Langeweile
Ich weiß, das klingt alles nicht sehr sexy. Tokens. Governance. ARIA-Labels. Wo bleibt die Kreativität? Wo bleibt der „Wow Faktor“?
Ich sage dir etwas. Der größte Wow Faktor für einen SaaS Kunden ist eine Software, die einfach funktioniert. Die vorhersehbar ist. Die ihn nicht zum Nachdenken zwingt. Konsistenz ist langweilig für den Designer, aber beruhigend für den Nutzer.
Und für das Business ist diese „Langeweile“ pures Gold. Wir sprechen hier von Effizienzgewinnen, die messbar sind. Wenn dein Team nicht mehr diskutieren muss, wie groß der Abstand zwischen Headline und Subline ist, weil das der Token space-m regelt, dann haben sie Zeit, komplexe User Flows zu durchdenken. Zeit, Innovation zu treiben.
Studien zeigen, dass Entwickler bis zu einem Drittel ihrer Zeit mit trivialen UI-Entscheidungen verschwenden, wenn kein System existiert. Rechne das mal auf das Gehalt eines Senior Entwicklers hoch. Ein Design System ist keine Kostenstelle. Es ist ein Investitionsschutz für deine teuerste Ressource: Deine Mitarbeiter.
Fazit: Werde zum Architekten
Die Rolle des UX-Designers im SaaS Umfeld wandelt sich. Wir sind nicht mehr die, die Dinge hübsch machen. Wir sind Systemarchitekten. Wir bauen die Infrastruktur, auf der das Business skaliert.
Wenn du diesen Shift machst, wenn du anfängst, in Tokens und APIs zu denken statt in Screens und Pages, dann wirst du sehen, wie sich deine Arbeit verändert. Du wirst mehr Einfluss haben. Du wirst ernster genommen werden von den Engineering-Leads. Weil du ihre Probleme löst, statt neue zu schaffen.
Ein Design System ist nie fertig. Es ist ein lebender Organismus. Es entwickelt sich, wächst, macht manchmal Fehler und lernt daraus. Du wirst scheitern, du wirst refaktorieren, du wirst zurück auf Los gehen. Genau das ist der Prozess, der dich als UX-Profi wachsen lässt.
Jeder neue Token, jede Regel, jede Entscheidung ist Teil davon. Am Ende bist du nicht die Person, die Buttons malt, sondern jemand, der Produktarchitektur so baut, dass andere darin arbeiten können. Das ist Handwerk, Haltung und Verantwortung. Und, wenn wir ehrlich sind, daran misst sich, ob ein SaaS wirklich skalieren kann.
Vielleicht klingt das nach viel. Vielleicht nach Arbeit, die niemand sieht. Aber die beste Architektur ist die, die niemand bemerkt, weil einfach alles funktioniert.
Also: Bau Systeme, keine Kunstwerke. Mach Fehler, lerne daraus, pflege dein Ökosystem bewusst. Das ist der Unterschied zwischen Feature Feuerwerk und nachhaltigem Produkt. Und irgendwann, wenn du zurückblickst, wirst du merken – während alle anderen noch Farben tauschen, hast du längst das nächste Kapitel aufgeschlagen.