Formular-Design-System

Was macht Formular-Design-System?

Zweck

Die Fähigkeit "Formular-Design-System" bietet eine Methodik zur Gestaltung des visuellen und räumlichen Rahmens von Webformularen. Während die technische Implementierung das "Wie" behandelt und die Optimierung des Wachstums das "Warum", definiert das Designsystem das "Was" und "Wo". Es stellt sicher, dass Formularelemente – Labels, Eingabefelder, Auswahlmöglichkeiten und Aktionen – in einer vorhersagbaren, zugänglichen und vertrauenswürdigen Oberfläche organisiert sind, die die kognitive Belastung reduziert und Benutzerfehler verhindert.

Anwendungsfälle

• Entwerfen einer UI-Kit- oder Designsystem-Komponentenbibliothek für Formulare.
• Festlegen visueller Standards für komplexe, mehrstufige Dateneingabeschnittstellen.
• Überprüfung bestehender Formulare auf visuelle Inkonsistenzen oder räumliche Reibungen.
• Entwerfen responsiver Formularlayouts, die die Hierarchie über Geräte hinweg beibehalten.
• Standardisieren von Fehler- und Validierungsvisualisierungsmustern.

Wann NICHT zu verwenden

• Allgemeine Suchleisten: Einfache, einzelne Suchfelder benötigen selten die volle Behandlung des Designsystems.
• Experimentelle interaktive Medien: Bei denen die formularähnliche Interaktion sekundär zu einer narrativen oder künstlerischen Erfahrung ist.
• Low-Stakes-Mikrointeraktionen: Wie ein "Daumen hoch/Daumen runter" oder ein einfacher Schalter ohne begleitende Dateneingabe.

Eingaben

1. Informationsanatomie: Die spezifischen zu erfassenden Datenpunkte und ihre Beziehungen.
2. Geräte-Breakpoints: Responsive Anforderungen aus dem responsive-grid-system.
3. Markenstile: Typografieskalen, Farbschemata und Abstands-Tokens (aus dem fluid-spacing-system).
4. Interaktionsanforderungen: Ob das Formular Echtzeitvalidierung, Datei-Uploads oder komplexe Auswahlmöglichkeiten erfordert.

Ausgaben

1. Spezifikation der Eingabeanatomie: Visuelle Definitionen für Labels, Eingabefelder, Hilfetexte, Symbole und Fehlermeldungen.
2. Layout-Blueprint: Räumliche Regeln für Feldgruppierung, Ausrichtung (oben vs. links) und Aktionsplatzierung.
3. Zuordnung der Auswahlkomponenten: Definitionen, wann Radio, Checkbox, Switch oder Select verwendet werden.
4. Feedback- und Zustandsmatrix: Visuelle Behandlungen für Hover-, Fokus-, Deaktiviert-, Erfolgs- und Fehlerzustände.

Arbeitsablauf

1. Komponentenanatomie definieren

Etablieren Sie eine konsistente Struktur für jede "Feldgruppe". Ein Feld sollte bestehen aus:

• Das Label: Klarer, prägnanter Text, der das Feld identifiziert.
• Die Eingabe: Der interaktive Container (Text, Select usw.).
• Hilfe-/Anleitungstext: Dauerhafte Anleitung (z. B. "Passwort muss 8 Zeichen lang sein").
• Fehlermeldung: Kontextbezogenes Feedback, das nur erscheint, wenn die Validierung fehlschlägt.

2. Räumliches Layout und Ausrichtung festlegen

Bestimmen Sie die Beziehung zwischen Labels und Eingaben:

• Oben ausgerichtete Labels (empfohlen): Am besten für die Scanbarkeit und mobile Reaktionsfähigkeit.
• Links ausgerichtete Labels: Nur für datenintensive Desktop-Oberflächen, bei denen vertikaler Platz kritisch ist.
• Gruppierung: Verwenden Sie logische Abstände (z. B. --space-l) zwischen Gruppen und kleinere Abstände (z. B. --space-s) innerhalb von Gruppen.

3. Interaktionsmuster auswählen

Weisen Sie UI-Muster Datentypen zu:

• Binäre Entscheidungen: Verwenden Sie Checkboxen für "Ja/Nein" oder Mehrfachauswahl.
• Gegenseitige Ausschließlichkeit: Verwenden Sie Radio-Buttons für 2–5 Optionen; verwenden Sie Select für 6+ Optionen.
• Sofortige Schalter: Verwenden Sie Switches für Einstellungen, die ohne eine "Absenden"-Aktion sofort wirksam werden.

4. Die Feedback-Schleife entwerfen

Erstellen Sie eine visuelle Hierarchie für die Validierung:

• Fokus-Zustand: Verwenden Sie einen kontrastreichen Ring, um das aktive Feld anzuzeigen.
• Fehlerzustand: Verwenden Sie Farbe (normalerweise Rot), Symbole und Rahmendicke, um Fehler zu signalisieren.
• Erfolgszustand: Verwenden Sie subtile Hinweise (wie ein grünes Häkchen) für kritische Felder (z. B. Verfügbarkeit des Benutzernamens).

5. Responsive Anpassungen planen

Kartieren Sie, wie das Formular auf kleineren Bildschirmen überlebt:

• Stapeln: Mehrspaltige Layouts auf dem Desktop müssen auf Mobilgeräten zu einer einzigen Spalte gestapelt werden.
• Touch-Ziele: Stellen Sie sicher, dass alle interaktiven Zonen (Radios, Checkboxen, Buttons) mindestens 24 x 24 Pixel groß sind (WCAG 2.2 SC 2.5.8 Minimum); 44 x 44 Pixel sind bevorzugt und sollten die Standardgröße für primäre Absendeaktionen sein.

Entscheidungsregeln

• Die Einzelspaltenregel: Verwenden Sie ein einspaltiges Layout für die Mehrheit der Formulare, um einen klaren vertikalen Scanpfad beizubehalten und die Ermüdung durch Augenbewegungen zu verringern.
• Label-Ausrichtung: Standardmäßig oben ausgerichtete Labels. Sie reduzieren die Anzahl der Augenfixierungen, die zum Verarbeiten des Formulars erforderlich sind.
• Platzhalter vs. Labels: Verwenden Sie Platzhalter niemals als Labels. Labels müssen auch dann sichtbar bleiben, wenn der Benutzer mit der Eingabe begonnen hat.
• Button-Hierarchie: Die primäre "Absenden"-Aktion sollte die optisch auffälligste sein. Sekundäre Aktionen (z. B. "Abbrechen") sollten Textlinks oder kontrastarme Buttons sein.
• Nähe: Platzieren Sie Hilfetexte und Fehlermeldungen so nah wie möglich an der Eingabe (normalerweise direkt darunter).

Einschränkungen

• Barrierefreiheit: Labels müssen programmatisch mit Eingaben verknüpft sein (<label for> oder Wrapping). Kontrastverhältnisse für Text und Rahmen müssen WCAG AA erfüllen (4,5:1 für Text, 3:1 für UI-Komponenten). Fehlermeldungen müssen programmatisch mit ihrer Eingabe über aria-describedby verknüpft sein, und ungültige Felder müssen aria-invalid="true" setzen. Fokusindikatoren dürfen nicht hinter klebrigen Kopfzeilen, Toasts oder Overlays verborgen werden (WCAG 2.4.11 Focus Not Obscured).
• Reaktionsfähigkeit: Formularfelder dürfen niemals ihren Container überlaufen oder feste Breiten haben, die mobile Viewports überschreiten.
• Visuelle Hierarchie: Fehlermeldungen müssen sich visuell von Hilfetexten unterscheiden, um sicherzustellen, dass sie nicht übersehen werden.

Häufige Fehlermuster

• Die "Platzhalter-Label"-Falle: Verwenden von Platzhaltern anstelle von Labels, wodurch Benutzer beim Tippen den Kontext verlieren.
• Überwältigende Spalten: Verwenden von mehrspaltigen Layouts, die den natürlichen vertikalen Scanpfad des Benutzers verwirren.
• Vage Fehler: Visualisieren eines Fehlers nur mit Farbe (z. B. nur den Rahmen rot färben) ohne Symbol oder Textnachricht.
• Kleine Touch-Ziele: Entwerfen von Radios oder Checkboxen, die für die Daumeninteraktion auf Mobilgeräten zu klein sind.
• Der "unsichtbare" Fokus: Keinen klaren Fokusring bereitstellen, was die Navigation für Tastaturbenutzer unmöglich macht.

Validierungskriterien

• Jede Eingabe hat ein dauerhaftes, sichtbares Label.
• Das Formular folgt einem logischen, einspaltigen vertikalen Scanpfad.
• Fehlerzustände verwenden eine Kombination aus Farbe, Symbolen und Text.
• Fokusindikatoren sind kontrastreich und deutlich sichtbar.
• Interaktive Elemente (Eingaben, Buttons) erfüllen das WCAG 2.2 24x24 Pixel Touch-Ziel-Minimum (44x44 Pixel bevorzugt).
• Das Layout geht auf mobilen Viewports nahtlos in eine einzige Spalte über.
• Primäre, sekundäre und tertiäre Aktionen haben eine klare visuelle Hierarchie.