Der Formular-Kanon: Jedes Feld ist eine Frage

Ein Formular ist der Moment, in dem eine Oberfläche aufhört zu präsentieren und anfängt zu fragen. Jedes Feld ist eine Frage an einen Menschen, der eigentlich etwas anderes tun möchte; deshalb ist jedes überflüssige Feld eine Zumutung und jedes unklare ein kleiner Vertrauensbruch. Das Handwerk des Formulars lässt sich auf einen Kanon eindampfen, den man im Kopf behalten kann: weniger fragen, einspaltig, mit sichtbaren Beschriftungen; Antworten so annehmen, wie Menschen sie natürlicherweise geben; die Validierung auslösen, wenn ein Gedanke zu Ende gedacht ist, nicht mitten im Tastenanschlag; Fehlermeldungen schreiben, die sagen, wie sich das Problem beheben lässt; und unter keinen Umständen wegwerfen, was jemand eingetippt hat. Die meiste Formularreibung da draußen ist ein Verstoß gegen eine dieser Zeilen. {.answer-block}

TL;DR

• Ein Formular ist ein Gespräch, also fragen Sie so, wie ein Mensch fragen würde: so wenige Fragen wie möglich, in einer geordneten Spalte, nach Themen gruppiert – und jedes Feld muss sich gegen die Kosten des Fragens rechtfertigen.
• Das Layout ist geklärt: eine Spalte, Beschriftungen über dem Feld, Feldbreite als Hinweis auf die Länge der Antwort. Mehrspaltige Formulare und Floating-Label-Tricks tauschen echtes Verständnis gegen eingebildete Eleganz.
• Nehmen Sie Antworten so an, wie Menschen sie geben. Das versehentliche Leerzeichen abschneiden, die Telefonnummer in jedem Format akzeptieren, das Feld ganz lassen, statt es in drei Kästchen zu zerlegen – Normalisierung ist Aufgabe der Software, nicht der Nutzer.
• Validieren Sie beim Verlassen des Feldes, nicht beim Tastenanschlag, und schreiben Sie Fehlermeldungen, die weiterhelfen: was schiefging, wie es zu beheben ist, direkt neben dem betroffenen Feld.
• Die Eingabe der Nutzer ist heilig. Ein fehlgeschlagenes Absenden, das das Formular leert, oder ein deaktivierter Button, der nicht verrät, warum, macht aus einem willigen Teilnehmer einen ehemaligen.

Warum jedes Feld eine Frage ist

Betrachten Sie ein Formular als Mitschrift eines Interviews, und seine Qualität wird lesbar. Würde ein kompetenter Interviewer aus Gewohnheit nach Ihrer Faxnummer fragen? Ihr Geburtsdatum verlangen, bevor er erklärt, wozu? Sie mitten beim Buchstabieren Ihrer E-Mail-Adresse unterbrechen, um sie für ungültig zu erklären? Alles Gesagte vergessen, weil in Ihrer Postleitzahl ein Leerzeichen stand? Zu jedem dieser Fälle gibt es ein Gegenstück in produktiv laufenden Formularen, und Nutzer erleben sie genauso, wie sie den Interviewer erleben würden: als Unhöflichkeit.

Aus dieser Perspektive folgt auch die erste und wichtigste Regel, die allem Layout und aller Gestaltung vorausgeht: Jedes Feld muss seine Existenz gegen die Kosten des Fragens rechtfertigen. Jede zusätzliche Frage erhöht die Abbruchrate; jede erhobene Antwort ist ein Datum, das Sie fortan speichern, schützen und verantworten. Der stärkste Zug im Formulardesign ist das Löschen – das entfernte Feld schlägt jede Politur, die Sie ihm angedeihen lassen könnten. Der klassische Beleg stammt von Expedia: Das Streichen eines einzigen optionalen Feldes, „Company“, aus dem Buchungsformular war Berichten zufolge rund 12 Millionen Dollar im Jahr wert – Kunden hatten dort den Namen ihrer Bank eingetragen und scheiterten anschließend an der Adressprüfung. Ein Feld, ehrlich befragt, schlug jede Neugestaltung. „Optional“ ist keine Rechtfertigung; es ist eine kleinere Zumutung, aber immer noch eine. Fragen Sie, was die Transaktion braucht, kennzeichnen Sie das seltene optionale Feld als optional, und verschieben Sie alles Übrige auf später, wenn die Beziehung es verdient hat. (Das gegnerische Lager versieht stattdessen jedes Pflichtfeld mit einem Sternchen; wenn nahezu alles Pflicht ist, werden die Sternchen zur Tapete.)

Die Layout-Regeln

Formularlayout ist eine der wenigen Ecken des Designs, in denen die Befundlage im Wesentlichen geklärt ist – wer davon abweicht, entscheidet sich damit gegen den Nutzer:

Eine Spalte. Ein Formular ist eine Folge von Fragen, und eine einzige Spalte macht diese Folge eindeutig: antworten, weiter nach unten, fertig. Mehrspaltige Layouts erzwingen in jeder Zeile eine Entscheidung über die Lesereihenfolge – quer oder abwärts? –, und Nutzer lösen sie uneinheitlich auf und überspringen dabei Felder, die sie nie gesehen haben. Im bekanntesten Eyetracking-Vergleich waren dieselben Felder in einer Spalte rund fünfzehn Sekunden schneller ausgefüllt als auf zwei verteilt. Die Ausnahme bilden echte Verbundangaben, die sich als eine Antwort lesen: Ort / Bundesland / Postleitzahl in einer Zeile, ein Datum aus drei Teilen. Das ist eine Frage in drei Eingabefeldern, nicht drei Fragen.

Beschriftungen über dem Feld, immer sichtbar. Beschriftungen neben dem Feld erzeugen zerfranste Blickwege; Beschriftungen im Feld (Platzhalter als Beschriftung) verschwinden in dem Moment, in dem jemand zu tippen beginnt – also genau dann, wenn er sie braucht: Auf halber Strecke durch ein langes Formular wird jedes ausgefüllte Feld zur Wundertüte des Was-war-das-noch-mal. Floating Labels, der animierte Kompromiss, überleben zwar den Fokus, schrumpfen aber auf Bildunterschriftengröße und lassen leere Felder wie ausgefüllte wirken: dieselbe Rechnung in sanfter Form, bezahlt wird trotzdem mit Verständlichkeit. Platzhalter sind für Formathinweise da („[email protected]“), niemals für die Frage selbst.

Feldbreite ist Information. Ein Postleitzahlfeld, so breit wie ein Adressfeld, lügt über die Gestalt der Antwort. Eingabefelder auf ihren erwarteten Inhalt zu bemessen – kurz für Postleitzahlen, lang für Adressen – ist dasselbe Handwerk wie Abstände, die Gruppierung codieren: Geometrie, die leise kommuniziert.

Nach Themen gruppieren, und die Gruppierung dem Raum überlassen. Kontakt, Versand, Zahlung – Bündel verwandter Fragen mit klaren Nahtstellen dazwischen, und diese Nähte bestehen aus Weißraum statt aus Kästen oder Linien. Ein Formular, das sich als drei kleine Themen liest, ist psychologisch kleiner als dieselben Felder in einer undifferenzierten Platte.

Die Regeln für Eingaben

Das Thema des Eingabedesigns passt in einen Satz: Normalisierung ist Aufgabe der Software. Welche Formatierungslast auch anfällt, die Maschine trägt sie, denn die Maschine ist es, der das Format wichtig ist.

• Nehmen Sie schlampige Antworten an. Leerzeichen abschneiden – das angehängte Leerzeichen aus einer automatisch ausgefüllten E-Mail-Adresse hat mehr Logins scheitern lassen, als ihm zusteht. Telefonnummern mit Bindestrichen, Punkten, Leerzeichen, Klammern oder ganz ohne akzeptieren. Die Kartennummer mit oder ohne Lücken annehmen. Wenn Sie es parsen können, parsen Sie es; 555 867 5309 abzulehnen, weil Sie 5558675309 wollten, heißt, den Nutzer Ihren String-Formatierungscode von Hand ausführen zu lassen.
• Zerlegen Sie niemals, was für den Nutzer eine Sache ist. Telefonnummern in drei Kästchen, Datumsangaben in drei Dropdowns, Bestätigungscodes in sechs Ein-Zeichen-Zellen samt selbstgebautem Fokussprung – jede dieser Varianten zerlegt eine gedankliche Antwort in ein Navigationsrätsel und zerstört meist das Einfügen, die effizienteste Eingabemethode, die der Nutzer besitzt. (Die Verbund-Ausnahme aus den Layout-Regeln bleibt bestehen: ein Datum aus drei getippten Teilen ist in Ordnung – die Sünde ist das Dropdown-Zeremoniell und der geraubte Fokus, nicht die Nachbarschaft. Und für Codes lautet die haltbare Antwort: ein Eingabefeld mit autocomplete="one-time-code".)
• Rufen Sie die richtige Tastatur. Auf Touch-Geräten entscheiden type="email", inputmode="numeric" und Verwandte darüber, ob jemand eine Adresse auf einer dafür gebauten Tastatur tippt oder das @ durch Symbolebenen jagt. Das kostet ein Attribut.
• Lassen Sie den Browser helfen. Korrekte autocomplete-Werte verwandeln einen zwölffeldrigen Checkout für wiederkehrende Kunden in zwei Fingertipps. Autofill in Adress- und Zahlungsfeldern zu deaktivieren – meist Aberglaube aus einem Security-Review, das nie stattgefunden hat – verschenkt die größte einzelne Beschleunigung, die einem Formular zur Verfügung steht.
• Empfangen Sie den Finger dort, wo er landet. Felder, ihre Buttons und alles andere Antippbare halten das Mindest-Touchziel der Plattform ein – 44 pt unter iOS, 48 dp unter Android. Ein kompaktes, elegantes Feld, das der Daumen nicht zuverlässig trifft, ist ein Desktop-Formular im Handy-Kostüm.

Die Regeln zu Tastatur und Autofill kosten zusammen ein paar Attribute:

<input type="tel" autocomplete="tel">              <!-- phone keypad, autofilled -->
<input inputmode="numeric" autocomplete="one-time-code">  <!-- digit pad, code autofills -->

Die Regeln für Validierung

Beim Zeitpunkt der Validierung werden Formulare am häufigsten feindselig, und die Regel ist einfach: Antworten Sie, wenn der Nutzer einen Gedanken zu Ende gebracht hat. Bei jedem Tastenanschlag auszulösen heißt, jemandem nach vier Zeichen „ungültige E-Mail-Adresse!“ entgegenzurufen – Sätze zu kritisieren, bevor sie enden. Die Gegenschule validiert ausschließlich beim Absenden, und sie hat einen ernstzunehmenden Fürsprecher: Das Designsystem von GOV.UK macht genau das und kombiniert das Absenden mit einer Fehlerübersicht am Seitenanfang, weil eine Übersicht für Screenreader ansagbar ist und Tastaturnutzern einen einzigen Startpunkt für Korrekturen gibt. Das ist eine kohärente Position, abgestimmt auf Dienste, bei denen Barrierefreiheit die bindende Randbedingung ist. Für die meisten Produktformulare bleibe ich dennoch bei der Validierung beim Verlassen des Feldes: Der Nutzer füllt das Feld aus, geht weiter und bekommt sein Feedback an der Naht zwischen zwei Gedanken, solange der Gedanke noch warm ist. (Eine Verfeinerung: Ein Feld, das bereits als ungültig markiert war, darf bei jedem Tastenanschlag erneut prüfen, damit der rote Zustand in dem Augenblick verschwindet, in dem die Korrektur sitzt, statt ein ganzes Feld hinterherzuhinken.)

Das Schreiben von Fehlermeldungen besteht denselben Gesprächstest. Eine Fehlermeldung ist kein Urteil, sondern eine Reparaturanweisung. „Ungültige Eingabe“ fällt durch – inwiefern ungültig? „In dieser E-Mail-Adresse fehlt das @“ besteht. (Und die Anweisung muss der tatsächlichen Regel entsprechen: Kartennummern haben legitim 12 bis 19 Ziffern, „muss 16 Ziffern haben“ ist also keine Fehlermeldung, sondern ein Validierungsfehler, der jeden Amex-Inhaber abweist.) Platzieren Sie die Meldung an dem Feld, um das es geht, und zwar als Text – Farbe allein schließt farbenblinde Menschen aus, und Text ist der einzige Kanal, den ein Leser, der nichts rendert, sehen kann – und verknüpfen Sie sie programmatisch mit ihrem Eingabefeld (aria-describedby), damit assistive Technik den Fehler zusammen mit dem Feld ansagt, statt ihn auf dem Bildschirm stranden zu lassen. Halten Sie den Ton sachlich: Das Formular soll den Nutzer hindurchbringen, nicht Schuld zuweisen. Die ganze Regel in einem Paar:

<!-- before: a verdict, visually nearby, programmatically stranded -->
<label for="email">Email</label>
<input id="email" type="email">
<span class="error">Invalid input</span>

<!-- after: a repair instruction, announced with its field -->
<label for="email">Email</label>
<input id="email" type="email"
       aria-invalid="true" aria-describedby="email-err">
<span id="email-err">This email address is missing its @</span>

Zwei strukturelle Regeln vervollständigen den Satz. Deaktivieren Sie den Absenden-Button niemals als Validierungsstrategie – ein toter Button ohne Erklärung ist ein Rätsel, und der nächste Zug des Nutzers heißt Weggehen; lassen Sie ihn absenden und zeigen Sie dann genau, was Aufmerksamkeit braucht. (Ihn während eines laufenden Absendevorgangs zu deaktivieren, um eine doppelte Belastung zu verhindern, ist etwas anderes: Das ist Zustand, kein Urteil.) Und das tiefste Gesetz des Kanons: Ein fehlgeschlagenes Absenden bewahrt jeden Tastenanschlag der geleisteten Arbeit. Ein Formular, das bei einem Fehler leert, hat Minuten fremder Mühe genommen und sie vor den Augen ihres Urhebers verbrannt. Davon erholt sich keine visuelle Verfeinerung.

Der Kanon als Checkliste

Die Arbeitsform all dessen, anzulegen an jedes Formular, bevor es live geht:

In einem Designsystem härten diese Regeln in den Formularkomponenten selbst aus – ein Textfeld, das seinen Beschriftungs-Slot oben, seinen Fehler-Slot unten und sein Validierungstiming schon mitbringt –, sodass der Kanon standardmäßig gilt und erst das Abweichen Mühe kostet. Das ist dasselbe Systematisierungsargument wie bei Motion-Tokens: die Entscheidung einmal codieren oder sie in jedem Feature neu verhandeln.

Häufige Fragen

Sollte ein Formular eine oder zwei Spalten haben?

Eine Spalte. Eine einzige Spalte macht die Antwortreihenfolge eindeutig und ist messbar schneller auszufüllen; mehrspaltige Layouts führen zu übersprungenen Feldern, weil Nutzer die Lesereihenfolge uneinheitlich auflösen. Die Ausnahme ist eine Verbundangabe – Ort / Bundesland / Postleitzahl –, also eine Frage, ausgedrückt in benachbarten Eingabefeldern.

Wann sollte die Formularvalidierung auslösen?

Beim Verlassen des Feldes – also wenn der Nutzer es verlässt – und nicht bei jedem Tastenanschlag; für die meisten Produktformulare auch nicht aufgespart bis zum Absenden. Validierung pro Tastenanschlag kritisiert unfertige Antworten; Validierung nur beim Absenden liefert sämtliche Fehler auf einen Schlag, wobei die Fehlerübersicht von GOV.UK beim Absenden dort die richtige Wahl ist, wo die Ansage durch Screenreader die bindende Randbedingung ist. Ein bereits als ungültig markiertes Feld darf pro Tastenanschlag erneut prüfen, damit der Fehler sofort verschwindet, sobald er behoben ist.

Darf man Platzhaltertext als Feldbeschriftung verwenden?

Nein. Der Platzhalter als Beschriftung verschwindet, sobald jemand zu tippen beginnt – genau dann, wenn die Frage erinnert werden muss – und macht beim Prüfen aus jedem ausgefüllten Feld unbeschriftete Daten. Behalten Sie eine sichtbare Beschriftung über dem Feld und reservieren Sie Platzhalter für Formatbeispiele.

Sollte der Absenden-Button deaktiviert sein, bis das Formular gültig ist?

Nein. Ein deaktiviertes Absenden ohne Erklärung ist eine Sackgasse, die der Nutzer selbst diagnostizieren muss. Lassen Sie ihn aktiv, und legen Sie beim Absenden jedes ungelöste Feld mit einer konkreten, anleitenden Fehlermeldung daneben offen – und bewahren Sie dabei alles, was bereits eingegeben wurde.