Wie viel UI-Autonomie verträgt ein Produkt?

Microfrontends versprechen technische Autonomie. Teams können unterschiedliche Frameworks einsetzen, ihre Anwendungen unabhängig entwickeln und ihren technischen Stack an die Anforderungen ihres fachlichen Bereichs anpassen.

Diese Freiheit endet jedoch nicht erst an fachlichen Abhängigkeiten oder globalen Plattformfunktionen. Sie endet auch an der Oberfläche.

Für Nutzerinnen und Nutzer besteht ein Produkt nicht aus Hosts, Remotes, Frameworks und Deployment-Einheiten. Sie sehen Formulare, Schaltflächen, Tabellen, Dialoge und Navigation. Wenn ein Bereich anders aussieht oder sich anders verhält als der nächste, erkennen sie keine gelungene technische Entkopplung. Sie erleben ein uneinheitliches Produkt.

Damit stellt sich eine Frage, die technisch kleiner wirkt, als sie organisatorisch ist:

Wie viel gestalterische und technische UI-Autonomie dürfen einzelne Remotes besitzen, ohne dass das gemeinsame Produkt auseinanderfällt?

Die Antwort muss nicht darin bestehen, jedes Remote auf dasselbe Framework und dieselbe Komponentenbibliothek zu verpflichten. Das würde einen wesentlichen Teil der technischen Autonomie wieder aufheben. Ein Angular-Remote darf Angular Material verwenden, während ein React-Remote Material UI oder eine andere geeignete Bibliothek integriert. Ein weiteres Remote kann mit Utility-Klassen arbeiten.

Diese technischen Unterschiede müssen für das Produkt nicht problematisch sein. Problematisch werden sie, sobald sie für Nutzer sichtbar oder spürbar werden.

Das Remote besitzt die technische Umsetzung. Das Produkt besitzt Identität und Verhalten.

Ein Produkt darf seine Architektur nicht zeigen

Technische Grenzen sind für die Architektur wichtig. Für das Produkterlebnis sollten sie möglichst unsichtbar bleiben.

Nutzer sollten nicht an der Oberfläche erkennen müssen, dass eine Seite von Angular und die nächste von React gerendert wird. Sie sollten auch nicht bemerken, dass zwei Formulare aus unterschiedlichen Komponentenbibliotheken stammen oder dass ein Remote unabhängig vom übrigen Produkt ausgeliefert wurde.

Sichtbare Remote-Grenzen können sich auf unterschiedliche Weise zeigen:

• Farben verändern sich beim Wechsel in einen anderen Produktbereich.
• Überschriften besitzen plötzlich eine andere Typografie.
• Abstände werden enger oder großzügiger.
• Schaltflächen haben andere Radien, Höhen oder Zustände.
• Formulare validieren zu unterschiedlichen Zeitpunkten.
• Fehlermeldungen erscheinen an wechselnden Positionen.
• Speichern funktioniert einmal über einen Button und einmal automatisch.
• Tastatur- und Fokusverhalten unterscheiden sich.

Jede einzelne Abweichung kann klein wirken. In ihrer Summe lassen sie das Produkt jedoch wie eine Sammlung lose verbundener Anwendungen erscheinen.

Technische Autonomie ist deshalb nicht mit gestalterischer Beliebigkeit gleichzusetzen. Ein Remote darf selbst entscheiden, wie es den gemeinsamen Produktvertrag in seinem technischen Stack umsetzt. Es darf aber nicht eigenmächtig entscheiden, wie das Produkt in seinem Bereich grundsätzlich aussieht und funktioniert.

UI-Autonomie endet dort, wo Nutzer die Architektur sehen.

Das Problem ist technisch erstaunlich einfach

Die technische Grundregel für eine konsistente Oberfläche ist überraschend einfach.

Ein Remote verwendet zunächst die Komponentenbibliothek, die für seinen UI-Stack vorgesehen ist. Es nutzt deren öffentliche APIs, integriert das vorgesehene Theming-Konzept und bindet dieses an die gemeinsamen Produkt-Tokens an. Abstände, Farben, Typografie, Radien und Zustände werden nicht für jeden Anwendungsfall neu erfunden.

Wo eine Utility-Schicht vereinbart wurde, nutzt das Remote deren definiertes Gestaltungsvokabular. Wo eigenes CSS notwendig ist, greift es weiterhin auf semantische Produktwerte zurück.

Eine sinnvolle Reihenfolge lautet:

1. Vorhandene Komponente der UI-Bibliothek verwenden.
2. Öffentliche Komponenten-API nutzen.
3. Offizielles Theming-Konzept verwenden.
4. Definierte Design Tokens einsetzen.
5. Vereinbarte Utility-Klassen verwenden.
6. Begrenztes lokales CSS auf Basis semantischer Produkt-Tokens schreiben.
7. Freie Werte oder eigene Komponenten als ausdrücklich begründete Ausnahme behandeln.

Diese Reihenfolge ist kein unveränderliches Gesetz. Sie beschreibt eine sinnvolle Beweislast.

Eine eigene Komponente kann gerechtfertigt sein, wenn eine fachlich besondere Visualisierung benötigt wird, eine echte Lücke in der Bibliothek besteht oder ein Browser-Workaround notwendig ist. Auch eine bewusst entwickelte produktweite Komponente kann eine solche Abweichung rechtfertigen.

Schwächer sind Begründungen wie: „So ging es schneller“, „Mir gefiel der Abstand nicht“ oder „Es sind doch nur wenige Zeilen CSS“.

Unter diesen Bedingungen ist UI-Konsistenz kein besonders kompliziertes Architekturproblem. Die Werkzeuge existieren. Die Integrationspunkte sind bekannt. Die Regeln lassen sich dokumentieren und zu einem gewissen Grad automatisieren.

Schwierig ist nicht das technische Modell, sondern seine konsequente Anwendung.

Warum die Realität trotzdem anders aussieht

In realen Projekten entsteht eine uneinheitliche Oberfläche selten durch eine bewusste Entscheidung gegen das Design-System. Sie entsteht schrittweise.

Ein Team benötigt eine Schaltfläche, deren Abstand nicht ganz passt. Eine lokale Regel korrigiert ihn. Ein anderes Team möchte eine Karte etwas stärker abrunden. In einem dritten Remote wird ein Formularfeld nachgebaut, weil die API der vorhandenen Komponente zunächst komplizierter wirkt als ein paar Zeilen HTML und CSS.

Keine dieser Entscheidungen zerstört das Produkt unmittelbar. Jede einzelne erscheint lokal nachvollziehbar.

Das Problem liegt in ihrer Wiederholung.

Aus einem eigenen Abstand werden mehrere Abstände. Aus einer angepassten Farbe wird eine lokale Farbpalette. Aus einer selbst gebauten Schaltfläche entstehen Varianten für Laden, Fehler, Deaktivierung und Tastaturbedienung. Nach einigen Jahren existiert neben der offiziellen UI-Plattform eine zweite, verteilte UI-Plattform.

Diese zweite Plattform besitzt keinen Namen, keine Roadmap und kein verantwortliches Team. Sie besteht aus lokalen Selektoren, überschriebenen Komponenten, kopierten Styles und impliziten Konventionen. Trotzdem muss sie bei jeder visuellen oder technischen Änderung mitgepflegt werden.

UI-Konsistenz scheitert selten am fehlenden Design-System. Sie scheitert daran, dass seine Regeln als optional behandelt werden.

Ein Design-System ist kein Katalog unverbindlicher Vorschläge. Es ist ein Produktvertrag. Wird dieser Vertrag nur dann eingehalten, wenn er zufällig zur lokalen Umsetzung passt, besitzt das Produkt faktisch keinen gemeinsamen Vertrag mehr.

„If you’re writing CSS, you’re probably doing something wrong“

In einem langjährigen Projekt etablierte sich dafür ein bewusst überspitztes geflügeltes Wort:

If you’re writing CSS, you’re probably doing something wrong.

Der Satz behauptet nicht, dass eigenes CSS grundsätzlich falsch sei. Eine Oberfläche ohne projektspezifisches CSS ist weder immer möglich noch automatisch erstrebenswert.

Sein Zweck ist ein anderer: Er kehrt die Beweislast um.

Der gemeinsame UI- und Theming-Vertrag ist der Normalfall. Die Komponentenbibliothek, ihre öffentlichen APIs, die Design Tokens und die vereinbarten Utility-Klassen bilden den vorgesehenen Weg. Wer diesen Weg verlässt, sollte erklären können, weshalb die vorhandenen Mittel nicht ausreichen.

Ohne diese Umkehrung entsteht schnell die gegenteilige Situation. Dann muss der Produktvertrag bei jeder lokalen Abweichung erneut verteidigt werden:

Warum darf die Schaltfläche nicht etwas höher sein? Warum soll die Karte denselben Radius verwenden? Warum ist 13px problematisch, wenn es auf dem aktuellen Bildschirm gut aussieht?

Die falsche Frage lautet, weshalb sich ein Team an den gemeinsamen Vertrag halten sollte. Die richtige Frage lautet, weshalb die konkrete Abweichung für das Produkt notwendig ist.

Die Ausnahme muss sich gegenüber dem Produktvertrag rechtfertigen – nicht der Produktvertrag gegenüber der Ausnahme.

Diese Haltung ist nicht gegen gestalterische Arbeit gerichtet. Sie schützt sie. Ein Design-System entfaltet seinen Wert erst, wenn neue Anforderungen zunächst innerhalb seiner Sprache gelöst werden. Jede begründete Lücke kann anschließend bewusst in den Produktvertrag aufgenommen werden, statt als lokale Sonderregel verborgen zu bleiben.

Custom CSS kann den Theming-Vertrag umgehen

Custom CSS wird häufig vor allem als Wartungsproblem diskutiert. Lange Stylesheets, spezifische Selektoren und schwer nachvollziehbare Überschreibungen sind tatsächlich problematisch. Für ein Produkt mit mehreren Remotes ist jedoch ein anderer Punkt noch wichtiger:

Custom CSS kann den zentralen Theming-Vertrag umgehen.

Ein lokaler Stil kann heute korrekt aussehen und trotzdem bereits von der zukünftigen Entwicklung des Produkts entkoppelt sein.

.remote-card {
  color: #2457d6;
  font-size: 15px;
  padding: 13px;
  border-radius: 7px;
}

Diese Werte reagieren nicht automatisch auf eine neue Corporate Identity. Sie kennen keinen Dark Mode, keine geänderte Typografieskala und keine kompaktere Dichte. Neue Accessibility-Vorgaben oder eine spätere Migration des Design-Systems erreichen sie ebenfalls nicht ohne Weiteres.

Die Karte funktioniert technisch. Sie nimmt aber nicht mehr vollständig am Produkt-Theme teil.

An das Theme angebundenes Custom CSS verhält sich anders:

.remote-card {
  color: var(--product-color-text);
  background: var(--product-color-surface);
  font: var(--product-typography-body);
  padding: var(--product-space-card-padding);
  border-radius: var(--product-radius-card);
}

Auch diese Regel ist eigenes CSS. Ihre Werte sind jedoch nicht lokal definiert. Die Komponente bleibt an die semantischen Rollen des Produkts gebunden.

Ändert sich die Oberfläche zentral, kann die Karte dieser Änderung folgen. Das Remote besitzt weiterhin seine konkrete Darstellung, ohne einen parallelen Gestaltungspfad zu eröffnen.

Custom CSS ist daher nicht grundsätzlich das Problem. Unthematisiertes Custom CSS ist es.

Die präzisere Regel lautet:

Custom CSS darf den Produktvertrag erweitern, aber nicht umgehen.

Eine fachlich besondere Visualisierung wird möglicherweise eigene Layoutregeln benötigen. Ein komplexer Editor, ein Diagramm oder eine spezialisierte Planungskomponente lässt sich nicht immer aus Standardbausteinen zusammensetzen. Trotzdem können Farben, Typografie, Fokuszustände, Abstände und Kontraste aus dem gemeinsamen Vertrag stammen.

Die fachliche Besonderheit rechtfertigt eine eigene Komponente. Sie rechtfertigt nicht automatisch eine eigene visuelle Sprache.

Die Konventionen des UI-Stacks nutzen

Eine etablierte Komponentenbibliothek liefert nicht nur ein bestimmtes Aussehen. Sie übernimmt einen Teil der langfristigen Wartungsarbeit.

Eine Schaltfläche besteht nicht lediglich aus einem farbigen Rechteck mit Text. Sie benötigt Fokuszustände, Tastaturbedienung, Disabled-Verhalten, Ladezustände und verständliche Kontraste. Ein Formularfeld benötigt Beschriftungen, Fehlermeldungen, Zustandswechsel und eine nachvollziehbare Einbindung in Formulare. Dialoge benötigen Fokusführung, Escape-Verhalten und eine sinnvolle Behandlung des Hintergrunds.

Bibliotheken wie Angular Material, Material UI oder vergleichbare komponentenbasierte Systeme stellen dafür APIs, Konventionen und ein zentrales Theming-Modell bereit. Sie lösen nicht automatisch jedes Accessibility- oder UX-Problem. Sie reduzieren aber die Menge an Infrastruktur, die ein Produkt selbst entwickeln und langfristig pflegen muss.

Wer diese Mechanismen regelmäßig überschreibt, übernimmt ihre Verantwortung schrittweise wieder selbst.

Eine lokal nachgebaute Komponente benötigt zunächst vielleicht nur wenig Code. Später kommen Varianten, Validierung, Responsivität, Tastatursteuerung und Anpassungen an neue Browserversionen hinzu. Jede Abweichung erhöht die Zahl der Fälle, die nicht mehr durch Updates der Bibliothek abgedeckt werden.

Je stärker eine etablierte UI-Bibliothek überschrieben wird, desto mehr ihrer Wartung übernimmt das Produkt selbst.

Der sinnvolle Einsatz einer Komponentenbibliothek bedeutet deshalb nicht, dass jedes Produkt wie die Standarddemo der Bibliothek aussehen muss. Das Theme kann Farben, Typografie, Dichte und weitere Parameter an die Produktidentität anpassen.

Entscheidend ist, dass diese Anpassung innerhalb des vorgesehenen Systems stattfindet. Eine konfigurierte Bibliothek bleibt aktualisierbar. Eine aus vielen lokalen Überschreibungen zusammengesetzte Bibliothek wird dagegen zunehmend zu einem eigenen Fork, auch wenn ihr Quellcode nie tatsächlich kopiert wurde.

Utility First ist nicht automatisch Token First

Utility-Klassen können den Produktvertrag sehr gut unterstützen.

Sie stellen ein begrenztes Gestaltungsvokabular bereit, machen definierte Abstände und Größen unmittelbar verfügbar und vermeiden viele frei benannte lokale CSS-Klassen. Ein Team kann Oberflächen zusammensetzen, ohne für jede kleine Layoutentscheidung eine neue Abstraktion zu erfinden.

Das funktioniert jedoch nur, wenn die Utilities selbst an den Produktvertrag gebunden sind.

Utility First ist nicht automatisch Token First.

Auch ein Utility-System kann freie Werte ermöglichen. Ein Ausdruck wie gap-[13px] ist keine bessere Produktentscheidung als gap: 13px. Die Schreibweise ist kompakter, der Wert bleibt aber lokal erfunden.

Dasselbe gilt für frei gewählte Farben, Schatten, Radien oder Schriftgrößen. Ein Team kann mit Utility-Klassen ebenso gut eine eigene Designsprache entwickeln wie mit klassischen Stylesheets.

Tailwind, die Utilities von Bootstrap und ähnliche Ansätze verhindern eine lokale Designsprache daher nicht automatisch. Sie können einen themenfähigen und produktkonformen Weg technisch bequem anbieten. Die notwendige Disziplin ersetzen sie nicht.

Der Unterschied liegt im erlaubten Vokabular.

Werden semantische Produkt-Tokens über Utilities zugänglich gemacht, kann beispielsweise eine Klasse für eine primäre Aktion auf die entsprechende Rolle im Produkt-Theme verweisen. Ändert sich deren konkrete Farbe, bleibt die Bedeutung der Klasse stabil.

Werden dagegen nur technische Rohwerte angeboten, verbreiten sich Entscheidungen wie „blau in Stufe sechs“ oder „Abstand vier“ über den Code. Solche Bezeichnungen beschreiben eine Implementierung, aber nicht ihre Rolle.

Das Werkzeug kann die Einhaltung des Vertrags erleichtern. Es kann nicht entscheiden, ob eine lokale Abweichung fachlich notwendig ist.

Das Produkt besitzt das Theme

Ein gemeinsames Theme sollte nicht an ein bestimmtes Framework gekoppelt sein. Andernfalls würde die visuelle Identität des Produkts von der technischen Implementierung eines einzelnen Remotes abhängen.

Die gemeinsame Ebene benötigt deshalb semantische Produkt-Tokens:

:root {
  --product-color-primary-action: ...;
  --product-color-danger: ...;
  --product-color-surface: ...;
  --product-color-text: ...;
  --product-color-text-muted: ...;

  --product-typography-heading: ...;
  --product-typography-body: ...;
  --product-typography-label: ...;

  --product-space-card-padding: ...;
  --product-space-content-gap: ...;
  --product-space-section: ...;

  --product-radius-control: ...;
  --product-radius-card: ...;
  --product-control-height: ...;
}

Diese Namen beschreiben nicht primär einen konkreten Wert. Sie beschreiben dessen Bedeutung im Produkt.

Bezeichnungen wie blue-600, gray-100 oder spacing-4 liegen näher an der technischen Darstellung. Sie können innerhalb eines Design-Systems als Rohwerte sinnvoll sein, sind aber als öffentlicher Produktvertrag weniger stabil.

Eine primäre Aktion muss heute vielleicht blau sein. Nach einer neuen Corporate Identity kann sie eine andere Farbe erhalten. Die Rolle bleibt trotzdem eine primäre Aktion. Entsprechend sind Begriffe wie primary-action, danger, surface, text-muted, control-height oder content-spacing langfristig aussagekräftiger.

Semantische Tokens erlauben außerdem mehrere Produktkontexte. Ein Dark Mode kann dieselbe Rolle anders abbilden. Eine kompakte Ansicht kann die Höhe eines Controls reduzieren. Ein barriereärmeres Kontrast-Theme kann Farben verändern, ohne dass jedes Remote seine Komponenten neu interpretieren muss.

Das Produkt entscheidet, was ein Wert bedeutet. Das Remote entscheidet, wie sein UI-Stack diesen Wert technisch abbildet.

Damit bleibt der Vertrag frameworkneutral. Ein Angular-Remote kann die Produkt-Tokens in ein Angular-Material-Theme übersetzen. Ein React-Remote bildet sie auf das Theme seiner Komponentenbibliothek ab. Ein Utility-basierter Stack übernimmt sie in seine Konfiguration.

Die technische Form darf unterschiedlich sein. Die semantischen Rollen bleiben gemeinsam.

Pro Remote ein Adapter, nicht eine eigene Identität

Unterschiedliche UI-Stacks benötigen unterschiedliche Integrationen. Das ist kein Fehler, sondern eine natürliche Folge technischer Autonomie.

Ein mögliches Modell sieht so aus:

Produkt-Tokens
├── Angular-Material-Theme
├── Material-UI-Theme
├── Tailwind-Konfiguration
├── Bootstrap-Konfiguration
└── begrenztes Custom CSS

Jeder Ast übersetzt denselben Produktvertrag in die Sprache des jeweiligen Stacks. Die Adapter können sich technisch deutlich unterscheiden. Sie müssen weder identische APIs noch dieselben internen Mechanismen verwenden.

Problematisch wäre ein anderes Modell: Jedes Remote definiert eigene Farben, Typografie, Dichte, Radien, Formularzustände, Fehlermeldungen und Interaktionsmuster. Dann existieren nicht mehrere technische Adapter, sondern mehrere Produktidentitäten.

Jedes Remote darf ein eigenes technisches Theme besitzen. Es darf nicht eigenmächtig eine eigene Produktsprache erfinden.

Der Host beziehungsweise die Produktplattform bestimmt den aktiven Produktkontext. Dazu können das aktuelle Theme, die Dichte, die Sprache oder weitere globale Einstellungen gehören. Das Remote erhält diesen Kontext über einen stabilen Vertrag und übersetzt ihn in seine technische Umgebung.

Der Host muss dafür weder die Komponentenbibliothek des Remotes kennen noch dessen interne Theme-Implementierung steuern. Er liefert Bedeutung und Kontext, keine komponentenspezifischen Anweisungen.

So bleibt die Grenze sauber: Die Plattform besitzt das Produkt-Theme. Das Remote besitzt den Adapter.

Pointiert formuliert:

Pro Remote ein Theme-Adapter – nicht pro Remote eine eigene Corporate Identity.

Der Mini-Host liefert denselben Vertrag

Dynamische Remotes sollen unabhängig vom echten Host entwickelt und getestet werden können. Andernfalls wird die versprochene Autonomie bereits für lokale Entwicklung und automatisierte Tests wieder aufgehoben.

Dafür benötigt ein Remote einen Mini-Host oder eine vergleichbare lokale Laufzeitumgebung.

Der Mini-Host stellt die Plattformverträge bereit, die das Remote im Produktbetrieb erwartet. Dazu können Theme und Design Tokens ebenso gehören wie Locale, Authentifizierungskontext, Navigation, Feature-Konfiguration und weitere globale Fähigkeiten.

Produktbetrieb
└── echter Host liefert Produkt- und Theme-Vertrag

Lokale Entwicklung
└── Mini-Host liefert denselben Vertrag mit definierten Produktvarianten

Entscheidend ist, dass der Mini-Host keine zweite visuelle Realität erzeugt.

Frei erfundene Testfarben oder vereinfachte lokale Styles erscheinen zunächst bequem. Sie führen jedoch dazu, dass das Remote während der Entwicklung unter anderen Bedingungen betrachtet wird als im späteren Produkt. Probleme mit Kontrasten, Abständen, Dichte oder Theme-Wechseln fallen dann erst in der Integration auf.

Der Mini-Host sollte deshalb dieselben semantischen Rollen und dieselbe Vertragsstruktur verwenden. Er kann unterschiedliche definierte Test-Themes anbieten, um beispielsweise helle, dunkle, kompakte oder kontrastreiche Varianten zu prüfen.

Der Mini-Host ersetzt nicht die Produktplattform. Er stellt deren Verträge für Entwicklung und Tests bereit.

Diese Nachbildung darf nicht zu einer engen Kopplung an die konkrete Implementierung des echten Hosts führen. Das Remote sollte gegen den Plattformvertrag entwickelt werden, nicht gegen interne Services, Komponenten oder Zustandsmodelle des Hosts.

Gerade dadurch wird der Mini-Host zu einem wertvollen Architekturtest. Lässt sich der notwendige Produktkontext nicht unabhängig bereitstellen, ist der Vertrag möglicherweise noch nicht klar genug geschnitten.

Design Tokens vereinheitlichen noch kein Verhalten

Ein Produkt kann dieselben Farben, Abstände und Schriftarten verwenden und sich trotzdem uneinheitlich anfühlen.

Remote A validiert ein Formularfeld beim Verlassen des Feldes. Remote B zeigt Fehler erst nach dem Absenden. Remote C blendet bei jedem Tastendruck neue Fehlermeldungen ein.

Alle drei Formulare können dieselben Design Tokens verwenden. Trotzdem muss sich die Person vor dem Bildschirm in jedem Bereich neu orientieren.

Dasselbe gilt für das Speichern. Ein Remote verwendet einen klaren primären Button. Ein anderes speichert automatisch. Ein drittes versteckt die Aktion hinter einem kaum erklärten Toolbar-Icon. Jede Lösung kann für sich genommen begründbar sein. Ohne gemeinsamen Produktkontext erzeugen sie jedoch widersprüchliche Erwartungen.

Design-Systeme benötigen deshalb neben visuellen Tokens auch gemeinsame Interaction Patterns.

Dazu gehören insbesondere Entscheidungen über:

• Formularvalidierung
• Speichern und Abbrechen
• Ladezustände
• Fehlerbehandlung
• Benachrichtigungen
• Bestätigungsdialoge
• destruktive Aktionen
• Fokusführung und Tastaturbedienung
• Navigation
• leere Zustände
• Tabellen und Filter

Nicht jedes Detail muss in jedem Remote identisch umgesetzt sein. Ein komplexer Editor benötigt andere Interaktionen als eine einfache Stammdatenmaske. Gemeinsame Patterns definieren jedoch den Normalfall und die Erwartungen, von denen bewusst abgewichen werden kann.

Eine destruktive Aktion sollte beispielsweise nicht in einem Remote sofort ausgeführt, im nächsten durch einen Dialog bestätigt und im dritten über eine mehrere Sekunden sichtbare Undo-Funktion abgesichert werden, ohne dass die Unterschiede fachlich erklärbar sind.

Design Tokens vereinheitlichen Werte. Interaction Patterns vereinheitlichen Verhalten.

Das Produkt besitzt daher nicht nur Farben und Typografie. Es besitzt auch grundlegende Erwartungen daran, wie sich seine Oberfläche verhält.

Auch hier gilt die Beweislast der Ausnahme. Fachliche Anforderungen können ein abweichendes Muster rechtfertigen. Die bloße Vorliebe eines Teams sollte es nicht tun.

Wo Web Components sinnvoll helfen können

Wenn mehrere Frameworks dieselben visuellen Bausteine benötigen, erscheinen Web Components als naheliegende Lösung. Sie ermöglichen eine gemeinsame Implementierung, die grundsätzlich frameworkneutral eingebunden werden kann.

Für bestimmte Komponenten kann das sinnvoll sein:

• markenprägende, frameworkübergreifende Elemente
• kleine globale Plattformkomponenten
• klar gekapselte Spezialkomponenten
• Bausteine, deren DOM und Verhalten wirklich identisch bleiben sollen

Ein markenprägender Produktbaustein, ein frameworkübergreifend eingesetztes Bedienelement oder eine stark spezialisierte Visualisierung kann durch eine Web Component konsistenter bereitgestellt werden als durch mehrere unabhängige Nachbauten.

Damit sinkt bei diesem konkreten Baustein die Gefahr visueller und funktionaler Drift.

Der Nutzen darf jedoch nicht mit einer kostenlosen Abstraktion verwechselt werden. Web Components benötigen eigene Verträge für Properties und Events. Sie müssen in Formulare und Zustandsmodelle verschiedener Frameworks integriert werden. Accessibility, Fokusführung und Tastaturverhalten bleiben eine Verantwortung der Implementierung. Häufig entstehen zusätzliche Frameworkadapter, Teststufen und Release-Prozesse.

Auch die gemeinsame Komponente muss versioniert, dokumentiert und langfristig gepflegt werden. Sie ist damit ein Produkt der Plattform und nicht lediglich ein neutraler technischer Container.

Web Components können einzelne gemeinsame Bausteine vereinheitlichen. Sie ersetzen nicht automatisch ein vollständiges Design-System.

Insbesondere Shadow DOM löst weder die organisatorische Abstimmung noch die Frage nach der visuellen Identität. Eine gekapselte Komponente kann ebenso gut die falschen Farben, unpassende Abstände oder inkonsistente Interaktionen enthalten. Kapselung verhindert unerwünschte Einflüsse. Sie erzeugt nicht automatisch einen guten Produktvertrag.

Web Components sind deshalb eine Option für bewusst ausgewählte gemeinsame Bausteine. Sie sind keine allgemeine Antwort auf jede frameworkübergreifende UI-Frage.

Die wirtschaftlichen Kosten sichtbarer Autonomie

Lokale UI-Autonomie besitzt reale Vorteile.

Ein Team kann Entscheidungen schneller treffen, die Stärken seines Frameworks besser nutzen und unabhängig von einer zentralen Komponenten-Roadmap arbeiten. Weniger Abstimmung kann kurzfristig mehr Geschwindigkeit erzeugen.

Diese Rechnung bleibt jedoch unvollständig, solange nur die Kosten des einzelnen Teams betrachtet werden.

Mehr lokale Freiheit kann mehrere Theme-Adapter, zusätzliche visuelle Regressionstests und wiederholte Accessibility-Prüfungen erforderlich machen. Die Zahl der Varianten steigt. UX-Governance wird aufwendiger. Migrationen müssen über unterschiedliche Bibliotheken und lokale Sonderfälle hinweg geplant werden.

Was Teams durch lokale UI-Freiheit an Abstimmung sparen, kann das Produkt später als Harmonisierungskosten zurückzahlen.

Der Unterschied wird besonders bei größeren Veränderungen sichtbar.

Ist eine neue Corporate Identity konsequent über Produkt-Tokens und technische Adapter angebunden, kann ein großer Teil der Umstellung zentral vorbereitet werden. Die einzelnen Remotes aktualisieren ihre Adapter, prüfen die Ergebnisse und korrigieren begrenzte Sonderfälle.

Existieren dagegen zahlreiche freie Farbwerte, lokale Typografieregeln und überschriebene Komponenten, wird dieselbe Veränderung zu einer verteilten Migration. Jedes Remote muss durchsucht, bewertet und angepasst werden. Visuelle Abweichungen zeigen sich häufig erst in Screenshots oder im integrierten Produkt.

Die lokale Ersparnis kann Jahre später von vielen Teams erneut bezahlt werden.

UI-Autonomie ist lokal billig und global teuer, sobald sie für Nutzer sichtbar wird.

Das bedeutet nicht, dass mehrere UI-Stacks wirtschaftlich grundsätzlich falsch sind. Die zusätzliche Komplexität kann gerechtfertigt sein, wenn unterschiedliche fachliche Bereiche, Lebenszyklen oder Teamstrukturen davon profitieren.

Sie sollte nur als reale Produktinvestition betrachtet werden. Jeder zusätzliche Stack benötigt einen zuverlässigen Theme-Adapter, Tests und Know-how. Jede begründete Abweichung erweitert die langfristige Wartungsfläche.

Technische Vielfalt ist nicht kostenlos. Sichtbare Inkonsistenz ist allerdings meist noch teurer, weil sie neben der Entwicklung auch das Vertrauen und die Orientierung der Nutzer belastet.

Governance statt Zentralismus

Ein gemeinsamer UI-Vertrag bedeutet nicht, dass ein zentrales Team jede CSS-Klasse genehmigen muss.

Eine solche Organisation würde die Vorteile autonomer Teams untergraben und den Produktvertrag selbst zum Engpass machen. Gute Governance besteht nicht aus Mikromanagement, sondern aus klaren, leicht nutzbaren Grenzen.

Dafür müssen die vorgesehenen Mittel praktisch verfügbar sein:

• Produkt-Tokens sind technisch zugänglich.
• Themes lassen sich mit vertretbarem Aufwand integrieren.
• Ein Mini-Host stellt den Produktkontext bereit.
• Komponenten und Interaction Patterns sind dokumentiert.
• Vereinbarte Utility-Klassen decken typische Layouts ab.
• Accessibility-Grundlagen sind vorbereitet.
• Lokale und automatisierte Tests sind möglich.

Ein Vertrag, dessen Einhaltung unnötig kompliziert ist, wird in der Praxis häufiger umgangen. Benötigt die Verwendung eines korrekten Tokens mehrere Abhängigkeiten und langwierige Abstimmungen, während ein freier CSS-Wert sofort funktioniert, erzeugt die Plattform selbst einen Anreiz zur Abweichung.

Governance muss deshalb beide Seiten ernst nehmen.

Die Teams tragen die Verantwortung, vorhandene Verträge nicht aus Bequemlichkeit zu umgehen. Die Plattform trägt die Verantwortung, den richtigen Weg zum einfachsten vernünftigen Weg zu machen.

Automatisierbare Regeln können dabei helfen. Linting kann bestimmte freie Werte erkennen. Visuelle Tests können Theme-Varianten prüfen. Dokumentierte Referenzimplementierungen können typische Formulare, Tabellen und Zustände zeigen.

Nicht jede Abweichung lässt sich technisch verhindern. Das ist auch nicht notwendig. Entscheidend ist, dass Abweichungen sichtbar, bewusst und begründbar bleiben.

Ein Team kann den Code seines Remotes besitzen und innerhalb des vereinbarten Rahmens weitreichend autonom arbeiten. Es besitzt jedoch nicht die visuelle Identität des gesamten Produkts.

UI-Autonomie endet beim Produkterlebnis

Technische UI-Autonomie ist sinnvoll, solange sie innerhalb eines gemeinsamen Produktvertrags stattfindet.

Remotes dürfen unterschiedliche Frameworks, Komponentenbibliotheken und technische Theme-Implementierungen verwenden. Zusammengehörigkeit entsteht nicht durch identische Technik, sondern durch gemeinsame semantische Rollen und Verhaltensmuster.

Theme-Adapter, Komponenten-APIs und vereinbarte Utilities bilden den Normalfall. Custom CSS und eigene Komponenten bleiben möglich, tragen aber die Begründungslast und müssen an den Produktvertrag angebunden bleiben.

Das technische Modell ist damit vergleichsweise einfach. Schwierig ist seine organisatorische Konsequenz.

Über Jahre entstehen nicht deshalb uneinheitliche Oberflächen, weil kein Theme existiert. Sie entstehen, weil kleine lokale Ausnahmen nicht mehr als Ausnahmen behandelt werden. Aus wenigen freien Werten wird schrittweise eine parallele Designsprache, deren Harmonisierung später über alle Remotes verteilt bezahlt werden muss.

Das Remote besitzt die technische Umsetzung. Das Produkt besitzt Identität und Verhalten.

Ein konsistentes Produkterlebnis ist technisch leicht herzustellen, aber organisatorisch schwer durchzuhalten.

UI-Autonomie endet dort, wo Nutzer die Architektur sehen.