I like the idea of delaying registration as well, but what happens when you let the user get through a multi-page application, sans registration/login, and then they want to submit, but registration is required first? Then the primary goal (submit application) gets confounded with the requirement to register.

“Once they start entering personal information (CollegeBoard.com asks for addresses, phone numbers, and social security numbers), the site can match that against information already in the database.”

Jared, what would happen at this point? Would the system prompt the user to log in? Or would it automatically log him/her in?

Kudos to Julian Pscheid for pointing out the security considerations involved in login scenarios. I’ve worked on a system where we were designing so the error messages would be highly uninformative, so as to thwart hackers.

Perhaps my biggest concern are questions like, What should the user do if he/she can’t remember which email address they used? Well, if you’re a user that constantly changes your email address, then you’re probably used to not being easily able to log into web apps anyway. Or the question, Should the user try another username or try to retrieve it via email? Most websites don’t even tell the user if the username exists in the database and instead spew out a generic message such as “Your username/password combination was incorrect.” What collegeboard has in place seems a luxury compared to today’s standards (and perhaps a security risk, but that’s a different conversation).

I’m not saying that the login process is not full of hurdles for users, after all it’s the point of creating those hurdles in order to prevent unauthorized access to accounts. But what I would like to see the most is a suggested login flow to solve the questions you posed. Because for now my opinion is that the standard login flow, as described using collegeboard, is so common that no user should have any problems navigating it.

I believe that is a fine example of how to do it right:
- inverted registration logic: rather than the usual “register first, edit later”, you start by playing around and then you can “claim” what you did, if you wish.
- log in as editor with password only: the website you’re trying to edit provided enough info as to “what” the user wants.

Linked had the same problem. The wanted you to sign in again if you were going to send an invite or changed something in your profile. As far as i can see they’ve recently fixed this problem, because that was what i called it.

I think, in addition to your article Jared, that we not only have to have a look at our poorly-implemented sign-in processes. We also have to be sure that we inform the user well enough about his status on the website: the user is either signed in or logged out, there’s nothing in between…

Jared, can you say a bit more about people changing e-mail addresses? I always thought that e-mail address was one of the best identifiers, because it’s unique, memorable and “most people would sooner change partners than e-mail addresses”. After all, it IS a hassle to get everyone to start using your new e-mail address. Any research on this you can point us to? Thanks.

So I think my husband (not pictured to the right), who is forced to read my blogs, thinks I\’m just a big nutter butter about my numerous login/password posts.
…