Design Systems und wiederverwendbare Komponenten

Design Systems und Komponenten

0:00 Das letzte Modul von Tag eins, und es schließt einen Bogen. Bisher haben wir einzelne Entscheidungen getroffen — Kontraste, Zielgrößen, Fokus, Beschriftungen. Jetzt geht es um die Frage, wie man solche Entscheidungen einmal trifft und überall wiederverwendet. Der Leitsatz des Moduls ist deshalb: Tokens sind der Ort, an dem Barrierefreiheit skaliert. Steht der Fokusindikator an einer Stelle fest, erben ihn alle Komponenten.

0:26 Wird er in jeder Komponente neu gestaltet, fehlt er in jeder zweiten. Alles, was Sie hier als Token oder als Spezifikation festhalten, muss an Tag zwei nicht mehr einzeln repariert werden.

Design Systems und wiederverwendbare Komponenten

0:38 Sieben Kapitel liegen vor uns. Wir klären zuerst die drei Schichten eines Design Systems, sprechen dann über Zustände und Varianten — der Teil, der die eigentliche Arbeit ausmacht — und kommen zum Herzstück: den Tokens. Danach geht es um die Anforderungen auf Komponentenebene, um Dokumentation, um Zusammenarbeit und um die Auswahl fremder Bibliotheken.

0:58 In der Übung spezifizieren Sie eine Komponente so vollständig, dass eine andere Gruppe sie ohne Rückfragen bauen kann. Und Sie werden merken: Die Rückfragen sind das eigentliche Ergebnis.

Komponenten, Patterns und Design Tokens

1:10 Fangen wir mit der Sortierung an. Ein Design System besteht aus drei Schichten, die gern durcheinandergeraten. Der Unterschied ist nicht akademisch — er hängt daran, wie oft sich etwas ändert und wie weit eine Änderung reicht. Denken Sie an ein Haus. Die Tokens sind die Baustoffe und Maße — Ziegelgröße, Farbe des Putzes, Höhe einer Stufe.

1:31 Die Komponenten sind Fenster, Türen und Treppen, also gebaute Teile. Und die Patterns sind bewährte Grundrisse: wie man ein Bad anordnet, wie eine Treppe ins Obergeschoss führt. Bei Fahrtwind haben wir für all das ein System, das ich Kompass nenne — es begleitet uns durch die restlichen Module. Dort ist die Abstandsskala ein Token, das Suchergebnis eine Komponente und der mehrstufige Buchungsablauf ein Pattern. Drei Schichten, drei Änderungsgeschwindigkeiten.

2:00 Die rechte Spalte trägt die eigentliche Botschaft, denn sie erklärt, warum man die Schichten überhaupt trennt. Tokens ändern sich selten und wirken überall — deshalb sind sie mächtig und deshalb sind Änderungen dort riskant und teuer zu prüfen. Komponenten ändern sich regelmäßig und wirken an vielen Stellen. Patterns ändern sich bei fachlichen Änderungen, also wenn sich der Buchungsablauf selbst wandelt.

2:22 Wenn Sie sich unsicher sind, wohin etwas gehört, ist das die nützlichste Frage: Wie oft ändert sich das, und wen trifft die Änderung? Die Antwort sortiert fast immer eindeutig ein. Der erste Stolperstein ist der Sammlertrieb: alles zur Komponente erklären, auch was nur einmal vorkommt. Ein Design System, das jede Einzelanfertigung aufnimmt, wird zum Katalog statt zum Werkzeug — und niemand findet mehr etwas.

2:47 Der zweite ist der häufigste in der Praxis: Tokens einführen und daneben weiter feste Werte schreiben. Dann haben Sie beide Kosten und keinen Nutzen, weil eine Token-Änderung eben doch nicht überall ankommt. Und der dritte ist ein Wahrheitsproblem: Patterns dokumentieren, die im Produkt nie so umgesetzt wurden. Solche Dokumentation ist schlimmer als keine, weil man sich auf sie verlässt.

Zustände und Varianten systematisch beschreiben

3:10 Jetzt zu dem Teil, der die eigentliche Arbeit einer Komponente ausmacht. Der Normalfall ist schnell gebaut. Die Zustände drumherum sind es, die den Unterschied zwischen einem Entwurf und einem Baustein machen. Zählen wir einmal durch. Ein Knopf hat Ruhe, Hover, Fokus, Aktiv, Deaktiviert und Ladend — sechs Zustände für das simpelste Bedienelement, das es gibt.

3:32 Ein Eingabefeld kommt zusätzlich mit Fehler, Warnung und Nur-Lesen. Wer diese Zustände nicht vorab benennt, bekommt sie trotzdem — nur später und woanders. Sie tauchen dann als Sonderfälle im Anwendungscode auf, jedes Mal anders gelöst und nirgends geprüft. Das ist der stille Preis einer unvollständigen Spezifikation: Die Arbeit verschwindet nicht, sie wird nur vervielfacht und verstreut.

3:57 Und in dieser verstreuten Form ist sie kaum noch zu prüfen. Die mittlere Spalte ist hier die diagnostische, weil sie alle vier Fälle auf dieselbe Ursache zurückführt: Im Entwurf gab es sie nicht. Der Fokuszustand wird nicht dargestellt, weil man beim Entwerfen mit der Maus arbeitet. Der Ladezustand fehlt, weil im Entwurfswerkzeug alles sofort da ist — die Folge sind doppelte Absendungen, weil ungeduldig zweimal geklickt wird.

4:23 Deaktiviert gilt als Randfall und wird deshalb kontrastarm gestaltet, oft unlesbar, und ohne Angabe des Grundes. Und der Fehlerzustand wird ins Formular verschoben und dort in jeder Ansicht anders gelöst. Vier Zustände, eine Ursache: Der Entwurf zeigt den guten Moment. Der erste Stolperstein ist eine stille Zuständigkeitsverschiebung: den Fokuszustand im Entwurf weglassen und ihn der Entwicklung überlassen.

4:47 Die Entwicklung entscheidet dann nach Gefühl, und zwar in jeder Komponente anders. Der zweite: Deaktivierte Elemente vom Kontrast ausnehmen. Das ist gängige Praxis und trotzdem problematisch — wer nicht lesen kann, was da steht, erfährt auch nicht, welche Option ihm gerade fehlt. Und der dritte ist ein Wildwuchsproblem: Varianten anlegen, die sich in einem Pixel Abstand unterscheiden.

5:09 Solche Varianten sind der Anfang vom Ende der Übersicht, und sie entstehen fast immer aus einer einzelnen Sonderanforderung.

Design Tokens für Farbe, Typografie, Abstände und Fokus

5:17 Damit kommen wir zum Kern des Moduls. Tokens sind die Stelle, an der Barrierefreiheit skaliert — oder eben nicht skaliert. Diesen Satz nehmen Sie bitte mit, auch wenn Sie sonst nichts aus diesem Modul behalten. Der Gedanke ist einfach und die Wirkung groß. Wenn der Fokusindikator einmal als Token feststeht — Dicke, Farbe, Abstand, geprüfter Kontrast — dann erben ihn alle Komponenten, auch die, die nächstes Jahr entstehen.

5:42 Wird er dagegen in jeder Komponente einzeln gestaltet, wird er in jeder zweiten vergessen. Nicht aus Nachlässigkeit, sondern weil man beim Bauen mit der Maus arbeitet und ihn deshalb nicht sieht. Dasselbe gilt für Zielgrößen und Textkontraste. Das ist der Hebel: Sie treffen die Entscheidung einmal, richtig und geprüft, und sie gilt anschließend für alles, was daraus gebaut wird.

6:05 Oben sehen Sie den Normalzustand vieler Projekte: Jede Komponente löst den Fokus für sich, mit unterschiedlichen Mitteln, unterschiedlichen Farben und in unterschiedlicher Qualität. Ein Kontrast wurde da nie geprüft. Unten dieselbe Sache als Token: eine Definition, ein Abstandswert, und eine einzige Regel, die für alles gilt, was den Fokus über Tastatur erhält.

6:27 Ein Detail lohnt die Erwähnung — der Abstand zwischen Element und Indikator. Er hält den Rahmen vom Element ab, sodass er auch auf dunklem Grund oder auf einer farbigen Fläche sichtbar bleibt. Ein Pixel Abstand, und der Indikator funktioniert überall statt nur auf Weiß. Der erste Stolperstein ist berüchtigt: die Umrandung entfernen, weil sie im Entwurf stört, und den Ersatz der jeweiligen Komponente überlassen.

6:51 Der Ersatz kommt dann nie oder nur teilweise, und die Tastaturbedienung wird unsichtbar. Der zweite: Zielgrößen nicht als Token führen. Dann erfindet jede Komponente ihre eigene Mindesthöhe, und die Werte driften über die Zeit auseinander. Und der dritte ist eine Halbheit, die ich sehr oft sehe: Tokens nur für Farben anlegen und Abstände weiter frei wählen.

7:12 Dabei sind gerade Abstände das, was Konsistenz erzeugt — und was Hierarchie trägt, wie wir im letzten Modul gesehen haben.

Accessibility-Anforderungen auf Komponentenebene

7:20 Jetzt kommt eine kleine Liste mit großer Wirkung. Vier Zeilen je Komponente, und diese vier Zeilen sind gleichzeitig Spezifikation, Testgrundlage und — das wird in Modul achtzehn wichtig — der Kontext, den Sie einem Coding Agent übergeben. Die Idee ist bewusst minimal, damit sie tatsächlich gepflegt wird. Jede Komponente trägt vier Angaben: welche Rolle sie hat, welchen zugänglichen Namen sie braucht, welche Tasten sie bedient und welche Zustände sie meldet. Mehr nicht.

7:48 Der Reiz liegt in der Dreifachnutzung: Die Entwicklung baut danach, die Qualitätssicherung prüft danach, und wenn Sie später ein KI-Werkzeug beauftragen, ist genau diese Liste der Kontext, der aus einem vagen Auftrag eine überprüfbare Anforderung macht. Vier Zeilen, die Sie ohnehin einmal denken müssen — hier werden sie nur aufgeschrieben statt vergessen.

8:08 Am Beispiel der Sitzplatz-Komponente sehen Sie, wie konkret das wird. Die Rolle ist eine Auswahlbox, weil ein Sitzplatz an- und abgewählt wird — nicht etwa eine Schaltfläche. Der Name enthält Platznummer, Lage und Verfügbarkeit. Die Leertaste wählt ab und an, wie bei jeder Auswahlbox. Und die Zustände sind einzeln benannt samt Meldeweg.

8:28 Achten Sie besonders auf die letzte Zeile und die Fußnote: Die Belegung steht zusätzlich im zugänglichen Namen. Das ist genau die zweite Codierung aus Modul fünf — die Information darf nicht allein an der Farbe hängen, und sie darf auch nicht allein an einem technischen Zustand hängen. Der erste Stolperstein ist ein Bestandsproblem: die Liste nur für neue Komponenten führen und den Altbestand auslassen.

8:53 Dann prüft niemand die zwanzig Komponenten, die es schon gibt — und die werden am häufigsten benutzt. Arbeiten Sie sie nach, eine pro Woche reicht. Der zweite: Rolle und Name festlegen, das Tastaturverhalten aber offenlassen. Das ist die halbe Miete und der schwierigere Teil fehlt. Und der dritte ist subtil: Zustände beschreiben, ohne zu sagen, wie sie gemeldet werden. „Zeigt an, dass geladen wird" ist keine Spezifikation.

9:20 Über welches Attribut, für welche Technologie hörbar — das ist die Spezifikation.

Verhalten, Tastaturbedienung und Semantik dokumentieren

9:26 Weiter zur Dokumentation. Sie klingt nach Pflichtübung und ist in Wahrheit der Übertragungsweg des Wissens. Was hier nicht steht, wird nicht gebaut — und zwar nicht aus Nachlässigkeit, sondern aus Unkenntnis. Eine Komponentendokumentation, die nur Aussehen und Schnittstellenparameter zeigt, lädt zum Nachbauen von Barrieren ein.

9:46 Nehmen Sie ein konkretes Beispiel: Ein Dialog muss beim Schließen den Fokus dorthin zurückgeben, wo er herkam. Steht dieser Hinweis nicht in der Dokumentation, wird niemand es implementieren. Nicht, weil es zu aufwendig wäre — es sind drei Zeilen —, sondern weil es niemand weiß. Das ist der Punkt, den ich Ihnen hier ans Herz legen möchte: Dokumentation ist in diesem Feld kein Beiwerk und keine Nachbereitung.

10:10 Sie ist der einzige Weg, auf dem Verhaltenswissen die Personengrenze überquert. Vier Angaben, und die letzte ist die ungewöhnliche. Erstens die Tastenbelegung, vollständig und mit dem erwarteten Ergebnis — nicht nur „Tab funktioniert", sondern was jede Taste bewirkt. Zweitens, woher der zugängliche Name kommt und was passiert, wenn er fehlt; damit vermeiden Sie stille Namenslücken. Drittens die gemeldeten Zustände samt Attribut.

10:37 Und viertens ein Gegenbeispiel: die häufigste falsche Verwendung, ausdrücklich benannt. Das ist ungewöhnlich in Dokumentationen und ausgesprochen wirksam. Menschen erinnern sich an das, was schiefgeht, oft besser als an die Regel — und es beantwortet eine Frage, bevor sie gestellt wird. Der erste Stolperstein ist eine Kategorienfrage mit Folgen: nur die Parameter dokumentieren und das Verhalten als Implementierungsdetail führen.

11:03 Bei zugänglichen Komponenten ist das Verhalten aber die Komponente — das Aussehen ist der austauschbare Teil. Der zweite ist peinlich und häufig: Beispiele zeigen, die selbst die eigenen Regeln verletzen. Menschen kopieren das Beispiel, nicht den Fließtext. Und der dritte ist ein Ortsproblem: die Dokumentation im Entwurfswerkzeug pflegen, wo die Entwicklung sie nicht liest.

11:25 Legen Sie sie dahin, wo gearbeitet wird — in die Komponentenbibliothek selbst, direkt neben den Code.

Zusammenarbeit zwischen Design, Entwicklung und QA

11:32 Ein Design System ist ein soziales Konstrukt, bevor es ein technisches ist. Es lebt davon, dass drei Rollen dieselben Namen benutzen. Und die Abweichung davon passiert leise. Nehmen Sie ein alltägliches Beispiel: Im Entwurf heißt etwas „Hinweisfeld", im Code heißt dieselbe Sache „Alert". Zunächst passiert nichts — jeder weiß, was gemeint ist.

11:54 Aber jetzt sind es zwei Wahrheiten, und beim nächsten Umbau ändert jemand die eine und nicht die andere. Solche Abweichungen entstehen leise und werden erst sichtbar, wenn eine Änderung nur an einer Stelle ankommt. Das Gegenmittel ist unspektakulär und billig: ein gemeinsames Namensregister und ein fester Weg für Änderungswünsche.

12:13 Das ist keine Bürokratie, das ist die Grundvoraussetzung dafür, dass drei Rollen an einer Sache arbeiten können. Fünf Schritte, und Schritt eins entscheidet über die Qualität aller weiteren: Beschreiben Sie den Wunsch am Anwendungsfall, nicht als Lösung. „Wir brauchen einen grünen Knopf" ist eine Lösung; „Wir müssen die bestätigende Aktion von der abbrechenden unterscheiden" ist ein Fall — und dafür gibt es womöglich längst eine Komponente.

12:40 Genau das prüft Schritt zwei. Schritt drei ist der eigentliche Entscheidungspunkt: Variante, neue Komponente oder Einzelfall im Produkt. Und ja — ein Einzelfall darf ein Einzelfall bleiben. Nicht alles muss ins System. Bei Variante oder Komponente schreiben Sie die Vier-Zeilen-Regel gleich mit, sonst wird sie nie nachgetragen.

12:59 Der erste Stolperstein ist das Gegenteil von Sparsamkeit: jeden Wunsch zur Komponente machen. Das System bläht sich auf, die Suche wird länger, und irgendwann baut jeder wieder selbst, weil Suchen teurer ist als Bauen. Der zweite ist ein Vertrauensproblem: Änderungen ohne Ankündigung ausliefern. Ein Design System ist eine Abhängigkeit; wer sie überraschend ändert, wird umgangen.

13:23 Und der dritte ist der eingangs beschriebene Doppelname — einer im Entwurf, einer im Code. Er kostet zunächst nichts und irgendwann viel. Ein gemeinsames Register kostet eine Tabelle.

Kriterien für die Auswahl von Komponentenbibliotheken

13:34 Das letzte inhaltliche Kapitel betrifft eine Entscheidung, die viele Teams in einer Stunde treffen und fünf Jahre lang tragen: die Wahl einer fremden Komponentenbibliothek. Bei fremden Bibliotheken zählen vier Fragen mehr als der Funktionsumfang. Sind die Komponenten tastaturbedienbar? Gibt es dokumentierte Semantik? Wie stabil ist die Pflege?

13:55 Und wie leicht lassen sich Tokens überschreiben? Der harte Satz dazu lautet: Eine Bibliothek mit Barrierefreiheitslücken erbt man vollständig — samt Wartungslast. Und man merkt es meist erst nach der Einführung, wenn hundert Stellen darauf aufbauen. Dann haben Sie die Wahl zwischen einer Migration und dem Nachpflegen fremder Fehler.

14:15 Beides ist teuer. Eine Stunde Prüfung vorher ist die mit Abstand billigste Variante — und die nächste Folie zeigt, wie diese Stunde aussieht. Der Trick liegt in Schritt eins: Nehmen Sie nicht den Knopf, sondern die drei anspruchsvollsten Komponenten — Dialog, Combobox und Datentabelle. Wer die sauber gebaut hat, hat sich Mühe gegeben; wer dort schwächelt, schwächelt überall. Dann bedienen Sie jede nur mit der Tastatur und notieren Abweichungen.

14:42 Im dritten Schritt sehen Sie im Accessibility Tree nach, ob Rolle, Name und Zustand ankommen — dazu kommt Modul fünfzehn. Schritt vier ist eine Fünf-Minuten-Recherche mit großem Aussagewert: Wie viele offene Accessibility-Meldungen liegen im Projekt, und wie alt sind sie? Und Schritt fünf misst die Anpassbarkeit, indem Sie einfach einen Token überschreiben.

15:03 Der erste Stolperstein ist der bequemste: nach Funktionsumfang und Beliebtheitspunkten auswählen statt nach Bedienbarkeit. Sterne messen Popularität, nicht Qualität — und schon gar nicht Zugänglichkeit. Der zweite ist ein methodischer: die Demoseite prüfen statt der Komponenten im eigenen Aufbau. Demoseiten sind poliert; in Ihrem Aufbau kommen eigene Stile, ein eigener Fokus-Token und ein anderes Umfeld dazu.

15:28 Und der dritte: auf das Versprechen im Marketingtext vertrauen, ohne es nachzustellen. „Barrierefrei" steht in fast jeder Bibliotheksbeschreibung. Was das im Einzelfall bedeutet, sehen Sie in fünfzehn Minuten mit der Tastatur — und dann wissen Sie es wirklich.

Übung — eine Komponente vollständig spezifizieren

15:44 Zum Abschluss von Tag eins spezifizieren Sie eine Komponente — und geben sie dann aus der Hand. Der Tausch mit einer anderen Gruppe ist dabei die eigentliche Prüfung Ihrer Arbeit. Sie spezifizieren die Sitzplatzauswahl des Kompass-Systems, und zwar so vollständig, dass Semantik und Tastaturbedienung ohne Rückfragen umsetzbar sind.

16:03 Erfolgreich sind Sie, wenn eine andere Gruppe daraus bauen kann, ohne nachzufragen, und wenn alle Zustände mit ihrem Meldeweg benannt sind. Der Tausch ist dabei kein Nettigkeitsritual, sondern die Messung: Jede Rückfrage ist ein Befund, keine Störung — und sie zeigt Ihnen präzise eine Lücke, die Sie selbst nicht sehen konnten, weil Sie das Fehlende ja im Kopf hatten.

16:24 Wer früh fertig ist, ergänzt das Gegenbeispiel: die häufigste falsche Verwendung, ausdrücklich benannt. Beachten Sie die Reihenfolge im ersten Schritt: Zustände und Varianten auflisten, bevor irgendetwas gezeichnet wird. Das ist gegen den Instinkt und deshalb der Kern der Übung. Dann Rolle, zugänglicher Name und Tastenbelegung. Dann für jeden Zustand der Meldeweg — nicht nur, dass er existiert, sondern über welches Attribut er nach außen dringt.

16:51 Schritt vier ist der, der in echten Spezifikationen am häufigsten fehlt: das Fehlerverhalten. Was passiert bei einem belegten Platz, was bei einer verlorenen Reservierung? Und dann tauschen Sie und schreiben jede Rückfrage mit. Diese Liste ist Ihr Ergebnis. Der erste Stolperstein ist der Reflex, gegen den Schritt eins gebaut ist: mit dem Aussehen beginnen und die Zustände daraus ableiten.

17:15 Dann finden Sie genau die Zustände, die man sehen kann — und der Fokuszustand und der Ladezustand fallen wieder durch. Der zweite: den zugänglichen Namen als bloße Beschriftung führen, ohne die Belegung zu nennen. Dann ist Platz vierzehn A eben Platz vierzehn A, ob frei oder belegt. Und der dritte macht die Übung kaputt: Rückfragen mündlich beantworten, statt die Spezifikation zu ergänzen.

17:38 Die mündliche Antwort löst das Gespräch und nicht das Dokument — und das Dokument ist das, was bleibt. Vier Punkte, und damit endet Tag eins. Tokens, Komponenten und Patterns ändern sich unterschiedlich oft — genau das trennt sie voneinander und sortiert im Zweifel richtig ein. Der Fokusindikator gehört als Token gesetzt, sonst fehlt er in jeder zweiten Komponente. Vier Zeilen je Komponente reichen: Rolle, Name, Tasten, Zustände.

18:05 Und Bibliotheken wählt man nach Bedienbarkeit aus, nicht nach Funktionsumfang. Morgen beginnt Tag zwei, und der prüft genau das nach, was ohne diese Festlegungen einzeln repariert werden müsste. Wir starten mit dem rechtlichen Rahmen — mit den Standards, an denen später gemessen wird.