uxzentrisch 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.

Wireframeausschnitt: Anmelden und Registrieren auf der Startseite in einem Formular

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:

Wireframe: Registrierung als Fehlerfall der Anmeldung
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.

13 Kommentare

Matthias Zellmer (@Zellmi) vor 6 Jahren

Interessantes Thema.

Zunächst einmal zum Begriffswirrwarr. Ich hab mal irgendwo statt »Registrieren« »Erstmalig anmelden« gelesen. Fand ich einen ganz guten Begriff.

Eine technisch etwas aufwendigere, aber usability-technisch bessere Lösung wäre es, wenn man (ähnlich der Gravatar-Kommentarfunktion hier) auf die Eingabe der Nutzerkennung (Mail-Adresse, Username, …) reagieren würde. Wird eine dem System unbekannte Nutzerkennung eingeben, so wird das Formular um die zur Registrierung notwendigen Felder erweitert.

Dominik vor 6 Jahren

Eine automatische Erkennung der bekannten E-Mailadressen würde zwar den Prozess stark vereinfachen, ist aber aus Sicherheitsgründen wieder schwierig. Captcha ab der dritten Eingabe? Diesen Aspekt aussen vor gelassen aber eine spannende Lösung; Reduzierung auf (zunächst) ein einziges Feld – cool!

Thema Begriffe: Ich verwende in der Regel »Registrieren« und »einloggen«, ich finde diese beiden Worte unterscheiden sich am deutlichsten von einander.

Matthias Zellmer (@Zellmi) vor 6 Jahren

@Dominik Ich würde schon mit zwei Feldern starten: Nutzerkennung und Passwort. Wenn man seine Kennung eingeben hat und zur Passwort-Eingabe wechselt, dann erst würde ich die eventuelle Erweiterung des Formulars darstellen lassen. Somit sollte der Sicherheitsaspekt auch deutlich besser abgedeckt sein.

Tobias Jordans Autor vor 6 Jahren

@Matthias @Dominik: Ja, das Formular dynamisch zu verändern kann ich mir auch gut vorstellen. Ich hatte aber den Eindruck, dass es in der Form wie im Wireframe etwas klarer/verständlicher ist für den Nutzer.
Insbesondere, wenn für die Registrierung zusätzliche Felder nötig sind wie Vorname, Nachname. Es sei denn, man würde diese wiederum erst nachgelagert abfragen (wenn der Nutzer schon einen Account hat).

Sicherheitsthema: Vielleicht sollte man dieses Pattern auch nur mit richtigen Benutzernamen und nicht mit E-Mail-Adressen verwenden. Einen Benutzernamen auszuspionieren ist uninteressant. Eine E-Mail-Adresse auf diese Weise zu validieren dagegen eher (Spam…).

Tamim vor 6 Jahren

Ja. Guter Ansatz. Gefällt auf Anhieb.

Dominik vor 6 Jahren

Ich hatte ein wenig gehofft, wir könnten diese ganze Benutzernamengeschichte abschaffen und Nicknames wären total 2006. Zumindest Nicknames zu Identifikationszwecken.

Ich habe (die völlig unverifizierte) Hoffnung, dass ich meine User beim Login mit einer E-Mailadresse immer daran erinnere, diese E-Mailadresse stehts aktuell zu halten. Aber das ist sowieso ein ganz anderes Thema.

Tobias Jordans Autor vor 6 Jahren

Mockingbird macht, was hier vorgeschlagen wird. Schreibt Matthias in seiner Review:

Kleines Detail noch am Rande. Vor ein paar Tagen habe ich auf dem Blog uxzentrisch an einer Diskussion über Anmelde- und Registrierungselemente teilgenommen. Interessanterweise ermöglicht Mockingbird das Anmelden bzw. Registrierungen genau in der dort von mir vorgeschlagenen Art und Weise. Dort bekommt man erst einmal nur ein Formular und wenn die eingegebene Mail-Adresse unbekannt ist, wird das Anmeldemodul um ein Feld zu Passwortbestätigung erweitert und somit zur Registrierung. Sehr innovativ, wie ich finde.

Tobias Jordans Autor vor 6 Jahren

Update: Google hat einen langen Artikel veröffentlicht in dem Sie über das gleiche Problem nachdenken: http://sites.google.com/site/oauthgoog/UXFedLogin
Ihre Lösung geht allerdings den transparenteren Weg, den Amazon.com verwendet (CheckboxenRadiobutton). Dieses UI-Pattern gefällt mir erstmal überhaupt nicht so gut. Aber vielleicht ist es besser, weil es transparenter/offensichtlicher ist für den Nutzer?
Muss den Googletext aber nochmal intensiv lesen :).

Googles Idee
Googles Ideee

Sehr gut an dem Google-Artikel sind die weiterführenden Gedanken, die sie sich über die OpenID-Integration in den Registrierungs- und Login-Prozess (Migration) machen.

Auch wenn mir dieses Google/Amazon/Buy.com Interface nicht so gut gefällt. Wenn Google es einsetzten würde, würde sich endlich ein neuer, besserer Standard etablieren.

Marian Steinbach uxzentrisch vor 6 Jahren

Bei Amazon Web Services gibt es einen Ansatz, der dem hier beschriebenen zumindest ähnelt. Hier ist ein Screenshot: http://twitpic.com/quuj1

Allerdings haben sie es geschafft, dass man sich als wiederkehrender Nutzer auf der Website praktisch gar nicht abgeholt fühlt. Alle Links, die auf die Login/Registrieren-Seite führen sind mit Texten wie »Sign up now« und »Sign up for a free AWS account« beschriftet. Es fehlt mir ein simpler »Login« oder »Sign in« Link.

http://aws.amazon.com/

Peter Scheidt vor 6 Jahren

E-Mail-Adressen als Login-Namen sind eher schwierig, finde ich. Einer meiner Kollegen erzählte letztlich von einem Test, in dem die Teilnehmer in dem Fall sozusagen reflexartig versuchten, ihr WEB.DE-Passwort zur Email-Adresse einzugeben, obwohl sie ganz woanders waren. Ich selber tue mich hin und wieder auch schwer damit, um ehrlich zu sein ;-)

Tobias Jordans Autor vor 6 Jahren

Update: Noch ein Artikel zum gleichen Thema (eng) http://blog.leahculver.com/2009/11/log-in-or-sign-up.html – Die Problemstellung ist die gleiche wie hier.

Die Lösung von Hurl, die dort beschrieben wird, finde ich nicht gut (2 Button, 1 Formular):

Die Lösung von Amazon, die als 2. Lösung beschrieben wird, gefällt mir auch nicht… aber sie scheint verbreitung zu finden (siehe oben, google).

Martin Gude uxzentrisch vor 6 Jahren

@Peter Trotzdem halte ich die E-Mail Adresse derzeit noch für den besten Benutzernamen. Den kann ich mir nämlich merken – vor allem im Gegensatz zu Kundennummern. Zumindest aber sollte ein Login mit der E-Mail-Adresse *möglich* sein

Und was tue ich, wenn mein gewünschter Benutzername vergeben ist? Klar ich denke mir einen neuen aus. Irgendwann muss man dann wirklich ein Account/Passwort-Management-Tool nutzen.

Das schlimmste Beispiel, wo ich bei jedem einloggen erstmal die Passwort vergessen Funktioon nutze, um meinen Benutzernamen rauszufinden ist die Petitionsseite des Bundestages. Die haben einen vom System vorgegebenen Benutzernamen im Format »Nutzer123456″. Und den kann ich mir beim besten Willen nicht merken.

Mein liebster Login Weg ist aber definitv via OpenID.

Trackbacks und Pingbacks