Formulardesign: Regeln und Beispiele

Kurz gesagt

Ein Formular ist die Stelle, an der ein Produkt etwas vom Nutzer will. Registrierung, Zahlung, Antrag oder Kontakt: In den meisten Produkten passiert die eigentliche Arbeit auf diesen Screens.

An einem Formular schaue ich auf zwei Dinge: die Fragen und das, was passiert, wenn der Nutzer etwas falsch eingibt. Acht der 23 Regeln unten betreffen direkt Fehler.

Laut einem Artikel des Baymard Institute von 2024 haben 17 % der Nutzer den Checkout abgebrochen, weil er ihnen zu kompliziert war. Derselbe Artikel nennt für den durchschnittlichen Checkout 5,1 Schritte und 11,3 Felder.

Wann man das Muster nutzt

Das Muster gilt überall, wo Sie vom Nutzer schriftliche Angaben verlangen. Eine Newsletter-Anmeldung mit einem Feld ist ebenso ein Formular wie ein Kreditantrag mit zehn Schritten.

• Registrierung und Anmeldung. Wenige Felder, aber durch diese Tür betritt der Nutzer das Produkt.
• Zahlung und Adresse. Adresse und Kartendaten treiben die Zahl der Felder schnell nach oben.
• Anträge und Verwaltungsleistungen. Das GOV.UK Design System empfiehlt eine Frage pro Fragenseite. Die Begründung: So kann sich der Nutzer auf diese Frage und seine Antwort konzentrieren.
• Kontakt und Support. Hierher kommt der Nutzer meist mit einem Problem. Das Formular soll es nicht größer machen.

Bevor ich ein Formular baue, frage ich mich: Kann ich diese Angabe herausfinden, ohne den Nutzer zu fragen? Wenn ja, zeichne ich das Feld gar nicht erst. Die Reihenfolge der Felder lege ich zuerst auf Papier fest, mit einem groben Wireframe.

Regeln für das Formulardesign

Jede Regel ist ein Satz mit einer kurzen Begründung darunter. Wo eine Quelle dahintersteht, nenne ich sie; die vollständigen Angaben stehen am Ende der Seite.

1. Fragen Sie nur die Felder ab, die Sie wirklich brauchen. Kathryn Whitenton von NN/g rät, Felder zu streichen, die sich anders herausfinden lassen, die man später bequemer fragen kann oder die man gar nicht braucht. Laut Baymards Daten von 2024 hat der durchschnittliche Checkout 11,3 Felder. Die meisten Websites kämen mit 8 aus.
2. Ordnen Sie die Felder in einer Spalte an. Laut Whitenton unterbrechen mehrere Spalten den Weg nach unten durch das Formular. Kurze, zusammengehörige Felder wie PLZ und Ort dürfen sich eine Zeile teilen.
3. Gruppieren Sie zusammengehörige Felder und setzen Sie das Label nah an sein Feld. Whitenton verlangt, dass das Label nah an dem Feld steht, das es beschreibt. Steht es zwischen zwei Feldern, muss der Nutzer raten, zu welchem es gehört.
4. Schreiben Sie das Label über das Feld, außerhalb des Felds. Katie Sherwin von NN/g schreibt, die beste Lösung sei ein sichtbares Label außerhalb des leeren Felds.
5. Nutzen Sie Platzhaltertext nicht statt eines Labels. Laut GOV.UK verschwindet der Platzhalter, sobald der Nutzer zu tippen beginnt, und nicht jeder Screenreader liest ihn vor. Sherwin ergänzt, dass Nutzer ihn für einen bereits eingetragenen Wert halten und das Feld überspringen können.
6. Nennen Sie die Formatregel, bevor ein Fehler entsteht, außerhalb des Felds. Whitenton verlangt, dass die Anweisung vollständig dasteht, wenn ein Feld ein bestimmtes Format braucht. Passwortregeln sollen Nutzer nicht erraten müssen. Wer die Regel erst aus der Fehlermeldung erfährt, füllt dasselbe Feld zweimal aus.
7. Schreiben Sie das Label kurz und direkt, nur der Anfang großgeschrieben, wie es die Grammatik verlangt. GOV.UK sagt auch, dass kein Doppelpunkt ans Ende des Labels gehört. „E-Mail“ genügt, „Ihre E-Mail-Adresse:“ braucht es nicht.
8. Markieren Sie Pflichtfelder einzeln. Laut Raluca Budiu von NN/g wird der Hinweis „Alle Felder sind Pflichtfelder“ am Anfang des Formulars leicht übersehen. Sie empfiehlt, jedes Pflichtfeld zu markieren, und schreibt, dass ein Sternchen vor dem Label das Überfliegen erleichtert.
9. Gibt es wenige freiwillige Felder, kennzeichnen Sie sie mit „optional“. Whitenton rät, freiwillige Felder auf eins oder zwei zu begrenzen und klar zu beschriften. So lernt der Nutzer die Regel nicht durch Versuch und Irrtum.
10. Wählen Sie die Breite des Felds nach der Länge der erwarteten Antwort. Das Beispiel von GOV.UK: Ein Feld für die Postleitzahl ist so breit wie eine Postleitzahl. Die richtige Größe hilft zu verstehen, was hineingehört.
11. Bei zwei oder drei Optionen: Radiobuttons statt Dropdown. Diese Empfehlung stammt von Whitenton. Liegen die Optionen offen, entscheidet der Nutzer, ohne eine Liste zu öffnen.
12. Ordnen Sie die Felder in der gewohnten Reihenfolge und halten Sie die Tab-Reihenfolge gleich der sichtbaren. Whitenton verlangt, die Tab-Reihenfolge mit der Tastatur zu testen. Springt der Fokus über den Screen, verliert ein Tastaturnutzer den Weg.
13. Zeigen Sie keinen Fehler, während der Nutzer tippt. Rachel Krause von NN/g rät, zu warten, bis das Feld verlassen wird. Laut Baymard kann ein zu früher Fehler dazu führen, dass der Nutzer einen richtig eingegebenen Wert für falsch hält.
14. Setzen Sie die Fehlermeldung direkt an das Feld. Laut Krause kann der Nutzer die Meldung so lesen, während er den Fehler behebt. Er muss sie sich nicht merken.
15. Entfernen Sie die Meldung, sobald der Nutzer den Fehler behoben hat. Baymard schreibt, dass eine Meldung, die nach der Korrektur stehen bleibt, verwirrt, besonders bei verknüpften Feldern wie der Passwortwiederholung.
16. Zeigen Sie Fehler nicht nur über die Farbe. Krause verlangt neben der roten Farbe ein Icon. Auch das Kriterium 3.3.1 der WCAG 2.2 schreibt vor, dass der Fehler in Text beschrieben wird.
17. Sagen Sie in der Meldung, was passiert ist und wie man es behebt. GOV.UK rät von allgemeinen Meldungen wie „Dieses Feld ist ein Pflichtfeld“ ab. Schreiben Sie für ein leeres Feld eine Anweisung wie „Geben Sie Ihren Namen ein“.
18. Verzichten Sie in der Meldung auf Vorwürfe, Entschuldigungen und das Wort „ungültig“. Die englischen Wörter für „vergessen“, „bitte“, „leider“ und „ungültig“ stehen auf der Liste der Wörter, die GOV.UK vermeidet. Sie sagen dem Nutzer nicht, was er korrigieren soll.
19. Gibt es beim Senden Fehler, zeigen Sie oben im Formular eine Zusammenfassung und setzen Sie den Fokus dorthin. So funktioniert das Validation-Muster von GOV.UK. Krause ergänzt, dass Sie sich nicht allein auf die Zusammenfassung verlassen sollen, weil der Nutzer sonst jedes Feld suchen muss.
20. Löschen Sie nichts, was der Nutzer geschrieben hat. GOV.UK verlangt, dass richtige wie falsche Antworten stehen bleiben. Nur so sieht der Nutzer, was schiefgelaufen ist.
21. Setzen Sie keinen Button „Zurücksetzen“ oder „Leeren“ ans Ende des Formulars. Laut Whitenton ist der Schaden, versehentlich alles zu löschen, größer als der Nutzen für jemanden, der neu anfangen will.
22. Geben Sie Feldern mit Angaben zum Nutzer ein autocomplete. Laut GOV.UK füllt der Browser so selbst aus, was der Nutzer früher schon eingegeben hat. GOV.UK schreibt auch, dass das für das Kriterium 1.3.5 der WCAG 2.2 nötig ist.
23. Lassen Sie dieselbe Information im selben Prozess nicht zweimal eingeben. Das Kriterium 3.3.7 der WCAG 2.2 verlangt, dass bereits eingegebene Informationen automatisch ausgefüllt werden oder auswählbar sind.

Eine Anmerkung zu Regel 18: Die Liste von GOV.UK besteht aus englischen Wörtern. Ich wende dieselbe Logik auf die deutschen Entsprechungen an.

Tun und lassen

Schlechtes und gutes Formular

Unten sehen Sie zwei Formulare mit denselben drei Feldern. Links das schlechte Beispiel, rechts ein Formular, das den Regeln dieser Seite folgt. Auf schmalen Screens stehen sie untereinander.

Schlechtes und gutes Formular

Schlecht

Platzhalter als Label, früher Fehler

SendenZurücksetzen

Beim Tippen: Schon beim ersten Buchstaben wird das Feld rot. Eine Erklärung gibt es nicht.

Nach „Senden“: Oben erscheint ein allgemeiner Hinweis, und alle Felder werden geleert. Dass die Telefonnummer keine Leerzeichen haben darf, steht nirgends.

Gut

Label oben, Fehler am Feld

Vor- und Nachname

E-Mail

Ich antworte Ihnen an diese Adresse

Telefon (optional)

Beispiel: 0151 23456789

Senden

Beim Tippen: Kein Fehler. Beim Verlassen des Felds wird das Format geprüft, und sobald Sie korrigieren, verschwindet die Meldung.

Nach „Senden“: Oben erscheint eine Liste der Probleme, und der Fokus springt dorthin. Jede Meldung steht an ihrem Feld, Ihre Eingaben bleiben erhalten.

Beide Formulare haben dieselben drei Felder. Lassen Sie zuerst beide leer und drücken Sie „Senden“. Schreiben Sie dann „anna@“ in die E-Mail, geben Sie die Telefonnummer mit Leerzeichen ein und versuchen Sie es noch einmal. Ist JavaScript aus, beschreibt die Notiz unter jedem Formular, was beim Senden passiert.

Den Unterschied sehen Sie am schnellsten nach „Senden“. Das schlechte Formular sagt „Etwas ist falsch“ und schickt Sie zurück an den Anfang. Das gute sagt, was falsch ist und wo Sie hinschauen müssen.

Beim Telefonfeld ist der Unterschied noch deutlicher. Das schlechte Formular lehnt „0151 23456789“ ab und sagt nicht, warum. Das gute akzeptiert dieselbe Schreibweise und entfernt Leerzeichen und Klammern selbst.

Dieselbe Logik gilt für lange Nummern wie IBAN, Kartennummer oder Steuer-ID. Nutzer schreiben sie in Gruppen. Das Formular soll diese Gruppen akzeptieren und die Leerzeichen erst beim Speichern entfernen.

Meine Notiz

Wann live validiert wird, darin sind sich die Quellen nicht einig. NN/g und Baymard empfehlen die Prüfung beim Verlassen des Felds. GOV.UK verlangt dagegen, erst zu prüfen, wenn der Nutzer auf „Senden“ oder „Weiter“ drückt.

GOV.UK erlaubt eine Prüfung beim Tippen nur unter einer Bedingung: Nutzerforschung muss zeigen, dass sie mehr Probleme löst, als sie schafft. Als Beispiel nennt GOV.UK den Zeichenzähler.

Im guten Formular oben habe ich beides verbunden. Ein leeres Feld melde ich beim Senden, weil der Nutzer gleich noch dorthin zurückkehren kann. Einen geschriebenen, aber falsch formatierten Wert zeige ich beim Verlassen des Felds.

Der teuerste Formularfehler ist für mich, die Felder nach einem Fehler zu leeren. Auch GOV.UK verlangt, dass die Felder so wieder angezeigt werden, wie der Nutzer sie ausgefüllt hat. Leeren widerspricht auch der neunten von Nielsens 10 Usability-Heuristiken: Nutzer sollen Fehler erkennen, verstehen und beheben können.

Hinweis zur Barrierefreiheit

In einer Barrierefreiheitsprüfung gehören Formulare zu den ersten Stellen, die ich mir ansehe. Zuerst prüfe ich diese vier Kriterien der WCAG 2.2.

• 3.3.2 Beschriftungen oder Anweisungen (Stufe A). Überall, wo der Nutzer etwas eingibt, braucht es ein Label oder eine Anweisung. Laut W3C erfüllt ein Name, der nur für assistive Technologien sichtbar ist, das Kriterium möglicherweise nicht.
• 3.3.1 Fehlererkennung (Stufe A). Bei einem automatisch erkannten Fehler wird das fehlerhafte Feld genannt und der Fehler in Text beschrieben. Laut W3C dürfen visuelle Hinweise wie Farbe nur zusätzlich zu diesem Text verwendet werden.
• 1.3.5 Bestimmung des Eingabezwecks (Stufe AA). Der Zweck eines Felds, das Angaben zum Nutzer sammelt, muss maschinell lesbar sein. Die ausreichende Technik, die das W3C für HTML zeigt, ist das Attribut autocomplete.
• 3.3.7 Redundante Eingabe (Stufe A). Wird im selben Prozess eine bereits eingegebene Information erneut verlangt, muss sie automatisch ausgefüllt oder auswählbar sein.

GOV.UK setzt vor die Fehlermeldung ein unsichtbares Präfix „Error:“. Screenreader-Nutzer hören so zuerst, dass es ein Fehler ist. Das Validation-Muster verlangt, dass bei einem Fehler auch vor den Seitentitel „Error: “ gesetzt wird.

Auf deutschen Seiten schreibe ich dieses Präfix als „Fehler:“. Wie ich ein Formular von Anfang bis Ende prüfe, beschreibe ich im Ratgeber zur Barrierefreiheitsprüfung, alle Kriterien im WCAG-Ratgeber.

Hinweis zur Umsetzung

Unten das einfache HTML für das E-Mail-Feld aus dem guten Formular. Label, Hinweis und Fehlerzeile sind über for und aria-describedby mit dem Feld verbunden.

<form action="/anfrage" method="post" novalidate>
  <div class="field">
    <label class="field__label" for="email">E-Mail</label>
    <p class="hinweis" id="email-hinweis">Ich antworte Ihnen an diese Adresse</p>
    <!-- Ohne Fehler bleibt diese Zeile verborgen. -->
    <p class="fehler" id="email-fehler" hidden>
      <span class="sr-only">Fehler: </span>Geben Sie die E-Mail-Adresse im Format [email protected] ein
    </p>
    <input class="field__control" id="email" name="email"
           type="email" autocomplete="email" spellcheck="false"
           aria-describedby="email-hinweis email-fehler">
  </div>
  <button class="btn btn--primary" type="submit">Anfrage senden</button>
</form>

Das novalidate im Formular schaltet die eigenen Fehlerblasen des Browsers ab. GOV.UK verlangt das und sagt, dass Felder kein required bekommen sollen. So schreiben Sie den Fehlertext selbst.

Die Prüfung im Browser funktioniert nicht immer. Deshalb verlangt GOV.UK, immer auch auf dem Server zu validieren.

Bei einem Fehler setze ich aria-invalid="true" auf das Feld und entferne das Attribut hidden von der Fehlerzeile. Wenn ich das Formular vom Design bis zum Code für Sie bauen soll, gehört das in den Design & Ship Sprint.

Checkliste

Bevor ein Formular live geht, gehe ich diese Liste durch. Wenn ich Ihr Formular mit dieser Liste prüfen soll: Der UX Audit deckt das alles ab.

• Ich kann in einem Satz sagen, warum jedes Feld abgefragt wird.
• Die Felder stehen in einer Spalte, zusammengehörige gruppiert.
• Über jedem Feld steht ein sichtbares Label, der Platzhalter ist kein Label.
• Formatregeln stehen am Feld, bevor ein Fehler entsteht.
• Pflichtfelder und freiwillige Felder sind zu unterscheiden.
• Beim Tippen erscheint kein Fehler, ein behobener Fehler verschwindet sofort.
• Jeder Fehler steht mit Text und Icon an seinem Feld.
• Beim Senden erscheint oben eine Zusammenfassung, der Fokus springt dorthin.
• Nach einem Fehler wird kein Feld geleert.
• Felder mit Angaben zum Nutzer haben autocomplete.
• Die Tab-Reihenfolge entspricht der sichtbaren Reihenfolge.
• Auch auf dem Server wird validiert.