6. UI/UX-Design und Designsystem

UI/UX-Design und Designsystem

Öffnen Sie eine Anwendung, die über ein Jahr von mehreren Personen gebaut wurde, und Sie finden fünf Blautöne, drei Arten von Schaltflächen, vier Abstandsmaße und zwei Schriftgrößen, die sich um ein Pixel unterscheiden. Niemand hat das entschieden. Es ist entstanden, weil jede Ansicht an einem anderen Tag von einem anderen Menschen unter anderem Zeitdruck gebaut wurde.

Im Vorjahr ging es darum, ob eine einzelne Ansicht bedienbar ist. Diese zwei Wochen behandeln die Stufe darüber: Konsistenz über ein ganzes System und über mehrere Zielplattformen. Ein Designsystem ist dafür das Werkzeug, und es ist im Kern nichts Ästhetisches. Es ist eine Sammlung von Entscheidungen, die einmal getroffen und danach nur noch verwendet werden.

Die Gestaltung im engeren Sinn, also Farbklang, Bildsprache und Typografie als Ausdrucksmittel, bleibt Sache der Medientechnik. Hier geht es um Systematik, Umsetzung und Nachweis.

Gestaltungstoken

Zwei Ebenen

Ein Token ist ein benannter Gestaltungswert. Der Anfängerfehler ist, nur eine Ebene anzulegen, also blue-600 überall dort zu verwenden, wo etwas blau sein soll. Sobald das dunkle Erscheinungsbild dazukommt oder der Auftraggeber die Hausfarbe ändert, sucht man 200 Stellen zusammen.

Deshalb zwei Ebenen: Basiswerte halten die rohen Farben, semantische Namen sagen, wofür sie stehen.

:root {
  /* Level 1: base values */
  --blue-600: #1d4ed8;
  --gray-050: #fafafa;
  --gray-900: #18181b;
  --red-600:  #dc2626;

  /* Level 2: meaning */
  --color-action:      var(--blue-600);
  --color-danger:      var(--red-600);
  --surface-background: var(--gray-050);
  --surface-raised:     #ffffff;
  --text-strong:        var(--gray-900);

  /* Spacing: one scale, no arbitrary numbers */
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-3: 0.75rem;
  --space-4: 1rem;
  --space-6: 1.5rem;
  --space-8: 2rem;

  --radius-sm: 0.25rem;
  --radius-lg: 0.75rem;
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-action:       #60a5fa;   /* lighter, so the contrast holds */
    --surface-background: var(--gray-900);
    --surface-raised:     #27272a;
    --text-strong:        var(--gray-050);
  }
}

Im Code steht danach var(--color-action) und nie eine Farbe. Der Test, ob Ihr System trägt: Ändern Sie die Hausfarbe an einer Stelle und sehen Sie nach, ob die ganze Anwendung mitgeht.

Dunkles Erscheinungsbild

Farben umzudrehen ergibt matschige Ergebnisse. Ein dunkles Erscheinungsbild braucht eigene Werte: Aktionsfarben werden heller, sonst reicht der Kontrast nicht; große Flächen werden nicht reines Schwarz, sondern dunkles Grau; und Erhebung wird über hellere Flächen dargestellt statt über Schatten, weil Schatten auf Dunkel nicht sichtbar sind.

Kontrast gehört ins Token

Prüfen Sie jedes Paar aus Text und Fläche, sobald Sie es festlegen: 4,5:1 für normalen Text, 3:1 für großen Text und für Bedienelemente und deren Umrisse. Ein Token, das durchfällt, wird im Token korrigiert, nicht in dreißig Komponenten.

Typografie und Raster

Eine Skala statt beliebiger Größen, etwa mit dem Faktor 1,25 zwischen den Stufen, dazu Zeilenhöhen, die zur Größe passen. Für die Fläche ein Raster mit wenigen Spaltenzahlen und ein Abstandssystem, das auf einem Grundmaß aufbaut. Wer Abstände frei wählt, bekommt 13, 14 und 15 Pixel im selben Bildschirm.

Komponentenbibliothek

Zustände gehören zur Komponente

Zustand	Wird gebraucht bei	Wird meistens vergessen
Normal	immer	nein
Überfahren	Maus	nein
Fokus	Tastatur	ja
Aktiv	während des Drucks	nein
Deaktiviert	Aktion nicht möglich	teilweise
Ladend	Aktion läuft	ja
Fehler	Eingabe ungültig	ja

Eine Schaltfläche ohne Fokus- und Ladezustand ist eine halbe Komponente. Der Ladezustand ist dabei nicht nur Zierde: Ohne ihn drückt der Benutzer zweimal, und Sie brauchen den Idempotency-Key aus dem Vorjahr.

Dazu kommen Varianten mit klarer Bedeutung (primär, sekundär, gefährlich) und Zusammensetzbarkeit: Eine Komponente, die Inhalte aufnimmt, ist besser als eine mit zwanzig Eigenschaften für jeden denkbaren Sonderfall.

Dokumentation als lebende Referenz

Eine Komponentenbibliothek, die nur im Code existiert, wird nicht verwendet, weil niemand weiß, was es gibt. Ein Werkzeug wie Storybook zeigt jede Komponente in allen Varianten und Zuständen, isoliert und ausprobierbar. Der praktische Nutzen ist dreifach: Das Team sieht den Bestand, Zustände lassen sich testen, ohne sie in der Anwendung herbeizuführen, und die Barrierefreiheitsprüfung läuft je Komponente statt je Bildschirm.

Fertige Bibliothek oder Eigenbau

Weg	Vorteil	Preis
Unstilisierte Bausteine (Radix, React Aria)	Tastatur, Fokus und ARIA sind gelöst, Aussehen bleibt Ihres	Sie gestalten alles selbst
Bausteine mit Vorlagen (shadcn/ui)	Code liegt in Ihrem Projekt und ist anpassbar	Aktualisierungen liegen bei Ihnen
Vollständiges Designsystem (Material, Fluent)	schnell fertig, in sich stimmig	Ihre Anwendung sieht aus wie alle anderen
Eigenbau	volle Kontrolle	Sie bauen Dialoge und Kombinationsfelder selbst

Die Empfehlung für ein Maturaprojekt sind unstilisierte Bausteine mit eigenen Token. Der Grund steht weiter unten im Abschnitt über Barrierefreiheit: Fokusverwaltung, Tastaturbedienung und ARIA-Auszeichnung eines Dialogs oder eines Kombinationsfelds korrekt zu bauen kostet Wochen, und die Fehler dabei fallen erst beim Test mit Hilfstechnologie auf.

Wie immer gilt: Die Wahl kommt mit Begründung nach docs/entscheidungen.md.

Abläufe entwerfen

Die Nutzerreise

Nehmen Sie die wichtigste Aufgabe Ihres Projekts und schreiben Sie sie als Reise auf, Schritt für Schritt, aus der Sicht der Person und nicht der Anwendung.

Schritt	Was die Person will	Was das System zeigt	Reibung
Einstieg	„Kann ich am Freitag?”	Startseite mit Suche	Suche unten, wird übersehen
Auswahl	„Welche Maschine passt?”	Liste mit Bildern	keine Angabe zur Verfügbarkeit
Buchung	„Zwei Stunden reichen”	Formular mit Datum und Zeit	Datumsauswahl mobil unbrauchbar
Bestätigung	„Hat es geklappt?”	Meldung und Mail	Meldung verschwindet nach 3 Sekunden

Die letzte Spalte ist der Ertrag dieser Übung. Sie entsteht, indem Sie die Reise selbst durchgehen und aufschreiben, wo Sie stocken.

Architektur und Navigation

Wo etwas steht, entscheidet darüber, ob es gefunden wird. Zwei Regeln tragen weit: flach vor tief, weil jede zusätzliche Ebene Benutzer kostet, und Benennung aus der Sprache der Benutzer, nicht aus der Datenbank. Ein Menüpunkt „Entitäten” ist im Datenmodell korrekt und in der Oberfläche unbrauchbar.

Ob Ihre Einteilung trägt, lässt sich mit wenig Aufwand prüfen: Schreiben Sie die Inhalte Ihres Projekts auf Karten und lassen Sie drei Personen sie zu Gruppen ordnen und benennen. Wo alle drei gleich sortieren, stimmt Ihre Struktur; wo jede etwas anderes tut, stimmt Ihre Benennung nicht.

Das Navigationsmuster folgt dem Umfang: eine Leiste oben bei wenigen Bereichen, ein Seitenmenü ab etwa acht, eine Suche, sobald der Bestand größer wird als das Menü.

Für mehrschrittige Abläufe gelten drei Punkte: Der Fortschritt ist sichtbar, Zurück ist erlaubt und verliert nichts, und ein Abbruch nach dem dritten Schritt darf die ersten beiden nicht wegwerfen. Der technische Unterbau dafür stammt aus dem Formularkapitel des Vorjahres, die Entscheidung darüber, wie viele Schritte es überhaupt gibt, fällt hier.

Prototypen in passender Treue

Stufe	Werkzeug	Beantwortet die Frage
Skizze auf Papier	Stift	Stimmt die Reihenfolge der Schritte?
Klickbarer Entwurf	Figma, Penpot	Finden Leute den Weg?
Umsetzung im Code	Ihr Designsystem	Funktioniert es mit echten Daten?

Die Regel: Je teurer die Änderung wird, desto früher soll der Fehler auffallen. Eine falsche Schrittreihenfolge auf Papier zu bemerken kostet zwei Minuten, dieselbe Erkenntnis nach der Umsetzung kostet zwei Tage. Umgekehrt lohnt sich ein hochauflösender Entwurf selten, wenn Sie das Designsystem ohnehin schon haben.

Sprache gehört zum Entwurf

Beschriftungen, Fehlermeldungen, Leerzustände und Bestätigungen sind Teil der Bedienung, nicht Dekoration. Schaltflächen bekommen Verben, die die Handlung benennen, also „Buchung anlegen” statt „OK”. Bestätigungsdialoge nennen die Folge, also „Buchung am 27. Juni löschen?” statt „Sind Sie sicher?”.

Diese Texte gehören in das Designsystem und nicht in die einzelne Ansicht, sonst heißt dieselbe Sache an drei Stellen anders. Bei mehrsprachigen Projekten sind es dieselben Schlüssel aus dem i18n-Kapitel des Vorjahres.

Prüfen mit echten Personen

Das Verfahren kennen Sie aus dem Vorjahr: Aufgaben statt Fragen, lautes Denken, beobachten und nicht helfen. Neu sind hier drei Dinge.

Fünf Personen und ein Nachtest. Fünf Personen decken den Großteil der Probleme auf. Wichtiger als eine sechste ist der zweite Durchgang nach den Änderungen, weil er zeigt, ob die Behebung wirkt. Ohne Nachtest optimieren Sie ins Blaue.

Befunde führen zu Änderungen, die sich benennen lassen. Aus „drei von fünf haben die Suche nicht gefunden” wird eine konkrete Maßnahme mit Datum und verantwortlicher Person, kein Eintrag in einer Wunschliste.

Findet sich niemand zum Testen, bleibt der kognitive Durchgang aus dem Vorjahr: dieselben Schritte am Schreibtisch, mit den drei Fragen je Station. Er ersetzt den Test nicht, weil Sie Ihr eigenes Vorwissen nicht abschalten können, aber er ist jederzeit machbar.

Zahlen ergänzen Beobachtung, ersetzen sie nicht. Nutzungsdaten zeigen, dass die Hälfte der Leute im dritten Schritt abbricht; der Test zeigt, warum. Und beides gilt nur mit der Grundlage aus Kapitel 4: Reichweitenmessung braucht eine Einwilligung, ein A/B-Vergleich mit Personenbezug ebenso. Bei Ihren Nutzerzahlen ist ein A/B-Vergleich ohnehin selten aussagekräftig, dafür fehlt schlicht die Menge.

Barrierefreiheit, vertieft

Das Mindestmaß aus dem Vorjahr, also Tastatur, Fokus, Kontrast, Alternativtexte und semantisches HTML, wird hier vorausgesetzt. Jetzt kommen die Kriterien dazu, an denen Anwendungen scheitern, im Unterschied zu Websites.

Fokusverwaltung

Der häufigste schwere Befund in Webanwendungen. Sobald etwas erscheint oder verschwindet, muss der Fokus mitkommen.

Ein modaler Dialog braucht vier Dinge: Der Fokus springt beim Öffnen hinein, er bleibt darin gefangen, solange der Dialog offen ist, Escape schließt, und beim Schließen kehrt der Fokus auf das auslösende Element zurück. Das native dialog-Element mit showModal() bringt das mit; eine Nachbildung aus div-Elementen bringt es nicht.

Dieselbe Frage stellt sich nach jedem Schrittwechsel, nach dem Absenden eines Formulars und nach dem Löschen einer Zeile: Wo steht der Fokus jetzt? Wenn die Antwort „am Seitenanfang” oder „nirgends” lautet, ist der Weg mit der Tastatur unterbrochen.

Dynamische Meldungen

Eine Meldung, die eingeblendet wird, sieht ein Screenreader-Benutzer nicht. Sie muss angesagt werden:

<!-- Search results: unobtrusive, after the current output -->
<div role="status" aria-live="polite">
  14 machines found
</div>

<!-- Error on submit: interrupts -->
<div role="alert">
  The booking could not be saved.
</div>

Der Bereich muss beim Laden der Seite bereits vorhanden sein und wird danach befüllt. Ein Element, das gemeinsam mit seinem Text ins Dokument kommt, wird oft nicht angesagt.

Komplexe Bedienelemente

Kalender, Kombinationsfelder, Registerkarten, Baumansichten und sortierbare Tabellen haben festgelegte Tastaturmuster, die Benutzer erwarten: Pfeiltasten innerhalb, Tab hinein und hinaus, Home und End an die Enden, Escape zum Schließen. Diese Muster sind in den ARIA Authoring Practices beschrieben, und sie nachzubauen ist Fleißarbeit mit vielen Fallstricken.

Die Reihenfolge lautet deshalb: natives Element, sonst eine geprüfte Bibliothek, und erst als letztes Eigenbau. Eine sortierbare Tabelle braucht zusätzlich caption, th mit scope und aria-sort auf der aktiven Spalte.

Was WCAG 2.2 ergänzt hat

Kriterium	Heißt praktisch
Fokus nicht verdeckt	Das fokussierte Element darf nicht unter einer klebenden Kopfleiste liegen
Zielgröße mindestens 24 mal 24	Kleine Symbolschaltflächen brauchen Fläche oder Abstand
Alternative zum Ziehen	Was per Ziehen geht, muss auch per Klick gehen
Konsistente Hilfe	Der Kontaktweg steht überall an derselben Stelle
Zugängliche Anmeldung	Kein Gedächtnistest; Einfügen in Passwortfelder muss erlaubt sein

Die letzte Zeile ist die, die Entwickler regelmäßig selbst verursachen: Ein Passwortfeld, das Einfügen unterbindet, verhindert die Nutzung eines Passwortspeichers, macht Passwörter also schlechter und verstößt zusätzlich gegen dieses Kriterium.

Weitere Prüfungen von Hand

• Bewegung reduzieren: prefers-reduced-motion beachten und Animationen abschalten, statt sie nur zu verkürzen.
• Vergrößerung: 200 Prozent Zoom, und die Anwendung muss auf 320 Pixel Breite ohne waagrechtes Scrollen umbrechen.
• Screenreader: einen Hauptweg vollständig mit NVDA, Orca oder VoiceOver durchgehen.
• Nur Tastatur: dasselbe noch einmal ohne Maus.

Das Ziel ist WCAG 2.2 Stufe AA, mindestens auf den Hauptwegen. Der rechtliche Rahmen dazu steht in Kapitel 4; für die Bewertung in diesem Gegenstand zählt der Nachweis, nicht die Behauptung.

Konsistenz über Plattformen

In Kapitel 8 kommt die App dazu, im Web bleibt die Anwendung. Beide sollen erkennbar dasselbe Produkt sein, ohne sich auf der jeweiligen Plattform falsch anzufühlen.

Muss gleich bleiben	Darf sich unterscheiden
Begriffe und Beschriftungen	Navigationsmuster (Leiste unten gegen Seitenmenü)
Bedeutung der Farben	Eingabeelemente (native Datumsauswahl)
Reihenfolge der Schritte	Gesten und Zurück-Verhalten
Fehlerbehandlung und Meldungen	Schriftgrößen und Berührungsziele
Symbolsprache	Position der primären Aktion

Die Grundlage dafür sind Ihre Token: Wenn Farben, Abstände und Typografie als Werte vorliegen, lassen sie sich in die App übernehmen, während die Komponenten plattformgerecht anders gebaut sein dürfen. Wer Plattformkonventionen ignoriert und eine iOS-Oberfläche eins zu eins auf Android nachbaut, bekommt eine Anwendung, die sich überall leicht falsch anfühlt.

Häufige Stolperfallen

1. Designsystem als Farbtabelle ohne Komponenten und ohne Zustände.
2. Nur eine Token-Ebene, und beim dunklen Erscheinungsbild beginnt die Suche.
3. Dunkles Erscheinungsbild durch Umkehrung der Farben.
4. Kontrast erst am Ende geprüft, wenn die Farben schon überall stehen.
5. Komponenten ohne Fehler- und Ladezustand.
6. Eigene Widgets aus div-Elementen statt nativer Elemente oder geprüfter Bausteine.
7. Dialog ohne Fokusverwaltung. Mit der Tastatur landet man dahinter.
8. Meldungen, die nur sichtbar sind und nicht angesagt werden.
9. Usability-Test, bei dem die Entwicklerin die Bedienung erklärt.
10. Kein Nachtest, also kein Nachweis, dass die Änderung geholfen hat.
11. Barrierefreiheit mit einem automatischen Werkzeug abgehakt, das einen Bruchteil findet.
12. Einfügen im Passwortfeld gesperrt, in bester Absicht.

Lernergebnisse

• Erklären: begründen, warum Anwendungen ohne Designsystem auseinanderlaufen.
• Erschaffen: Gestaltungstoken auf zwei Ebenen anlegen, samt hellem und dunklem Erscheinungsbild und geprüften Kontrasten.
• Erschaffen: eine Komponentenbibliothek mit Varianten und allen Zuständen aufbauen und dokumentieren.
• Beurteilen: zwischen fertiger Bibliothek, unstilisierten Bausteinen und Eigenbau begründet wählen.
• Analysieren: eine Nutzerreise aufzeichnen und Reibungspunkte benennen.
• Anwenden: Prototypen in angemessener Treue erstellen und daraus die Umsetzung ableiten.
• Anwenden: einen Usability-Test mit fünf Personen durchführen, auswerten und die Wirkung im Nachtest belegen.
• Anwenden: Fokusverwaltung, Live-Bereiche und Tastaturmuster komplexer Bedienelemente korrekt umsetzen.
• Analysieren: die Anwendung gegen WCAG 2.2 Stufe AA prüfen, mit Werkzeug und mit Hilfstechnologie.
• Beurteilen: entscheiden, was über Plattformen gleich bleiben muss und was sich unterscheiden darf.

Arbeit am Jahresprojekt

• Designsystem in docs/designsystem.md und im Code: Token auf zwei Ebenen, Farben mit Kontrastnachweis, Typografie- und Abstandsskala, helles und dunkles Erscheinungsbild.
• Komponentenbibliothek mit mindestens acht Komponenten in allen Zuständen, dokumentiert und im Projekt tatsächlich verwendet.
• Alle Hauptansichten aus diesen Komponenten gebaut, keine Einzelfarben mehr im Code.
• Nutzerreise der wichtigsten Aufgabe, mit Reibungspunkten und daraus abgeleiteten Änderungen.
• Usability-Test mit fünf Personen: Aufgaben, Beobachtungen, Befunde mit Schweregrad, umgesetzte Änderungen, Nachtest.
• Barrierefreiheitsbericht: Werkzeugergebnis, Tastaturdurchgang, Screenreader-Durchgang eines Hauptwegs, Befundliste mit Behebung, Stand gegenüber WCAG 2.2 AA.

Passende Übungen

• Aufgabe - Token und Komponentenbibliothek aufsetzen
• Aufgabe - Usability-Test mit fünf Personen
• Aufgabe - Komplexes Widget barrierefrei umsetzen
• Aufgabe - Dunkles Erscheinungsbild systematisch