Form Design Best Practices: 10 Regeln für Web und Mobile
Die 10 Regeln für Formulare, die konvertieren. Echte Teardowns der Anmeldeflows von Notion, Tally und Mercury, plus Mobile-First-Patterns, die wirklich funktionieren.
Form Design Best Practices: 10 Regeln für Web und Mobile
Die Kosten eines schlechten Formulars
Ein schlechtes Formular ist eine Strategiesteuer auf jeden Euro, den du ausgegeben hast, um jemanden auf die Seite zu bringen. Completion Rates für Anmelde-, Checkout- und Onboarding-Formulare liegen im Schnitt bei rund 12 %, wenn Friction vorhanden ist. Entferne die Friction, und diese Zahl klettert über 50 %.
Die Lücke liegt fast nie am Text oder am Branding. Es sind die zehn Regeln, konsequent angewendet.
Salesforce-artige 30-Felder-Lead-Formulare existieren, weil jemand ein Datenbankschema auf eine Seite gemappt und das Ganze als Formular bezeichnet hat. Dafür hat sich der Nutzer nicht registriert. Er kam wegen des Produkts, und deine Qualifikationslogik hat dir den Lead gekostet.
Regel 1: Eine Spalte, eine Aufgabe pro Bildschirm
Eine Spalte, immer. Mehrspaltige Layouts wirken in einem Figma-Grid effizient und zerstören die Completion Rates auf einem echten Bildschirm.
Das Auge liest von links nach rechts und erwartet Kontinuität. Wenn Felder auf zwei Spalten aufgeteilt werden, muss der Nutzer entscheiden, welchem Pfad er folgt, und diese Mikroentscheidung erzeugt Friction, bevor auch nur ein einziges Zeichen getippt ist.
Notions Anmeldeflow ist eine einzelne zentrierte Spalte, die auf Mobile jeweils ein Feld hervorhebt. Das Formular wirkt schnell, weil es nach einer Sache fragt. Das ist die Regel.
Regel 2: Label-Position ist wichtiger als Label-Stil
Labels stehen über dem Feld. Nicht darin, nicht daneben. Oben, immer sichtbar.
Placeholder-Text als Label verschwindet in dem Moment, in dem der Nutzer anfängt zu tippen. Dann muss er das Feld leeren, um sich zu erinnern, was er gerade ausfüllt. Mercurys Onboarding-Flow verwendet auf jedem Input persistente Labels über dem Feld, damit der Kontext während des Ausfüllens nie verloren geht.
Floating Labels, die beim Fokus aus der Placeholder-Position nach oben animieren, sind ein akzeptabler Mittelweg, erfordern aber scharfen Kontrast und sorgfältiges Timing, um barrierefrei zu sein. Im Zweifel das Label oben platzieren und dort lassen.
Die UX-Forschung zur Label-Positionierung wird ausführlich in unserem Leitfaden zu UX-Research-Methoden behandelt.
Regel 3: Feldreihenfolge folgt der Nutzerrealität, nicht dem Datenbankschema
Die Reihenfolge der Felder sollte widerspiegeln, wie ein Mensch über die Aufgabe nachdenkt, nicht wie Entwickler das Datenmodell strukturiert haben.
Ein Checkout-Formular, das nach der Lieferadresse fragt, bevor der Warenkorb bestätigt wurde, legt die Kontextlast auf den Nutzer. Stripe Checkout, die kanonische Referenz für gehostete Checkout-Formular-UX, gliedert das Formular in drei Schritte:
- E-Mail (wer bist du)
- Zahlung (wie wirst du zahlen)
- Adresse (wohin soll es gehen)
Das ist die Reihenfolge, die ein vernünftiger Mensch persönlich wählen würde. Wenn die Datenbank die Feldreihenfolge diktiert, entstehen Formulare, die nach einer Postleitzahl fragen, bevor ein Land angegeben wurde, oder nach einem Jobtitel, bevor ein Unternehmen bekannt ist.
Regel 4: Inline validieren, nie beim Absenden
Das Feld validieren, sobald der Nutzer es verlässt, nicht wenn er auf den Submit-Button klickt.
Validierung beim Absenden bedeutet: Der Nutzer füllt ein Zehn-Felder-Formular aus, drückt den Button, und bekommt eine Wand roter Fehler präsentiert. Jeder Fehler ist eine Korrekturaufgabe, und jede Korrekturaufgabe riskiert, ihn ganz zu verlieren. Inline-Validierung, ausgelöst beim Blur, zeigt den Fehler, bevor der Nutzer weitermacht.
Apple ID validiert das E-Mail-Format beim Blur und prüft die Kontoverfügbarkeit, bevor der Submit-Button überhaupt aktiv wird. Diese Sequenzierung verhindert zwei Fehlerkategorien auf einmal. Die Interaktionsmuster dahinter werden in unserem Leitfaden zu Microinteraction Design behandelt.
Regel 5: Mobile-First bedeutet Mobile-Tastaturen
Jeder Feldtyp sollte die richtige Tastatur aufrufen. Das sind 80 % des Mobile-Formular-Designs.
Wenn ein Feld nach einer Telefonnummer fragt und die Standard-Texttastatur erscheint, ist das Formular kaputt, bevor der Nutzer auch nur etwas getippt hat. inputmode="numeric" für numerische Felder verwenden, type="email" um die @-Taste zu zeigen, und inputmode="decimal" für Preise. iOS und Android unterstützen beide den gesamten Bereich der Input-Modes.
Die Tastatur ist das primäre Eingabegerät auf Mobile. Die falsche anzugeben verwandelt ein visuell korrekt gestaltetes Formular in ein frustrierendes.
| Feldtyp | Korrektes HTML-Attribut |
|---|---|
type="email" | |
| Telefon | type="tel" |
| Ganzzahl | inputmode="numeric" |
| Dezimal / Preis | inputmode="decimal" |
| URL | type="url" |
| Suche | inputmode="search" |
Für das breitere Mobile-First-Fundament, in dem diese Patterns eingebettet sind, siehe Grundlagen des responsiven Webdesigns.
Regel 6: Fortschritt, Microcopy und das Langformular-Problem
Wenn das Formular mehr als fünf Felder erfordert, dem Nutzer zeigen, wo er im Flow steht.
Airbnbs mehrstufiger Buchungsflow zeigt während des gesamten Prozesses einen Fortschrittsindikator mit benannten Schritten. Nutzer, die sehen, dass sie 60 % erledigt haben, schließen den Flow nachweislich häufiger ab als Nutzer ohne Referenzpunkt.
Tally verfolgt für seine einbettbaren Formulare einen anderen Ansatz: eine Frage auf einmal mit einer persistenten Fortschrittsanzeige oben, die in den dokumentierten Nutzertests von Tally konsistent besser abschneidet als einseitige Langformulare.
Microcopy leistet dieselbe Arbeit. "Schritt 2 von 4" ist ehrlicher als ein bloßer Fortschrittsbalken. "Wir benötigen diese Angabe zur Identitätsprüfung" ist hilfreicher als ein unbeschriftetes sensibles Feld.
Regel 7: Fehlermeldungen sind Anweisungen, keine Anschuldigungen
Fehlermeldungen im Imperativ schreiben, nicht als Anschuldigung.
"Dieses Feld ist erforderlich" ist eine Anschuldigung. "E-Mail-Adresse eingeben, um fortzufahren" ist eine Anweisung. Der Nutzer weiß bereits, dass etwas schiefgelaufen ist. Was er braucht, ist die Lösung.
Die beste Fehler-Copy benennt die genaue Bedingung und die genaue Handlung: "Das Passwort muss mindestens 8 Zeichen enthalten und eine Zahl einschließen." Stripe Checkout macht das präzise. Die Meldung erscheint beim Blur, benennt das Problem und verschwindet, sobald die Bedingung erfüllt ist.
Kein anhaltender roter Zustand. Es funktioniert einfach.
Regel 8: Autofill ist ein Feature, kein Nachgedanke
Das autocomplete-Attribut sagt dem Browser genau, was ausgefüllt werden soll. Es auf jedem Feld verwenden.
Ein Checkout-Formular mit korrekten Autocomplete-Attributen dauert auf einem Telefon mit gespeicherten Daten etwa 12 Sekunden zum Ausfüllen. Ohne sie dauert dasselbe Formular zwei Minuten, weil der Nutzer alles manuell eingibt. Diese Lücke von 108 Sekunden ist der Punkt, an dem die meisten Mobile-Checkout-Abbrüche passieren, und sie kostet nichts, sie zu schließen. Der Leitfaden zur UI-Komponentenbibliothek zeigt, wie man diese Attribute in die Formularkomponenten des Design-Systems einbaut, damit sie nie fehlen.
| Feld | autocomplete-Wert |
|---|---|
email | |
| Vorname | given-name |
| Nachname | family-name |
| Telefon | tel |
| Straße | street-address |
| Stadt | address-level2 |
| Postleitzahl | postal-code |
| Kartennummer | cc-number |
| Kartenablauf | cc-exp |
Regel 9: Der Submit-Button entscheidet alles
Der Submit-Button ist der Vertrag. Seine Beschriftung, sein Zustand und seine Position signalisieren, ob der Nutzer dem vertrauen kann, was als Nächstes passiert.
Ein ausgegrauer Button ohne Erklärung sagt dem Nutzer, dass das Formular kaputt ist, aber nicht warum. Das ist eine Sackgasse. Ein Button mit der Aufschrift "Absenden" sagt dem Nutzer nichts darüber, womit er sich einverstanden erklärt.
"Konto erstellen", "Kostenlose Testversion starten" und "Loslegen" sind alle ehrlicher. Den Button nur deaktivieren, wenn der Grund in der UI erklärt werden kann. Tally verwendet auf jedem Schritt im Formularersteller aktionsspezifische Button-Beschriftungen, und das ist ein direkter Beitrag zu den überdurchschnittlichen Completion Rates für eingebettete B2B-Flows.
Regel 10: Mit echten Daumen, echten Daten, echter Latenz testen
Ein Formular in einem Desktop-Browser über schnelles WLAN zu testen sagt einem nichts Aussagekräftiges darüber, ob es funktioniert.
Auf einem mittelklassigen Android-Gerät über eine 4G-Verbindung mit realen Datenlängen in jedem Feld testen:
- Ein Name mit einem Akzentzeichen
- Eine Adresse mit einer Wohnungsnummer in Zeile zwei
- Eine 22-Zeichen-E-Mail
- Ein 1-Zeichen-Vorname
Realwelt-Edge-Cases brechen Formulare, die in Figma sauber aussehen. Echte Latenz zeigt, ob Validierungsaufrufe den Input blockieren oder asynchron laufen. Dieser Unterschied ist in einem Browser-Simulator unsichtbar und auf einem Telefon mit zwei Balken Empfang katastrophal.
Du möchtest ein Formular-Audit für deinen Anmelde-, Checkout- oder Onboarding-Flow? Brainy führt das vollständige Zehn-Regeln-Audit auf echten Bildschirmen, mit echten Daten und echten Conversion-Zahlen durch.
Wo Designer noch immer die schlechtesten Formulare veröffentlichen
Die schlechtesten Formulare in der Produktion teilen heute drei Muster:
- Enterprise-Sales-Lead-Formulare: Salesforce-artige 30-Felder-Qualifikationsmasken mit obligatorischen "Jahresumsatz"-Selektoren und ohne Inline-Validierung
- Mehrstufige Onboarding-Flows, die keinen Fortschritt speichern: ein Anruf bei Schritt 7 von 9 schickt den Nutzer zurück zu Schritt 1
- Checkout-Flows, die vor dem Mobile-Zeitalter gebaut und nie neu gebaut wurden: jedes numerische Feld verwendet noch immer
type="text", weil "es auf Desktop gut funktioniert"
Die Fehlerzustandsentscheidungen in allen drei Fällen scheitern auch oft an Kontrastvorgaben; barrierefreie Farbkontrastmuster beheben diesen spezifischen Fehlerpunkt.
Der gemeinsame Nenner in allen drei: Das Formular wurde für das System gestaltet, nicht für die Person, die es ausfüllt. Die Lösung ist dieselbe.
Die zehn Regeln anwenden. Mit Mobile anfangen. Das Datenbankschema für sich selbst sorgen lassen.
FAQ
Wie viele Felder sollte ein Formular haben?
So wenige, wie das Ergebnis erfordert. Die richtige Anzahl ist die, bei der das Entfernen eines weiteren Felds das Produkt kaputt machen würde. Jedes Feld, das hinzugefügt wird, senkt die Completion Rate. Bei null anfangen und nur hinzufügen, was zwingend erforderlich ist.
Sollte ich mehrstufige oder einseitige Formulare verwenden?
Bei mehr als fünf Feldern übertrifft mehrstufig fast immer einseitig. Die Voraussetzung ist sichtbarer Fortschritt. Ohne ihn schneiden mehrstufige Formulare schlechter ab als einseitige, weil der Nutzer keine Ahnung hat, wie lang der Weg noch ist. Schritte benennen und zeigen, wo er in der Abfolge steht.
Was ist der beste Weg, Pflichtfelder zu kennzeichnen?
Optionale Felder kennzeichnen, nicht Pflichtfelder. Wenn die meisten Felder Pflichtfelder sind (was sie sein sollten, angesichts der obigen Regel), ist das Markieren jedes Felds mit einem roten Sternchen visuelles Rauschen.
Die Ausnahmen kennzeichnen. "Optional" neben einem Feld ist eine sinnvolle Information. Ein Sternchen neben jedem Feld ist es nicht.
Wie gehe ich mit Passwortanforderungen um, ohne den Nutzer zu bestrafen?
Anforderungen anzeigen, bevor der Nutzer anfängt zu tippen, nicht nachdem er gescheitert ist. Eine kleine Checkliste, die sich aktiviert, wenn jede Bedingung erfüllt ist, schneidet besser ab als eine Fehlerwand nach dem Absenden. Apple ID und die meisten aktuellen Auth-Flows verwenden dieses Pattern. Das Feedback ist live, positiv und nie bestrafend.
Kommuniziert die Feldbreite etwas?
Ja, und Nutzer lesen das. Feldbreite signalisiert die erwartete Eingabelänge. Ein schmales Feld signalisiert eine kurze Antwort. Ein vollbreites Feld signalisiert eine längere.
Feldbreite an die erwartete Eingabelänge anpassen, wo das Layout es erlaubt. Ein Postleitzahl-Feld in voller Breite sieht wie ein Fehler aus. Ein Textbereich für eine Straße sieht nach Overkill aus. Den Container dem erwarteten Inhalt anpassen.
Was verursacht die meisten Mobile-Formular-Abbrüche?
Falscher Tastaturtyp steht an erster Stelle. Autofill, das nicht funktioniert, an zweiter. Beide sind stille Fehler: Das Formular sieht korrekt aus, der Nutzer kann es nur nicht effizient ausfüllen.
Beide mit zwei Attributen pro Feld beheben. Der Aufwand beträgt 15 Minuten. Die Rendite ist messbar in der Checkout-Conversion innerhalb desselben Sprints.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started
