The Sign-In Travesty
September 14th, 2007
One of the most common design elements that stops users in their tracks is the sign-in page. A poorly-designed sign-in page can prevent users from proceeding with their task, thereby dramatically increasing abandonment rates.
We recently encountered this problem, in its full glory, at the CollegeBoard.com site, while observing users registering for the fall SAT courses.
Upon starting the registration process, the user is faced with this screen:
The sign-in page for CollegeBoard.com
Of course, the user now needs to know if they have an account or not. If the user is a parent with multiple children, they may have an account, having signed a sibling up previously. Or maybe they signed the student up for another test. However, these scenarios could’ve happened years before, so remembering the user id or the password may not work.
The user may try a common user name/password combination. However, if the user name is unrecognized by the system, it generates an error:
Receiving an error due to an unrecognized user name or password
Now the user is faced with a decision. Do they try another user name (there may be dozens to choose from) or do they try the unknown “Forgot Your User Name?” feature? Most of our users, wasted a little time trying other combinations that didn’t work before progressing on to the user name recovery feature:
The “Forgot Your User Name” feature
To recover the user name, the user has to put in their email address. However, this comes with its own challenges since many people have multiple email addresses and they frequently change them. (It’s estimated that one-third of all email addresses become obsolete every year.)
Entering an email address that the system doesn’t recognize produces the following error message:
An error from entering an unrecognized email address
The system informs the user that is doesn’t have anyone in their system who has that email address.
What is the user supposed to do now? There’s no “Create New Account” option, if that’s the proper thing. There’s no way to deduce which old email address could be in the system. The user has reached a dead-end.
At best, the user would hit the back button, but, amusingly enough, that produces a POSTDATA error message which sounds like something bad is going to happen, so users get very concerned.
What can developers do to avoid the Sign-in Travesty? They could postpone any notion of account sign-in until as late as possible. For example, if users don’t remember if they’ve already created an account, let them continue with the process. 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.
At a minimum, you should be regularly watching people who can’t remember their account information as they try to use your site. You’ll learn that your attempts to make the site convenient, by remembering information, actually makes it very inconvenient. And that’s the travesty of a poorly-implemented sign-in process.
September 14th, 2007 at 9:08 am
See It\’s Not Just Me…
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.
…
September 14th, 2007 at 9:17 am
[...] Jared Spool nails it again with his case study on poor login/register user experience: The Sign-In Travesty. [...]
September 14th, 2007 at 9:26 am
No good deed goes unpunished. The obvious intent is to not make someone create a new account each time their kid goes to college. But the limited benefit is far overshadowed by the experience Jared describes. I’ve seen this principle re-enacted in many different scenarios such as when the warning about unsupport browsers caused more problems than the unsupported browsed did. I had the same experience almost to the t trying to renew my fishing license this year. The “benefit” of not having to enter my name and address every year was erased by the 20 minutes fighting the scenario shown here.
September 14th, 2007 at 12:13 pm
Great article, Jared. I wish more companies would implement your solution and save us a lot of headaches.
September 14th, 2007 at 1:03 pm
“…many people have multiple email addresses and they frequently change them.”
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.
September 14th, 2007 at 5:49 pm
Great article Jared. I’ve noticed an almost similar problem: sign-in again when you’re already signed in. Two examples are Amazon (co.uk) and LinkedIn. Amazon asks you to sign in (again) if you want to see more detailed information about your packages and payment information. For users the reason the reason for this in totally unclear, and they get confused. “Do i have two login names for Amazon? And if yes, which one do they want?” and “Why do i have to sign in again? Did i log out?”. Questions the user shouldn’t have to ask himself.
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…
September 17th, 2007 at 9:49 pm
May I suggest you take a look at what the guys at http://bitbots.net did with Jottit (http://jottit.com)? It’s a simple and straightforward webapp for creating your own website.
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.
September 19th, 2007 at 3:30 pm
Jared, I’m not sure I agree with your position in this article. Part of it might be that I can identify a lot with the collegeboard site, since the login process is very similar to what I am familiar with and would use myself.
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.
September 23rd, 2007 at 11:58 pm
[...] my recent post, The Sign-in Travesty, one reader, Ron, talked about his frustration with Amazon.com’s frequent login requests. [...]
September 25th, 2007 at 5:31 pm
“They could postpone any notion of account sign-in until as late as possible.”
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.
September 27th, 2007 at 9:28 am
web tasarım, matbaa, web design, fatura, kartvizit, katalog, broşür
September 27th, 2007 at 9:29 am
anlaşmalı matbaa ofset, dijital, kurumsal, reklam, hizmetleri, promosyon, dijital, katalog, matbaa, arama, kurumsal, show, ajans, tabela, internet,