ux·zentrisch erörtert:
Interface-Pattern: Anmelden und Registrieren über ein gemeinsames Formular

Anmelden und Registrieren. Zwei Interface-Pattern, die täglich tausendfach genutzt werden. Aber müssen sie wirklich so aussehen, wie wir sie kennen? Dieser Artikel schlägt ein alternatives Pattern vor: Ein gemeinsames Formular für Anmeldung und Registrierung.

Als Jakob Nielsen kürzlich behauptete, alle Passwortfelder sollten unmaskiert sein, gingen Welle des Jubels und der Entrüstung gleichermaßen durch die Blogo- und Twittersphäre. Und egal ob Nielsen mit seiner Aussage recht hat, er hat uns alle nachdenken lassen über ein Interface-Pattern, das wir in dieser Form schon immer kennen und das bisher viel zu wenige in Frage gestellt haben.

Ich möchte heute ein anderes bekanntes Pattern in Frage stellen:

Registrieren vs. Anmelden

Nahezu jede Webapplikation erfordert heutzutage einen Benutzeraccount. Und meistens muss man sich zuerst Registrieren (d.h. einen Account einrichten), bevor man sich mit diesem Account anmelden kann.

Die Differenzierung zwischen der Anmeldung und der Registrierung ist dabei eine rein technische und dem Nutzer eigentlich egal. Er will nur rein. Hinzu kommen weitere Probleme:

• Wording: »Login«, »Anmelden«, »Registrieren«, »neu hier?«, »Wiederkehrer«… – das alles sind Begriffe, die nur verständlich sind, weil wir gelernt haben, sie mit Aktionen zu verknüpfen.
• Positionierung: Was ist wichtiger auf der Startseite, die Anmeldung oder die Registrierung? XING beispielsweise legt auf der Startseite den Fokus auf die Anmeldung, Facebook dagegen auf die Registrierung.

Lösungsansatz

Akademisch gesehen, ist die die Registrierung nur ein Fehlerfall der Anmeldung: Der Nutzer versucht sich anzumelden, das System erkennt, dass es diese Anmeldedaten noch nicht kennt und bittet um die Vervollständigung der Registrierung.
Es besteht kein Grund, den Nutzer auf der Startseite die Entscheidung abzuverlangen, ob er wohl schon eine Benutzerkonto hat oder sich jetzt registireren muss Für ihn geht es nur, darum rein zu kommen.

»Ja, aber…« sagen meine Kollegen jetzt. Und ich stimme ihnen dabei auch zu: Das ist erstmal eine sehr akademisch-theoretische Lösungsansatz und ich bin selbst unsicher, ob er wirklich funktioniert oder gar besser ist. Aber das sollte uns ja nicht davon abhalten, ihn zu durchdenken, nicht wahr? Also, was denkt ihr?

Wireframe:

Vergrößern

Hier die original Balsamiq-Datei zum downloaden, erweitern und kopieren (CC-by).

Pro Argumente:

• Ein Formular auf der Startseite, das sowohl registrierte als auch nicht registrierte Nutzer abholt.
• Der Nutzer muss nicht mehr wissen, ob er schon einen Account hat oder nicht.

Contra Argumente:

• Das klassische Anmelden-Registrieren-Pattern ist gelernt und wird erwartet. Diese Erwartungshaltung zu brechen lenkt mehr ab, als die Frage nach dem richtigen Prozess.
• Man muss das Wording auf der Startseite ändern. Der Button darf nicht mehr anmelden oder registrieren lauten, sondern »weiter gehts«, »los gehts«, …
• Man muss serverseitig einen Schutz gegen das Validieren von E-Mail-Adresse einbauen. Denn diese Lösung ist nur etwas für Webapplikationen, die sich erlauben wollen, konkrete Fehlermeldungen anzuzeigen (›Benutzername unbekannt‹ und ›Passwort falsch‹ vs. ›Benutzername oder Passwort falsch‹).

Alternativen?

Die eingangs beschriebenen Probleme hat übrigens nicht jede Webseite. Der Dienst Screenr.com beispielsweise braucht nur einen »Anmelden mit Twitter«-Button. Er profitiert davon, dass er aus Nutzersicht ohnehin kein Benutzerprofil speichert. Nur, wenn der Nutzer einen Twitteraccount hat, kann er sich dort anmelden.

Denkt man diese Lösung weiter, kann es gut sein, dass sich das hier diskutierte Problem in ein paar Jahren ohnehin von selbst erledigt: Dann werden nur noch einige wenige Dienste wie Google eine Registrierung benötigen. Alle nutzen dann das »Anmelden mit…«-Pattern (Stichwort: OpenID und oAuth) um ihre Besucher zu authentifizieren.