UX: Totale Transparenz bei Passwort-Restriktionen

Warum es wichtig ist, Passwort-Restriktionen klar und transparent im User-Interface anzuzeigen – und zwar bevor es zu einer Fehlermeldung kommt.

04. April 2013

Wenn man sich irgendwo online registriert, muss man in der Regel ein individuelles Passwort festlegen – kennen wir alle. Und wenn man es vergessen hat, bieten fast alle Services die Möglichkeit, ein neues Passwort zu vergeben.

Nicht selten ist die Vergabe eines Passworts an gewisse Restriktionen gebunden – das können systemseitige Einschränkungen oder Sicherheitsvorkehrungen sein. Bestimmte Länge des Passworts, bestimmte Zeichenanforderungen („muss mindestens eine numerische Zahl enthalten“), Passwort darf nicht den Nutzernamen enthalten, Passwort darf nicht Teile der E-Mail-Adresse enthalten, usw.

Initiale User Experience

Die Neu-Registrierung bei einem Webservice ist eine der ersten User-Erfahrungen mit einem Service – gerade deswegen sollten müssen alle Passwort-Restriktionen direkt im Registrierungsprozess angezeigt werden. Warum? Um den Frust zu vermeiden, der entsteht, wenn nach Absenden des Formulars eine Fehlermeldung erscheint. Und alleine wegen dieser Darstellung ist es sinnvoll, die Restriktionen so gering wie möglich zu halten. Denn: Je mehr Restriktionen es gibt, umso wichtiger ist es, diese klar zu benennen und darzustellen.

Zumindest für einige Restriktionen kann man auch Inline-Flash-Meldungen ausgeben, sobald eine Restriktionen nicht erfüllt ist (am besten als „Type ahead“-Darstellung, also während der Nutzer tippt). So erspart man dem User ggf. eine Restriktionen-Anforderungsliste und minimiert den User-Frust auf die Fälle, die eintreten.

Niemand macht Passwort-Änderungen zum Zeitvertreib

Gleiches gilt natürlich für die Neuvergabe eines Passworts, auch hier sind alle Restriktionen für den Nutzer transparent im User-Interface darzustellen. Denn: Wenn der Nutzer sein Passwort gerade jetzt neu definieren will bzw. muss, dann hat er ganz offensichtlich dringend vor, mit dem Webservice zu interagieren – was für den Servicebetreiber ja nicht selten in Umsatz münden könnte. Deswegen muss die Passwort-Neuvergabe unmittelbar und schnell zum Erfolg führen.

Wie man es nicht machen sollte

Während ich kürzlich dringend ein Car2go reservieren wollte, musste ich mein Passwort auf der car2go-Website neu vergeben. Nachdem ich mir also ein neues Passwort überlegt hatte, das Formular mühsam ausgefüllt hatte (Passwort-Eingaben und deren Wiederholung erfolgen ja gerne im Invisible-Modus), erhielt ich folgende pauschale Fehlermeldung:

Bitte beachten Sie, dass Ihr Passwort mindestens aus acht und maximal aus 25 Zeichen bestehen darf. Die erste Stelle des Passwortes muss ein Buchstabe sein und es muss mindestens einen Groß- und Kleinbuchstaben, sowie eine Zahl (0-9) enthalten.

Weiterhin sind Kombinationen, die den Vornamen, Nachnamen, Alias oder das Wort car2go enthalten, nicht nutzbar.

Wie groß ist wohl die Wahrscheinlichkeit, dass ich ohne Kenntnis dieser umfangreichen Restriktionen auf Anhieb ein systemkonformes Passwort definiere? Richtig – hart gegen Null. Mit dieser explosiven Anhäufung von diffizilen Anforderungen ist User-Frust im wahrsten Sinne des Wortes vorprogrammiert.

Einzelne Aspekte sind erklärbar – technisch (z.B. Mindestlänge wegen Verschlüsselung) oder sicherheitsbedingt (z.B. mindestens eine Zahl). Aber Einschränkungen wie „die erste Stelle muss ein Buchstabe sein“ erscheinen sehr willkürlich.

Wenig Restriktionen, viel Sichtbarkeit

Deswegen: So wenig Passwort-Restriktionen wie möglich, und diese im User-Interface unmittelbar und sichtbar kommunizieren. Damit die potenziellen Nutzer nicht schon bei der Registrierung Negativ-Erfahrungen machen.