HTML in Designsystemen

Ein Designsystem ist eine gemeinsame Bibliothek aus Komponenten, Tokens, Mustern und Richtlinien, die in den Produkten einer Organisation verwendet wird. Der HTML-Teil des Systems kapselt Markup-Konventionen, sodass jedes Produkt konsistente Strukturen für Buttons, Modals, Formulare und Cards rendert.

Tokens sind atomare Designwerte (color: blue-500, spacing: 16px). Komponenten sind wiederverwendbare Einheiten aus HTML+CSS+JS (Button, Modal, TextField). Muster sind Kompositionen auf höherer Ebene (Loginformular, Content-Card mit Avatar). Die HTML-Struktur ist auf Komponentenebene festgelegt; Muster kombinieren Komponenten.

Komponenten kodifizieren Best Practices: Jeder Button verwendet das Element <button> (kein div) mit dem passenden type-Attribut. Jedes Modal fängt den Fokus ab, unterstützt Escape und verfügt über die richtigen ARIA-Rollen. Durch die Verwendung von Komponenten muss Barrierefreiheit nicht für jedes Produktfeature neu implementiert werden.

Storybook rendert jede Komponente isoliert mit verschiedenen Props und Varianten. Designer und Product Manager sehen die verfügbaren Komponenten, ohne Code lesen zu müssen; Entwickler sehen Anwendungsbeispiele, ohne den Quellcode durchsuchen zu müssen. Es ist der De-facto-Standard für die Dokumentation von Designsystemen.

Behandeln Sie das Designsystem wie ein mit Semver veröffentlichtes Paket. Änderungen an HTML/CSS mit potenziell inkompatiblen Auswirkungen (etwa die Umbenennung einer CSS-Klasse, von der Consumer abhängen, oder das Entfernen eines Komponenten-Slots) erhöhen die Major-Version. Consumer aktualisieren bewusst nach ihrem eigenen Zeitplan und nicht überraschend.

Props, Slots und exponierte Teile einer Komponente bilden ihre öffentliche API. Sobald sie an Consumer ausgeliefert wurden, sollten Änderungen daran als aufwendig betrachtet werden. Führen Sie neue APIs schrittweise ein: Ergänzen Sie die neue API neben der alten, protokollieren Sie Warnungen bei der alten Verwendung und entfernen Sie sie erst nach einem anhand von Messwerten bestimmten Zeitraum.

Tokens ermöglichen Theming: Tauschen Sie die Token-Zuordnung für Farben aus, und jede Komponente übernimmt die neue Palette. White-Labeling (verschiedene Marken teilen sich Komponenten mit unterschiedlicher visueller Gestaltung) wird trivial, wenn alles von Tokens gesteuert wird und Komponenten auf Tokens statt auf fest codierte Werte verweisen.

Für Organisationen, die mehrere Frameworks verwenden (React, Vue, Angular), bieten Web Components eine Implementierung, die überall funktioniert. Entwickeln Sie mit Lit, FAST oder Vanilla; die Verwendung ist in jedem Framework identisch. Die HTML-Struktur ist der Vertrag, nicht das Framework.

Designsysteme integrieren Barrierefreiheit einmalig in jede Komponente: Tastaturinteraktionen, ARIA-Rollen, Fokusverwaltung und Farbkontrast. Produktteams, die das System übernehmen, erhalten Barrierefreiheit automatisch, statt jedes Feature von Grund auf zu entwickeln – dadurch sinkt die Zahl der Barrierefreiheitsfehler im gesamten Unternehmen messbar.

Verfolgen Sie, welche Produkte welche Version des Designsystems verwenden. Tools wie der Komponenten-Katalog von Backstage, eigene Slack-Bots zur Überwachung von package.json oder einfache interne Dashboards zeigen, wo die aktuelle Version noch nicht eingeführt wurde. Metriken zur Einführung begründen weitere Investitionen.

Legen Sie fest, wer Komponenten hinzufügen darf: ausschließlich ein zentrales Designsystem-Team oder auch Produktteams im Rahmen föderierter Beiträge? Jedes Modell hat Vor- und Nachteile. Zentrale Teams veröffentlichen langsamer, halten aber die Qualität aufrecht; föderierte Teams arbeiten schneller, riskieren jedoch eine Fragmentierung. Treffen Sie die Entscheidung bewusst und abhängig von der Größe Ihrer Organisation.

Designsysteme sind lebende Produkte. Fügen Sie Komponenten hinzu, wenn in Produkten neue Muster entstehen, verwerfen Sie Komponenten, die nicht mehr passen, und führen Sie Refactorings durch, wenn grundlegende Entscheidungen geändert werden müssen. Behandeln Sie das System wie Software mit einer Roadmap und nicht wie ein fertiges Artefakt.

Warum werden Design-Tokens (wie color: blue-500, spacing: 16px) gegenüber fest codierten Werten in Komponenten bevorzugt?

Designsysteme bündeln Tokens (atomare Werte), Komponenten (wiederverwendbare HTML-Einheiten) und Muster (Kompositionen auf höherer Ebene) in einer versionierten, von mehreren Produkten gemeinsam genutzten Bibliothek. Verwenden Sie Storybook zur Dokumentation, Web Components zur frameworkübergreifenden Nutzung und Semver für Stabilität. Integrieren Sie Barrierefreiheit in jede Komponente, verfolgen Sie die Einführung und entwickeln Sie das System als lebendes Produkt weiter.