Ein Formular ist kein „Pflichtteil“ am Ende einer Seite, sondern eine eigene kleine Nutzerreise. Wer hier zu viel verlangt, unklar beschriftet oder Fehler erst nach dem Absenden erklärt, verliert Menschen direkt vor dem Ziel. Gute UI-Formulare wirken dagegen unspektakulär: Sie führen ruhig durch den Prozess, erklären Erwartungen vorab und behandeln Fehler wie normale Situationen.
Im Webdesign treffen in Formularen viele Disziplinen aufeinander: Layout, Interaktion, Text, Barrierefreiheit und saubere Übergabe an die Entwicklung. Die folgenden Abschnitte helfen dabei, Formulare in Figma (oder ähnlichen Tools) so zu planen, dass sie im Code auch wirklich so funktionieren.
Welche Aufgaben ein Formular im UI wirklich lösen muss
Reduzieren statt sammeln: nur das abfragen, was gebraucht wird
Viele Formulare scheitern nicht an Farben oder Abständen, sondern an der Menge. Jede zusätzliche Frage erhöht die Denkzeit und die Chance auf Abbruch. Praktisch hilft eine harte Priorisierung: Welche Information ist zwingend nötig, um den nächsten Schritt zu ermöglichen? Alles andere kann später kommen (z. B. nach dem Kauf, im Profil, per optionalem Schritt).
Eine einfache Regel für die Planung: Jedes Feld braucht eine klare Begründung. Wenn diese Begründung nicht in einem Satz erklärbar ist, ist das Feld meist „Nice to have“.
Vertrauen schaffen: sensible Daten und Erwartungen klären
Nutzer geben Daten nicht nur „ein“, sie geben sie „ab“. Je persönlicher die Information (Adresse, Telefonnummer, Zahlungsdaten), desto wichtiger sind klare Hinweise: Wofür wird das benötigt? Kann das später geändert werden? Wo liegt die Hürde (z. B. Passwortregeln)?
Hier hilft eine Kombination aus verständlicher Feldbeschriftung, hilfreichen Hinweisen (unter dem Feld) und einem UI, das Fehler früh erkennt. In der Praxis ist Formular-UX oft der Unterschied zwischen „geht schnell“ und „fühlt sich riskant an“.
Feldtypen, Labels und Hilfetexte: so entsteht Klarheit
Labels sind Pflicht: Platzhalter ersetzen keine Beschriftung
Platzhaltertext (grauer Text im Feld) ist hilfreich für Beispiele, aber keine Beschriftung. Sobald der Nutzer tippt, verschwindet der Hinweis – und der Kontext geht verloren. Das führt besonders bei längeren Formularen zu Fehlern. Labels (Feldnamen) sollten daher sichtbar bleiben, auch wenn das Feld gefüllt ist.
Floating Labels (Labels, die beim Tippen nach oben wandern) können funktionieren, wenn sie gut lesbar bleiben und nicht „springen“. Wichtig ist dann eine stabile Höhe, damit das Layout beim Fokus nicht wackelt.
Hilfetexte (unter dem Feld) sind für Regeln, nicht für Marketing
Hilfetexte unter Eingabefeldern sollten Erwartungen klären: Format, Mindestanforderungen, Beispiele. Sie sind keine Bühne für lange Erklärungen. Besser kurz, konkret und im Wortschatz der Nutzer.
- Gut: „Bitte ohne Leerzeichen, z. B. max.mustermann“
- Schwierig: „Der Benutzername wird für die Authentifizierung im System verwendet“
Die richtige Auswahl: Textfeld, Dropdown, Radio, Checkbox
Die Komponente sollte zur Entscheidung passen. Als Faustregeln:
- Kurze, freie Eingabe: Textfeld
- Wenige Optionen (2–6), genau eine Auswahl: Radio Buttons
- Viele Optionen oder Platz ist knapp: Dropdown (aber sparsam einsetzen)
- Mehrere mögliche Auswahlpunkte: Checkboxen
Dropdowns wirken ordentlich, sind aber oft langsamer, besonders auf Mobile. Wenn die wichtigsten Optionen bekannt sind, sind Radios schneller und transparenter.
Fehler, Hinweise, Erfolg: Validierung ohne Frust
Fehler nicht bestrafen: erklären, wie es richtig geht
Fehlermeldungen sollten nicht nur sagen, dass etwas falsch ist, sondern wie es korrekt wird. Ein gutes Muster: Problem + Lösungsvorschlag.
- Schwierig: „Ungültige Eingabe“
- Besser: „Bitte eine E-Mail-Adresse im Format name@domain.de eingeben“
Das gilt auch für technische Themen wie Passwörter: Regeln sichtbar machen, idealerweise schon bevor der Fehler entsteht. Dann fühlt sich die Eingabe wie „geführt“ an statt wie „geprüft“.
Wann validieren? Sofort, nach dem Feld, oder erst beim Absenden
Es gibt drei gängige Zeitpunkte für Validierung (Prüfung der Eingaben). Jeder hat Vor- und Nachteile:
| Moment | Vorteil | Risiko |
|---|---|---|
| Während des Tippens | Sehr schnell, hilfreich bei Formatfeldern | Kann nerven, wenn zu früh „rot“ wird |
| Nach Verlassen des Felds | Guter Standard, weniger Ablenkung | Fehler werden etwas später sichtbar |
| Beim Absenden | Ruhig im Ablauf, einfach zu verstehen | Viele Fehler auf einmal, hoher Frust |
In der Praxis funktioniert eine Mischung gut: Formatfehler (z. B. E-Mail) nach Verlassen des Felds, komplexere Dinge (z. B. „E-Mail bereits vergeben“) nach Absenden oder nach Feldwechsel, abhängig vom System.
States im UI: Normal, Fokus, Fehler, Erfolg, deaktiviert
Formularfelder brauchen definierte Zustände (States), damit Nutzer Orientierung haben: Wo bin ich gerade? Was ist erledigt? Was muss korrigiert werden? Dabei sollte nicht nur Farbe kommunizieren. Zusätzliche Signale wie Icons, Text und klare Fehlermeldungen helfen besonders bei eingeschränktem Farbsehen.
Wenn ein Formular viele Felder hat, lohnt es sich, diese States als Varianten in der Komponente zu pflegen. Dazu passt ein sauberes Komponenten-Setup, wie es auch in UI-Design-System in Figma aufbauen – Komponenten mit Plan beschrieben wird.
Reihenfolge und Gruppierung: der Flow entscheidet über Tempo
Logische Gruppen bilden: Abschnitte statt Endlosliste
Menschen scannen. Wer verwandte Felder zusammenfasst (z. B. „Kontakt“, „Adresse“, „Zahlung“), reduziert mentale Last. Kleine Zwischenüberschriften sind hilfreich, aber auch die Anordnung selbst: Felder, die zusammengehören, sollten nah beieinander stehen.
Hier zahlt sich ein konsequentes Abstands-System aus. Wenn Abstände wild wechseln, wirkt das Formular unruhig und schwerer zu überblicken. Als Vertiefung hilft Design-Spacing im Webdesign – Abstände mit System planen.
Progressive Disclosure: erst fragen, wenn es relevant wird
Progressive Disclosure bedeutet: Zusätzliche Felder erscheinen erst, wenn sie nötig sind. Beispiel: „Firma“ nur anzeigen, wenn „Rechnung an Firma“ gewählt ist. Das verkürzt das Formular visuell und vermeidet Fragen, die viele Nutzer gar nicht betreffen.
Wichtig ist dabei Stabilität: Wenn Felder ein- und ausblenden, sollte das Layout nicht hektisch springen. Sanfte Übergänge helfen, aber schon das klare Einrücken und eine gute Gruppenlogik reichen oft aus.
Mobile zuerst denken: Tastaturtypen, Autofill, Scrollverhalten
Auf Mobile ist der Bildschirm klein, die Tastatur groß, und jeder unnötige Tap kostet Geduld. Darum lohnt sich Mobile-First im Formular besonders:
- Passender Eingabetyp (z. B. E-Mail-Tastatur mit „@“)
- Autofill-Felder sinnvoll benennen (für Entwickler relevant)
- Kurze Felder nicht zu hoch stapeln, aber auch nicht zu eng
- Fehlermeldungen nah am Feld anzeigen, nicht „oben irgendwo“
Barrierefreiheit bei Formularen: besser für alle
Fehler müssen verständlich und auffindbar sein
Barrierefreies Formulardesign bedeutet: Jeder kann das Formular bedienen, auch mit Tastatur, Screenreader oder bei eingeschränktem Sehvermögen. Praktisch im UI: Fehlermeldungen gehören direkt zum Feld und sollten klar sagen, was zu tun ist. Zusätzlich hilft eine Zusammenfassung am Anfang, wenn viele Felder betroffen sind (vor allem bei langen Formularen).
Auch Kontraste und Fokus-Markierungen gehören dazu. Ein Fokus-Rahmen darf nicht „wegdesignt“ werden, sondern sollte ins Design integriert wirken.
Pflichtfelder klar markieren, aber nicht überladen
Pflichtfelder sollten erkennbar sein, ohne dass der Bildschirm voller Sternchen wird. Eine gängige Lösung: Pflichtfelder markieren und zusätzlich am Anfang kurz erklären, was das Symbol bedeutet. Alternativ können nur optionale Felder mit „optional“ gekennzeichnet werden. Wichtig ist die Konsistenz.
Wenn das Thema Barrierefreiheit grundsätzlich im Team verankert werden soll, ergänzt Barrierefreiheit im Web – WCAG verständlich, Design praxisnah die Grundlagen sehr gut.
Aus Figma in die Umsetzung: Spezifikation, States, Inhalte
Komponenten sauber anlegen: Feld, Label, Hilfe, Fehler als Einheit
In Design-Tools wirkt ein Formular schnell „fertig“, aber in der Umsetzung entstehen Fragen: Wie hoch ist ein Feld? Was passiert beim Fehlerzustand? Wie sieht ein disabled Feld aus? Darum lohnt es sich, pro Feld-Komponente eine klare Struktur anzulegen: Label, Input, Hilfetext, Fehlermeldung. Diese Teile sollten als Einheit verschiebbar sein.
Wer mit Auto Layout arbeitet, bekommt hier besonders stabile Ergebnisse, weil Texte wachsen dürfen, ohne alles zu zerlegen. Dazu passt Figma Auto Layout meistern – flexible UI-Layouts mit System.
Microcopy im Formular: kurze Texte, die Entscheidungen erleichtern
Gute Formularthemen sind oft Textthemen: Feldlabels, Buttontexte, Fehlermeldungen, Hinweise. Das Ziel ist nicht „nett klingen“, sondern Missverständnisse zu vermeiden. Dazu gehören:
- Klare Buttontexte (z. B. „Konto erstellen“ statt „Senden“)
- Hinweise, was nach dem Klick passiert
- Fehlertexte, die Lösung und Ursache verständlich trennen
Wenn die Sprache im Interface insgesamt geschärft werden soll, hilft UI-Text im Webdesign: Microcopy, die Nutzer führt als Ergänzung.
Übergabe an Entwickler: was in Specs stehen sollte
Damit das Formular nicht „ungefähr so“ umgesetzt wird, brauchen Teams eine klare Übergabe. Dazu gehören neben Größen und Abständen vor allem Interaktionsregeln: Wann erscheint ein Fehler? Wie sieht Fokus aus? Was passiert bei Ladezustand? Welche Felder sind abhängig voneinander?
Ein typischer Stolperstein: In Designs ist alles „instant“, in echt gibt es Ladezeiten (z. B. bei Adressprüfung). Für diese Momente sollten Zustände geplant werden, etwa „lädt“, „erfolgreich geprüft“ oder „konnte nicht geprüft werden“.
Kompakte Schritte für die nächste Formular-Iteration
- Felderliste prüfen: jedes Feld braucht eine klare Begründung, sonst raus oder optional.
- Pro Feld definieren: Label, Hilfetext, Fehlertext, Erfolg/Status.
- Reihenfolge in Gruppen denken (Kontakt, Adresse, Zahlung) und visuell sauber trennen.
- Validierungslogik festlegen: während des Tippens, nach Feldwechsel oder beim Absenden.
- Mobile testen: Tastaturtypen, Scroll, Fehlermeldungen im Sichtbereich.
- Komponenten in Varianten anlegen: normal, Fokus, Fehler, disabled.
- Für die Entwicklung notieren: Abhängigkeiten, Ladezustände, Textlängen (kurz/lang).
Ein typisches Szenario aus Projekten: „Warum brechen so viele im Checkout ab?“
Ausgangslage: viele Pflichtfelder, Fehler erst nach dem Absenden
Ein häufiger Befund in Checkouts: Das Formular wirkt aufgeräumt, aber es fragt zu viel auf einmal ab. Zusätzlich erscheinen Fehlermeldungen erst nach dem Klick auf „Weiter“, dann gleich an mehreren Stellen. Nutzer müssen hoch und runter scrollen, suchen die Felder, korrigieren, schicken erneut ab. Das fühlt sich wie ein „Test“ an.
Änderungen, die oft schnell wirken
- Optionales klar als optional markieren, Pflichtfelder reduzieren.
- Fehler direkt am Feld nach Feldwechsel anzeigen (statt Sammel-Feuerwerk).
- Hilfetexte für Formate ergänzen (z. B. Telefonnummer, PLZ).
- Abhängige Felder erst anzeigen, wenn relevant.
- Buttontext präzisieren („Zur Zahlung“ statt „Weiter“), damit der nächste Schritt erwartbar ist.
Solche Anpassungen sind selten „große Redesigns“. Es ist eher Feinarbeit an Fehlermeldungen, Reihenfolge und Zuständen. Genau diese Details entscheiden aber darüber, ob ein Formular wie ein Gespräch wirkt oder wie ein Formular.
Vor- und Nachteile: Inline-Fehler vs. Fehlerliste am Anfang
| Ansatz | Vorteile | Nachteile |
|---|---|---|
| Inline-Fehler direkt am Feld | Kontext ist klar, schnelle Korrektur, ideal für mobile Nutzung | Bei vielen Fehlern kann es lang wirken, braucht saubere Abstände |
| Fehlerliste am Anfang der Seite | Guter Überblick, hilfreich bei langen Formularen | Nutzer müssen zum Feld springen; ohne Sprungmarken schwer |
In vielen Projekten funktioniert die Kombination am besten: Inline-Fehler als Standard, plus eine kurze Zusammenfassung oben, wenn mehrere Felder betroffen sind. Wichtig ist dann eine klare Verlinkung oder zumindest eine eindeutige Orientierung, damit niemand suchen muss.
Was oft vergessen wird: Formulare brauchen Pflege
Texte und Regeln ändern sich – Komponenten sollten das aushalten
Formulare entwickeln sich: neue Pflichtangaben, andere Passwortregeln, zusätzliche Länder, neue Bezahlarten. Darum sollte das Layout mit wachsenden Texten klarkommen. Hilfetexte dürfen zweizeilig werden, Fehlermeldungen dürfen länger sein, ohne dass alles kollabiert.
Das spricht für flexible Komponenten und klare Abstände. Zudem hilft eine kleine „Textbibliothek“ für wiederkehrende Meldungen, damit Ton und Begriffe konsistent bleiben.
Testen mit echten Eingaben: keine Fantasie-Daten
Viele Designfehler entstehen, weil nur „Max Mustermann“ getestet wird. Besser sind reale, schwierige Beispiele: lange Namen, internationale Adressen, doppelte Leerzeichen, Sonderzeichen, verschiedene Geräte. So zeigt sich früh, ob ein Feld zu klein ist, Labels abgeschnitten werden oder Fehlermeldungen das Layout sprengen.
Wer Formulare mit diesem Blick plant, gestaltet nicht nur „Felder“, sondern eine robuste Interaktion. Das Ergebnis ist ein UI, das Menschen durchbringt – auch wenn sie sich vertippen, unsicher sind oder mobil unterwegs sind.
