Website usability: Formulare

Für einen Benutzer sind Formulare lästig. Sie erfordern mehr Konzentration und aktive Beteiligung. Das wird jeder bei sich selbst schon beobachtet haben. Innerhalb einer Prozesskette ist ein Formular darüber hinaus auch eine Art von Währung. Genauer gesagt, der Aufwand das Ding auszufüllen und natürlich die Daten an sich.
Normalerweise wird man einen Benutzer nur dann auffordern, bestimmte Daten in ein Formular einzugeben, damit er im Gegenzug etwas bekommt. Einen Account, eine Bestellung, einen Termin, etc. Die Dateneingabe ist somit Teil des Preises oder der Gesamtpreis, den der Benutzer zahlen muss. Es findet automatisch eine Kosten-/Nutzen Analyse statt: „Ist es mir das wert?“.

Weniger ist mehr

Die Datenmenge, die abgefragt wird ist somit in zweierlei Hinsicht ein Kostenfaktor für den Benutzer. Um den Aufwand so gering wie möglich zu halten, sollten nur so viele Daten wie absolut nötig abgefragt werden.

Bei jeder optionalen Angabe sollte immer die Frage gestellt werden, ob dieses Feld nicht vollständig aus dem Formular genommen werden kann. Weniger sichtbare Felder bedeutet weniger Aufwand für den Benutzer.

Eine Nutzungsabsicht kommunizieren

Müssen oder sollen zusätzliche Informationen angegeben werden, ist es für den Benutzer eine große Hilfe zu verstehen, aus welchem Grund er sie angeben soll. Ein kleiner Hilfe-Text, der erklärt was wir mit diesen Informationen tun wollen schafft Verständnis und Vertrauen.

Angenommen, wir bieten einen Newsletter an. Zwingend erforderlich für das Abo ist die Angabe der E-Mail Adresse. Wenn wir noch den Namen und die Anrede haben wollen um den Empfänger persönlich anzureden, kann er bei der Registrierung auch direkt darüber informiert werden.

Gruppierung mit Fieldset und Legend

Ein umfangreiches Formular erscheint weniger massiv, wenn die Felder nach Art der Daten gruppiert und in einem Fieldset mit Legende aufbereitet werden. Hier lässt sich die Nutzungsabsicht auch gut zusammenfassend unterbringen.

Die Tab-Reihenfolge festlegen

Die Tab-Reihenfolge läuft, wenn nichts anderes angegeben ist, entsprechend des Auftretens der einzelnen Felder im Quellcode. Diese Reihenfolge muss aber nicht unbedingt mit einer sinnvollen Eingabereihenfolge übereinstimmen. Um dies zu gewährleisten ist der Einsatz des tabindex Attributs nützlich.

Labels sind klickbar

Felder sollten immer eine ID und ein Label mit for-Attribut bezogen auf diese ID besitzen. Ein klick auf das jeweilige Label setzt den Focus in das dazugehörige Eingabefeld.

Handelt es sich um ein Label für eine Checkbox, erlaubt dies auch das an- und Ausschalten der Checkbox durch klick auf das Label. Es ist für den User wesentlich einfacher auf das besser zu treffende Label zu klicken als genau auf die Checkbox.

Vorsicht bei inline-Labels

Inline-Labels sollten bei umfangreicheren oder komplexen Formularen unbedingt vermieden werden. Ist ein Feld mit einem Inline-Label ausgefüllt geht die Beschriftung und damit der Kontext für den Benutzer verloren. Tritt nun ein Validierungsfehler auf, ist es für den Benutzer nicht mehr einfach nachzuvollziehen welches Feld welche Eingabe haben sollte.

Formatvorgaben kommunizieren

Kaum etwas ist so nervenzehrend für einen Benutzer als ein Formular wegen Eingabefehlern erneut überprüfen zu müssen. Ganz besonders dann, wenn die Angabe inhaltlich Richtig ist, die Formatierung aber nicht einer Vorgabe entspricht über die er bei der ersten Eingabe nicht informiert worden ist.

Angenommen, es soll eine Telefonnummer in einem bestimmten Format eingetragen werden, sollte das Feld mit einem entsprechenden Hinweis versehen werden. Zusätzlich bietet sich das placeholder Attribut hervorragend dafür an um ein Beispiel vorzugeben.

Fehlermeldung mit Lösungsvorschlag

Validierungsfehler kommen natürlich trotzdem immer wieder vor. Hier sind klare, verständliche Fehlerbeschreibungen gefragt, damit der User genau weiß was er falsch gemacht hat und was er ändern muss, damit es richtig ist. Verständlich für den User muss es sein.

Angenommen, wir validieren eine E-Mail nebst der üblichen Syntaxprüfung auch auf den MX-Record der angegebenen Domain. Es wird den meisten Benutzern so gut wie nichts Sagen, wenn er angezeigt bekommt, dass der MX-Check fehlgeschlagen ist.

Fehler dort melden wo das Problem liegt

Die Platzierung der Fehlermeldung sollte so nah wie möglich an dem Feld auftauchen in dem der Fehler aufgetreten ist. Durch zusätzliches Hervorheben von Label und Feld ist die Meldung besser zuzuordnen. Es muss immer klar sein welche Meldung zu welchem Feld gehört.

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.