B2B-Plattformen unterscheiden sich grundlegend von verbraucherorientierten Anwendungen. Sie verarbeiten hohe Datenmengen, enthalten verschachtelte Berechtigungssysteme und bilden komplexe Fachlogiken ab, die oft über Jahre gewachsen sind. Wenn Designsysteme in solchen Umgebungen scheitern, liegt das selten an unzureichenden UI-Elementen. Das Problem entsteht fast immer durch eine mangelhafte architektonische Kopplung zwischen Design-Entscheidungen und dem eigentlichen Produktionscode.

Ein tragfähiges Designsystem für B2B-Software fungiert als technische Infrastruktur. Es definiert verbindliche Schnittstellen für Entwickler und Produktteams, minimiert den Abstimmungsaufwand bei der Release-Planung und verhindert visuelle sowie funktionale Inkonsistenzen in komplexen Workflows. Dieser Leitfaden beschreibt die praxiserprobte Strukturierung eines B2B-Designsystems von den Token-Grundlagen bis zur Migration bestehender Altsysteme.

Aufbau einer Token-Hierarchie von Grundfarben bis Komponenten

Design Tokens sind benannte Entitäten, die Rohwerte wie Hex-Codes, Pixelmaße oder Animationskurven speichern. Um ein B2B-System skalierbar zu halten, genügt eine flache Liste von Tokens nicht. Eine saubere Architektur nutzt eine dreistufige Hierarchie: Primitive Tokens, Semantische Tokens und Komponenten-Tokens. Diese Trennung erlaubt es, globale Markenänderungen durchzuführen oder neue Farbmodi wie einen kontrastreichen Modus einzuführen, ohne den Code einzelner Komponenten anpassen zu müssen.

Primitive Tokens definieren das Rohmaterial des Systems, ohne ihnen einen Verwendungszweck zuzuweisen. Sie beschreiben den physikalischen Wert, beispielsweise color-blue-600: #1e40af oder space-16: 1rem. Diese Werte dürfen niemals direkt in Komponenten-Stylesheets aufgerufen werden. Semantische Tokens referenzieren die primitiven Tokens und weisen ihnen einen funktionalen Kontext zu, etwa color-background-interactive-default: {color-blue-600}. Komponenten-Tokens binden diese Semantik schließlich an spezifische UI-Elemente wie button-primary-background-default: {color-background-interactive-default}.

Für B2B-Anwendungen spielt die Informationsdichte eine zentrale Rolle. Ein effektiver Ansatz besteht darin, Abstandstokens (Spacing) und Typografie-Skalen an ein Dichte-Attribut zu koppeln. Anstelle starrer Pixelwerte greifen Komponenten auf Tokens zu, die sich je nach eingestelltem Modus (kompakt oder standard) anpassen. In einer kompakten Tabellenansicht verringert sich das Padding von space-12 (12 Pixel) auf space-6 (6 Pixel), während die Schriftgröße von 14 Pixeln auf 12 Pixel wechselt. Dies geschieht rein über CSS-Variablen auf Wurzelebene des jeweiligen Containers.

Standardisierung wiederkehrender Datenansichten und Filter

Der Großteil der B2B-Interaktionen findet in Datentabellen, Listen und Filtern statt. Entwicklerteams neigen dazu, diese komplexen Ansichten für jedes Fachmodul neu zu implementieren, was zu divergierendem Verhalten bei Sortierung, Filterung und Tastaturbedienung führt. Das Designsystem muss standardisierte Layout-Muster bereitstellen, die Datenabfragen und Statusmodi vereinheitlichen.

Ein robustes Tabellenmuster umfasst mindestens fünf verbindliche Zustände: Initiales Laden (Skeleton-State), Datenanzeige (mit Paginierung oder virtuellem Scrolling ab 500 Datensätzen), Leerer Zustand ohne Filter, Leerer Zustand mit aktiven Filtern sowie Fehlerzustand mit Wiederholungsoption. Die Filterlogik selbst sollte in zwei Varianten unterteilt werden:

• Inline-Schnellfilter: Für 1 bis 3 hochfrequente Attribute (z. B. Volltextsuche, Status-Dropdown). Diese liegen horizontal direkt über der Datenansicht.
• Erweiterte Filterleiste: Für komplexe Abfragen mit Datumsbereichen, numerischen Schwellenwerten oder verschachtelten Oder-Verknüpfungen. Diese wird als vertikales Drawer-Panel realisiert, um die vertikale Lesefläche der Tabelle nicht dauerhaft einzuschränken.

Die Synchronisation des Filterzustands mit den URL-Query-Parametern muss im Komponentenvertrag verankert sein. Wenn ein Nutzer eine Tabelle filtert, Seite 4 aufruft und die URL teilt, muss der Empfänger exakt dieselbe Ansicht sehen. Wird dieses Verhalten nicht auf Komponentenebene standardisiert, implementiert jedes Entwicklerteam eigene Logiken für das Browser-History-Management, was zu inkonsistenten Anwendungszuständen führt.

Zusammenarbeit zwischen Figma und Komponenten-Repositories

Die Synchronisation zwischen dem Figma-Workspace der Designer und dem Code-Repository der Entwickler bricht häufig ab, sobald die erste Version veröffentlicht ist. Um diesen Bruch zu verhindern, muss das Komponenten-Repository als primäre Quelle der Wahrheit für Tokenwerte dienen. Figma fungiert als Konsument und Editor dieser Werte über automatisierte Schnittstellen.

Der Prozess basiert auf einem dateibasierten Austauschformat:

1. Tokens werden als JSON-Dateien in einem zentralen Git-Repository versioniert (z. B. nach der Spezifikation der W3C Design Tokens Community Group).
2. Ein Tool wie Style Dictionary übersetzt die JSON-Dateien über GitHub Actions in plattformspezifische Formate: CSS Custom Properties, SCSS-Variablen und TypeScript-Definitionen.
3. Über ein Plugin wie Tokens Studio oder die native Figma Variables API werden Aktualisierungen via GitHub Personal Access Token direkt in Figma importiert.
4. Entwerfen Designer neue Tokens, exportiert das Plugin einen Pull Request zurück in das Git-Repository, wo automatisierte Linting-Prüfungen Validierungsfehler abfangen.

Komponenten in Figma müssen exakt dieselben Properties widerspiegeln wie die React-, Vue- oder Web-Components im Code. Wenn eine Button-Komponente im Code die Properties variant="primary", size="dense" und isLoading={true} verarbeitet, müssen diese Varianten in Figma identisch benannt sein. Jede Abweichung in der Nomenklatur erhöht die Reibung bei der Übergabe und führt zu fehlerhaften Implementierungen.

Automatisierte Regressionstests für Designkomponenten

Manuelle Tests von UI-Komponenten über verschiedene Browser und Bildschirmauflösungen hinweg binden erhebliche Ressourcen und übersehen feine visuelle Fehler. B2B-Plattformen benötigen eine zweistufige automatisierte Testpipeline für ihre Komponentenbibliothek: funktionale Komponententests und visuelle Regressionstests.

Storybook dient dabei als isolierte Entwicklungsumgebung, in der jede Komponente mit all ihren Zuständen (Default, Hover, Focus, Active, Disabled, Loading, Error) als "Story" dokumentiert wird. Diese Geschichten sind die direkte Testgrundlage. Ein Test-Runner führt Storybook kopflos aus und prüft zunächst die Barrierefreiheit nach den Standards der WCAG 2.1 AA mittels integrierter Axe-Core-Prüfungen.

Für visuelle Regressionstests erfassen Tools wie Playwright oder Chromatic bei jedem Pull Request Screenshots aller Komponenten-Stories und vergleichen diese mit dem Hauptzweig:

• Schwellenwert festlegen: Die Bildvergleichs-Engine arbeitet mit einem Pixel-Differenz-Schwellenwert (Delta) von typischerweise 0,02 bis 0,05, um minimale Rendering-Unterschiede von Schriftarten zwischen Betriebssystemen zu ignorieren.
• Dynamische Daten neutralisieren: Datumsanzeigen, Zufallswerte oder Skeleton-Animationen werden über feste Test-Fixtures und deaktivierte CSS-Animationen stabilisiert, um Falschalarme (Flakiness) zu vermeiden.
• Automatische Blockierung: Weicht ein Pixelbild ab, blockiert die Continuous-Integration-Pipeline das Mergen des Pull Requests, bis ein Entwickler oder Designer die visuelle Änderung explizit über die Benutzeroberfläche des Testwerkzeugs genehmigt.

Strategien zur schrittweisen Einführung im Altsystem

Ein vollständiger Rewrite einer gewachsenen B2B-Plattform zugunsten eines neuen Designsystems birgt unkalkulierbare wirtschaftliche und technische Risiken. Die Umstellung erfolgt stattdessen schrittweise über das Strangler-Fig-Muster, bei dem neue Systemteile nach und nach das Altsystem ersetzen, bis die alte Codebasis vollständig abgelöst ist.

Der erste Eingriff erfolgt auf der Token-Ebene. Anstatt Komponenten auszutauschen, werden die globalen CSS-Klassen und Stylesheets des Altsystems mit den neuen Design Tokens verknüpft. Indem Entwickler alte Farbwerte wie #2B6CB0 durch die neue CSS-Variable var(--color-brand-primary) ersetzen, erhält die Altanwendung bereits eine visuelle Angleichung, ohne dass HTML-Strukturen verändert werden müssen.

Für den anschließenden Austausch von Komponenten empfehlen sich drei Vorgehensweisen:

1. Kapselung über Namespaces: Neue Komponenten werden mit CSS-Modulen, scoped Styles oder einem spezifischen Präfix (z. B. .ds-button) importiert, um Kaskadierungskonflikte mit dem globalen Legacy-CSS zu verhindern.
2. Vertikaler Modulschnitt: Es wird nicht eine einzelne Komponente (wie der Button) über 40 Bildschirme hinweg ausgetauscht. Stattdessen wird eine komplette, in sich geschlossene Ansicht (z. B. die Benutzerverwaltung oder das Rechnungswesen) vollständig auf die neuen Komponenten umgestellt. Dies garantiert ein konsistentes Nutzererlebnis innerhalb dieses spezifischen Workflows.
3. Micro-Frontends und Wrapper: In Architekturen mit Micro-Frontends stellt das Designsystem als NPM-Paket sicher, dass unabhängig deployte Fachmodule dasselbe Erscheinungsbild teilen. Für ältere Teilbereiche können Container-Wrapper genutzt werden, die das neue Designsystem laden und Legacy-Views umschließen.

Typische Fehler in der Praxis

Bei der Strukturierung von B2B-Designsystemen treten wiederkehrende Fehlentscheidungen auf, die den Nutzen der Initiative schmälern:

Übermäßige Komplexität am Anfang: Teams definieren oft hunderte Komponenten und Token-Ebenen im Voraus, bevor echte Anwendungsfälle vorliegen. Ein Designsystem sollte mit den Kernbestandteilen beginnen: Farbpalette, Typografie, Abstände, Buttons, Formularfelder und einfache Tabellenzellen. Erst wenn diese in mindestens drei Produktionsmodulen stabil laufen, folgen komplexere Organismen wie Daten-Grid-Filter oder Dashboard-Karten.

Vernachlässigung der Dokumentation des "Warum": Eine reine Dokumentation von Komponenten-Eigenschaften reicht nicht aus. Das Designsystem muss klare Anwendungsrichtlinien (Do's and Don'ts) enthalten. Entwickler müssen erfahren, wann ein sekundärer Button gegenüber einem Tertiär-Button zu bevorzugen ist und wie mit mehrzeiligen Tabelleninhalten verfahren werden muss.

Fehlendes Versionierungsmodell: Designsystem-Pakete ohne strikte Einhaltung von Semantic Versioning (SemVer) führen zu Misstrauen bei den konsumierenden Produktteams. Ein visueller Umbruch in einer Tabelle ist ein Breaking Change und erfordert einen Major-Release, damit Teams gezielt migrieren können, ohne dass laufende Releases gefährdet werden.

Nächste Schritte für die Implementierung

Beginnen Sie nicht mit dem Entwurf neuer UI-Elemente. Verschaffen Sie sich stattdessen einen Überblick über die bestehende Realität im Code.

1. UI-Audit durchführen: Extrahieren Sie alle aktuell verwendeten Hex-Farbcodes, Schriftgrößen und Button-Implementierungen aus der Produktionscodebasis. Nutzen Sie Skripte, um die Duplikate zu quantifizieren. Zeigen Sie dem Produktmanagement die 28 verschiedenen Grautöne, die sich derzeit im System befinden.
2. Token-Architektur aufsetzen: Erstellen Sie das Basis-Repository mit den drei Token-Ebenen (Primitiv, Semantisch, Komponente). Binden Sie Style Dictionary ein und konfigurieren Sie die automatische Generierung von CSS-Variablen.
3. Ersten vertikalen Schnitt definieren: Wählen Sie eine überschaubare, aber geschäftskritische Ansicht in Ihrer Anwendung, beispielsweise die Einstellungen oder eine einfache Datentabelle. Setzen Sie diese Ansicht vollständig mit den neuen Tokens und einer ersten Version der Komponentenbibliothek um.
4. Governance etablieren: Bestimmen Sie mindestens zwei feste Ansprechpartner (einen Designer, einen Entwickler), die wöchentlich neue Komponentenanforderungen sichten, Pull Requests prüfen und die Einhaltung der Spezifikationen überwachen.