How to prevent registration from login page and login from registration page

Question

During user tests we see quite some people 1) enter their previous chosen login details (email+pass) on the registration page. Including them wondering "why we ask all this information again?". The process fails right now as there already is such an email address.

Also, 2) some people fill in their email+pass for the first time on the login page. Without ever being registered before this also fails.

Of course we can adjust the notification at failure; already registered? go login, and not registered yet?. But that feels not the best, and, is too late.

We also tried having such notifications before you fill in the form. So log in here. haven't registered yet? ... But it feels a bit bad still, and it still doesn't catch all users

Are there any good practices? Or do you have another idea, on how to solve this issue? Is it in the wording and visual appearance of these notifications? (I don't really believe so..) - Or is there something more deeply wrong / to solve? (I hope so :))

---

PS: I've seen the question about merging the registration and login page into one, but I'm not convinced that is the way I want to go.

Answer 1

What kind of users do you have? Do they come back often, or is there a long time between visits? When they return, are they aware that they already have an account?

• Minimize the need for existing users to log in, remember them across sessions. Even if you don't log them in automatically, you could adapt the page they see to their needs. Log in should be in a logical place and easy to find.
• Make it easy to log in, try to embed the login fields in the page instead of using a separate login page. (I assume you ask for more information on registration than on log in, but I could be wrong here.)
• Consider using different terms. The most confusing example I've seen was in an application where users could choose between 'sign up' and 'log in'. It just didn't work. What terms are your users familiar with, and which terms are normally used in the domain? Do they 'create an account', 'join', or are they 'returning visitors'?
• It's often a trade-off between catering for existing users and attracting new ones. Which is more important for your application? If your main goal is to get as many signups as possible, having some of your returning visitors end up at the registration page might be a price you're willing to pay.
• Help your users recover from errors. As soon as an existing user enters their email address on the registration page, recognize them and prompt them to log in instead (without having to enter their email again, they just did). And if someone tries to log in who doesn't have an account yet, direct them to the registration process.

Answer 2

You said you were unsure about merging the two pages. One really simple example is Reddit.com - log out (if you're a member) and try to upvote any story. The popup will present you with both forms side-by-side. Too confusing?

I've also seen sites (the names don't come to memory) where the pages were combined but made distinct by implementing a tabbed interface. On the default (login page), a fat right sidebar contained a high contrast button with something like "Haven't registered yet? Click here". On the registration 'tab', there was a similar button about logging in on the left.

Aside from this, there's an easy hack you can implement to remove one of your use cases. If I user mistakenly fills out the registration form, have your app check the email and password. If the email already exists and the password is correct for the account, just log them in.

If your unregistered users are having problems on the login page, you might need to investigate why they are having problems..

• Is it unclear that the page is for logging in and not signing up? Why? Is the text too long? Is the language too technical or flowery?
• Are your users confused in thinking they already signed up because your site was linked from another site where they hold accounts?
• Are your users trying to log in using credentials from other places? If this is the case, they don't even know why they're logging in. Maybe more of the site needs to be public (bug them about logging in and registering when that's actually essential - not before they do anything).

Answer 3

I must say I do like the merging approach, but I can see why it may not be appropriate in all cases.

What's the flow of your website? Do they land on a page with links to login and to register, or on a page with the form to login/register and a link to the page with the other form? Or on a page with both forms? In short, is there a default and what is it? You can play with the architecture to solve it. For example, error 1 can't happen on gmail, because you always arrive at the login page first. But error 2 always happens to me on linkedin, since I am using a password manager, and it tries to enter my login details on the homepage, which is the registration form.

Also - how is the registration form designed? In the rare case that it only has two fields, I can see how people might mistake it for the login. You may want to add a couple of non-required fields specifically to deal with this - and put them before the login fields. That's why on the LinkedIn page I'd never make the mistake that my password manager does. OTOH, adding unnecessary fields is not a very good practice :). But the tradeoff is yours to figure out.

Answer 4

One idea would be to set a cookie and serve him the login form by default if he was logged in on this machine before (for this to work properly, to log in and the registration have to be on one page with a switch).

Answer 5

Use one form: e-mail, password ("forgot password", "remember me" features optional)

If the credentials are good, they're logged in. If the e-mail is good, but the pwd isn't, give the user an error message accordingly. If the e-mail doesn't correspond to a user, congratulations, you just got a new user. In your http response, begin collecting the rest of your required registration data. Also, e-mail them a verification link.

Answer 6

Default should be login form, another click to register. If your site/app is in it's early stages and you're pushing registration this is likely an in between problem.

Answer 7

There's Japanese design principle called Poka Yoke. It says you should fail-safe everything, that is, prevent as many error messages popping up as you can. Following Poka Yoke, your backend script should support logins on the registration form and registration on the login form. Try not to display an error message when the form is used for the wrong reason.

If you've ever read Don't Make Me Think by Steve Krug, you'll remember that Steve Krug noticed that people were still using Yahoo.com's search engine form to type in full URLs. These people thought that Yahoo was "the Internet". To this very day, Yahoo still places the URL as the first search result to support these naive people.

Similarly, since you are seeing people use your forms in the wrong way, you can support the wrong usage. Here's an example of the PHP script for registration. The PHP script for login will be the inverse.

if (User::find($_POST['username'], $_POST['password'])) {
 User::login($_POST['username'], $_POST['password']);
 User::redirectToLoggedInPage();
} else {
 User::register($_POST['username'], $_POST['password']);
}

Answer 8

On the login page, you could provide a button for the user to register if they enter a wrong username/email address. It would be a bad idea to register them without confirmation, as they could have simply mistyped their details.

You could make sure they don't have an account (and get information to create one) by asking for information they need to register (email or username) that you don't ask for on the login page (or you could just ask the user to re-type their existing username/email address). If a user with that username or email address already exists, you can prevent them from registering.

On the register page, you could consider logging the user in if their credentials fit. However, the user could have simply entered an username/email address that already exists and used a common password. So, consider:

• How strong is your password validation? If passwords have to be very strong, this is unlikely to happen.
• How much information do you request users enter? If you ask for an email address, a username and a password, it is almost certainly the right user. Be careful with privacy issues here.
• Can you detect if the user has logged in before on the same computer? Similar to Phil's idea, you could consider logging the user in automatically if they have already been logged-in on the same computer.

If not, you could provide a button to do this, too, possibly showing any public user information to help the user make their decision: