iTunes zeigt uns einen weiteren Ansatz im Umgang mit dem Registrieren-Link, es lässt ihn einfach weg. Statt dessen ist der Registrieren-UseCase im Anmelden-Dialog versteckt:

(Screenshot vergrößern)

Mir gefällt der Gedanke. Er spielt bewusst damit, dass Nutzer diesen Link schon klicken werden, wenn sie sonst keine Alternativen haben … aber erzeugt dabei kein schlechtes Gefühl.

Was haltet ihr davon? Ist das ein Pattern, das wir nutzen sollten in unseren Webapplikationen? Oder nur in speziellen Situationen?

Das ist interessant, denn für andere Begriffe, Elemente und Positionen haben sich im Netz, schon klare Quasi-Standards herausgebildet. Zum Beispiel das Disketten-Symbol zum Speichern, das Haus als Link zur Startseite oder die Position des Logos mit Startseitenlink oben links auf der Website. Solche Standards sind für Konzepter und Designer natürlich praktisch, denn sie sparen uns, ständig grundsätzlich über jedes Detail nachzudenken.

Mit dieser Erwartungshaltung war ich auch Anfang des Jahres in die Entwicklung der Startseite für mein probono-Projekt stayscout.de gegangen. Ich war erstaunt, wie knifflig es ist, Anmelden und Registrieren absolut klar voneinander abzugrenzen. Als ich meine erste Version der Startseite in Steve-Krug-Usability-Tests getestet habe, sind zu viele Probanden darüber gestolpert.

Inspiriert durch den Artikel »Login/Logout vs Sign In/Sign Out vs Log in/Sign out – A short roundup«, der der gleichen Frage im englischsprachigen Raum nachgeht, habe ich zusammen mit Christina, die auch schon an unserem Artikel »4 Jahre Designevolution des YouTube Players« mitgeholfen hat (Danke!), einige große deutsche Webseiten verglichen.

Mein Fazit für den Login:

Für eine deutsche Zielgruppe als Anmelden/Abmelden der gute Weg.
Die Begriffe werden am häufigsten verwendet und dazu meist auch in der Kombination Anmelden/Abmelden. Alternativ wird auch Einloggen/Ausloggen und manchmal gemixte Versionen gerne verwendet.

Mein Fazit für den Sign up:

Die Aufforderung zur Nutzer-Konto-Erstellung sollte im Kontext betrachtet werden um eine Abgrenzung zum »Anmelden« zu schaffen. Dabei ist es wichtig, die Einmaligkeit des Vorgangs hervorheben.

• Es fällt auf, dass es keinen einheitlichen Standard gibt.
• Auch »Registrieren« setzt sich nicht durch, ist aber in Variationen der am häufigsten vorkommende Begriff.
• Viele Seiten verwenden ihre eigene Sprache, eigene Begriffe/Varianten.
• Seiten verwenden häufig sehr kontext-bezogenes Wording
• Die Hälfte versucht dabei die Einmaligkeit des Vorgangs hervorzuheben (»Erstmalig«, »Neu hier?«, …)

Die Daten aus unserer Recherche:

(Die Tabelle kann gerne ergänzt werden!)

Für meinen StayScout-Anwendungsfall war ich inzwischen übrigens schon auf die gleiche Lösung gekommen. Ich spreche von »Anmelden« und »Jetzt Mitglied werden«, wobei ich letzteres im Kontext noch verstärke, zum Beispiel durch »Für neue Besucher«.

Welche Erfahrungen habt ihr gemacht mit der Unterscheidung zwischen Anmelden und Registrieren?

PS: In der Schweiz sieht das übrigens anders aus. Dort spricht man gerne von »Login« statt »Anmelden«.

PS2: Wie auch schon Tanin in dem oben verlinkten Artikel konnte ich auch keine Systematik bei den URLs finden. Hier herrscht fröhliches Chaos :-).

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.

Man könnte natürlich, wie Luis von Ahn im Google-Talk »Human Computation«, das Gute darin sehen: Menschen verbringen weltweit bestimmt tausende Stunden damit, Captchas auszufüllen – diese Zeit muss man für Gutes nutzen wie das digitalisieren von Büchern über sein reCaptcha-Projekt.

Für mich macht das das Ausfüllen von Captchas aber nur wenig besser. Aber es gibt noch etwas, das noch mehr nervt als Captchas einmal auszufüllen:
Captchas mehrmals ausfüllen müssen, weil aufgrund einer Meldung das Fomular nicht abgeschickt wurde.

Dabei ist die Lösung wieder sehr einfach und Twitter macht es uns vor:

Ryan Carson hat diesen Fall entdeckt und schön mit Screenshots in seinem Blog dokumentiert: »How to Increase Sign-ups with Easier Captchas«.

Man könnte jetzt noch Fragen, ob dieser Aufwand gerechtfertigt ist, wo doch schon die JavaScript-Validierung im Formular selbst alle Fehler abfängt. Dem würde ich auch zustimmen für ein so einfaches Formular – leider können aber nicht alle Fehler direkt abgefangen werden, weil beispielsweise nur Serverseitig überpfüft werden darf, ob die eingetragene E-Mail-Adresse schon von einem anderen Account verwendet wird.

Mich interessiert jetzt:

Habt ihr diesen Umgang mit Captchas schon anderswo beobachtet?

Oder kennt ihr weitere Formulare, deren UX auf ähnliche Weise verbessert wurde?