Das Online-Formular ist eine Internet-Funktionalität, mit der Nutzer immer wieder Schwierigkeiten haben, denn wie bei den meisten interaktiven Elementen stehen und fallen Qualität und Erfolg auch bei Formularen mit der Usability. Einige exemplarische Beispiele und Möglichkeiten zur Vermeidung von Problemen.
Eingabefelder für persönliche Daten
In nahezu jedem Formular werden Name und Anschrift des Users abgefragt. Bereits hier kommt es häufig zu Problemen und Irritationen, und zwar dann, wenn die Eingabefelder nicht den Nutzererwartungen entsprechen. Diesem Thema widmet sich eine Studie der eResult GmbH und betrachtet konkrete Erwartungshaltungen im Hinblick auf die Eingabe der Anschrift, des Namens und des Geburtsdatums.
Schon die erste Schlussfolgerung bestätigt bisherige Untersuchungen: Offenbar haben viele Nutzer die Informationen zu Straße und Hausnummer als Komplex, als eine einzige Informationseinheit gespeichert und geben diese Daten deshalb zusammenhängend ein. So erwartet der Studie zufolge die Mehrheit der User (54,3%) ein einziges Formularfeld zur Eingabe von Straße und Hausnummer (28,5% bevorzugen zwei getrennte Felder).
Ausgeprägt sind auch die Erwartungshaltungen an die Reihenfolge, in der Vor- und Nachname eingegeben werden sollen. Zwar ist es 38,5% der Studienteilnehmer egal, ob sie erst den Vor- oder erst den Nachnamen eingeben sollen; letztere Variante bevorzugen allerdings lediglich 15,2% der Teilnehmer, während 46,3% ihren Vornamen und anschließend ihren Nachnamen eingeben möchten. Anwendungen sollten die Sprache des Nutzers sprechen: Wer stellt sich in einer Alltagssituation einem Unbekannten zuerst mit „Nachname Vorname“ vor?
Den dritten Schwerpunkt der Studie bildet das Geburtsdatum. Stehen User vor der Wahl zwischen einem Formularfeld und drei Feldern zur getrennten Eingabe von Tag, Monat und Jahr, bevorzugen fast zwei Drittel der Nutzer die zweite Variante.
Die Ergebnisse sind nicht unbedingt überraschend, und doch: Gerade in diesen Punkten erfüllen zahlreiche Formulare nach wie vor nicht die Erwartungen der User.
Drop-Down-Menüs
Apropos Geburtsdatum: Um User-Fehler von vornherein auszuschließen, greifen viele Website-Betreiber auf Drop-Down-Menüs zurück. Häufig eingesetzt wird diese Variante bei der Länderauswahl oder eben für Datumsangaben. Zwar versichert sich der Website-Betreiber dadurch valider Daten, doch die Arbeit mit Drop-Down-Menüs ist mit einem nicht zu unterschätzenden Mehraufwand für den Nutzer verbunden: Zunächst muss dieser den „Schreiben-Modus“, in dem er sich befindet, unterbrechen und zur Maus greifen, um anschließend einmal zu klicken, gegebenenfalls zu scrollen und erneut zu klicken.
Darüber hinaus sind ausklappende Menüs in Formularen mitunter sehr lang. Ein User, der im Drop-Down-Menü beispielsweise bis hinunter zum Jahr 1965, bis zum 30. Tag eines Monats oder auf der Suche nach „Deutschland“ durch eine Liste mit aller Herren Länder scrollen muss (um schließlich festzustellen, dass „Deutschland“ nicht zur Auswahl steht und er offenbar noch weiter unten „Germany“ anklicken soll), hat eine Menge zusätzlicher Arbeit, die ihn frustriert. Unter Usability-Aspekten sind gerade lange Drop-Down-Menüs in Formularen sehr problematisch.
Fehlermeldungen
Tippfehler oder versehentlich übersprungene Pflichtfelder lösen Fehlermeldungen aus. Sind diese jedoch unpräzise, verwirrt dies die Nutzer: Effektiv ist eine Fehlermeldung, wenn User sie erstens sehen und zweitens verstehen.
Zu einem aussagefähigen Fehlerhinweis gehört nicht nur die konkrete Benennung des Problems, sondern auch das Anbieten einer Lösungsmöglichkeit. Zudem sollten Fehlermeldungen aufmerksamkeitsstark positioniert sein: User erwarten, ggf. vom System auf den Fehler hingewiesen zu werden und das Formular nicht ihrerseits erst nach der Fehlerquelle absuchen zu müssen.
Auch können mithilfe von JavaScript oder AJAX viele Daten schon während der Eingabe validiert werden: Ist die E-Mail-Adresse formal korrekt? (Doppelt belegte Tasten führen z.B. gerne zur Eingabe von „q“ statt des @-Zeichens.) Besteht die Postleitzahl aus fünf Ziffern? Wurde ein Pflichtfeld versehentlich übersprungen? Hierdurch erhält der Nutzer Fehlermeldungen frühzeitig und nicht erst dann, wenn er das Formular in der Annahme, es fertig ausgefüllt zu haben, abschicken möchte.
Zurückgesetzte Felder und Reset-Buttons
Nach wie vor stößt man bei der täglichen Web-Nutzung auf Formulare, die, wenn sie eine Fehlermeldung ausgeben, auch alle bereits getätigten Eingaben kurzerhand zurücksetzen. Diese „Worst Practice“ ist ein schwerwiegendes Usability-Problem und ein Garant für Nutzungsabbrüche.
Ein immerhin stark umstrittenes Feature ist der Reset-Knopf, mit dem der User selbst seine Eingaben löschen kann. Renommierte Usability-Experten (darunter Jakob Nielsen) warnen eindringlich vor der Verwendung dieser Funktion:
„The Web would be a happier place if virtually all Reset buttons were removed. This button almost never helps users, but often hurts them.”
Jakob Nielsen: Reset and Cancel Buttons
Andere Stimmen (offenbar aus einem eher praktischen Umfeld) dagegen sind der Ansicht, dass ein Reset-Button in Spezialfällen (etwa bei häufig genutzten Formularen in Intranets) durchaus sinnvoll ist. Diese Standpunkte sollen hier nicht vertieft werden; Tatsache ist jedoch, dass eine Reset-Funktion ein enormes Frustrationspotenzial besitzt, weil User sie nicht selten mit dem Submit-Button verwechseln und ihre Daten versehentlich zurücksetzen. Häufige Gründe sind eine falsche Postionierung und/oder eine mangelhafte grafische Unterscheidbarkeit.
Deshalb sollten, sofern man als Website-Betreiber den Reset-Knopf als unverzichtbar einstuft, diese Funktion und der Submit-Button zumindest durch möglichst viel Freiraum voneinander abgegrenzt sein. Zur Unterscheidbarkeit trägt auch eine grafische Differenzierung bei, beispielsweise durch Ausgrauung oder durch eine Darstellung als Text-Link.
Nutzerfreundliche Formulare führen zu hohen Konversionsraten
Die Liste potenzieller Fehler- und Frustrationsquellen in Formularen kann hier freilich nicht vollständig abgebildet werden und soll sich auf diese exemplarischen Beispiele beschränken. Gute und nutzerfreundliche Formulare führen zu hohen Konversionsraten. Entscheidend dabei ist, ein Formular als sehr komplexe Funktionalität zu verstehen, die professionell konzipiert und umgesetzt werden muss.
User haben weder Zeit noch Lust, sich im Web herumzuärgern. Formulare mit Usability-Problemen führen häufig genug nur dazu, dass Ihre Nutzer um einige schlechte Erfahrungen reicher sind - und Sie um einige Conversions ärmer.
Die Usability-Experten von //SEIBERT/MEDIA/CONSULTING reden gerne ausführlich mit Ihnen über die Konzeption interaktiver Elemente und über nutzerfreundliches und damit erfolgreiches Interaktions-Design. Sprechen Sie uns an.
Weiterführende Informationen:
Ergebnisse der EResults-Studie zur Formulargestaltung (PDF/0,9 MB)
Der Bestellvorgang: Was häufig schiefgeht und was User frustriert
Usability-Richtlinien für Submit-Formulare in Formularen
Interaktions-Design: Auf die Feinheiten kommt es an
Mehr über die Creative-Commons-Lizenz erfahren
Schöner Artikel. Nochmals kurz zu Reset-Buttons. Es kommt immer darauf an, was in Formularen abgefragt wird und ob ein Reset Sinn hat oder nicht. Und es kommt auf die Anwendung an, welcher Hintergrund diese hat. Und wie es von anderen GUI gewohnt ist, sollte die Anordnung der OK und Reset-Buttons räumlich getrennt sein und nicht gleich bedeutend nebeneinander.
Schön, dass nochmals jemand darauf hinweist, dass Drop Downs an vielen Stellen, wo sie eingesetzt werden, keinen Sinn haben.
Mich würde mal interessieren, welche konkreten Beispiele es gibt, bei denen ein Reset-Knopf wirklich sinnvoll ist. Kennt jemand welche?
Martin, z.B. enthält der im entsprechenden Abschnitt verlinkte Artikel im “Art of Web Usability”-Blog ein paar Argumente, warum nach Meinung des Autors ein Not-Aus bei komplexen Eingabemasken sinnvoll sein könnte: http://www.art-of-web-usability.de/Wordpress/wordpress/?p=19
Was mich immer wieder ärgert sind “übertriebene” Methoden zur “Validierung” von Mailadressen. mh+seibert-blog@zugschlus.de ist genauso gültig wie mh—seibert-blog@zugschlus.de oder m@rchaber.de (letztere Domain existiert nicht, das ist nur ein Beispiel für einen einzeichigen Localpart). Trotzdem gibt es etliche Formulare, die diese Adressen nicht akzeptieren. Plus im Localpart, drei Minusse hintereinander im Localpart, Localpart, der nur aus einem Zeichen besteht – das überfordert den durchschnittlichen Entwicklern von Webanwendungen.
Es ist so gut wie unmöglich, eine Mailadresse “offline” auf ihre Gültigkeit zu prüfen, dazu ist der relevante Standard einfach zu komplex.
Und warum man in manchen Formularen die eigene Mailadresse “zur Sicherheit” nochmal eingeben uss, ist mir ein absolutes Rätsel. Wer macht da kein cut&paste?
Ach ja: Und wenn man nach dem Schreiben von vfünf Absätzen mitbekommt, dass der “Submit”-Button Javascript braucht, ist das ebenfalls eine Usabilitykatastrophe. Ja, Seibertmedia, ich meine die Webseite, auf der ich gerade diesen Text schreibe, und den ich gleich nochmal in einen anderen Browser kopieren darf, damit ich ihn abschicken darf.
Hm … Das mit der Java-Script-Anforderung war mir bisher nicht bewußt, habe jetzt aber intern ein Ticket aufgemacht, damit das geändert wird. Danke für den Hinweis und sorry für das Usability-Problem.
Dankeschön 😉
Und sorry für die Tippfehler, nächstes Mal lese ich nochmal Korrektur.
Bei der Eingabe von Geburtsdaten finde ich es interessant, dass die Nutzer offenbar eine getrennte Eingabe von Tag, Monat und Jahr bevorzugen.
Bezüglich der Bedienungszeit dürfte ein einfaches Textfeld vorne liegen. Das ergab zumindest unsere Auswertung zu Eingabemethoden für Geburtsdaten. 🙂
http://www.uxcite.de/web/eingabefelder-fuer-geburtsdaten/
Hier scheinen auch psychologische Aspekte eine Rolle zu spielen. Eventuell die Sorge einen Fehler zu machen.